Re: Upgraded PHP version from 5.3 to 7.0.33 now database functions are broken...

>
> If you previously used the old ext/mysql (mysql_* functions), these have
> been removed and you should use either MySQLi or PDO instead. Note that
> neither of these are drop-in replacements for the mysql_* functions.


If you are indeed using the old mysql_ functions. If you have the time it
is best to update them to use pdo/mysqli, otherwise, if you don't want to
or don't have the time you can use this drop-in replacement that I wrote a
while back to make those functions work: https://github.com/AzizSaleh/mysql

On Fri, Sep 10, 2021 at 5:18 PM AllenJB <[email protected]> wrote:

> On 10/09/2021 20:24, Bo Berglund wrote:
> > Half a week ago I upgraded my webhost website to use PHP 7 instead of
> the old
> > 5.3 in order to make PHPmailer work, which it did after some work.
> Upgrading PHP 5.3 to 7.0 is a very big jump (PHP 5.3 thru 5.6 contain
> major changes from the abandoned PHP 6, among others) and I would expect
> code to break. In exactly what ways it will break will depend on the
> code. If the code is still using a lot of early PHP 5 / PHP 4-like
> constructs, you're going to run into more problems than if it was
> written with 5.3 era best practices.
>
> However, it is now well-trodden ground, so there's a number of tools,
> and plenty of articles and help out there for common issues people will
> encounter.
>
> You can find a list of changes in the "Migrating" appendices in the PHP
> Manual:
> https://www.php.net/manual/en/appendices.php
>
> The appendices for older versions can be found in the Zend hosted
> "legacy" manual:
> https://php-legacy-docs.zend.com/manual/php5/en/appendices
>
> You'll want to pay particular attention to the "breaking changes" sections.
>
> There are also tools that can help with finding most breaking changes.
> I've used the PHPCompatibility CodeSniffer ruleset, but there's also a
> range of others - a search for "php 5 to 7 migration tools" brings up
> some good articles.
>
> While I've not yet used it myself, one tool I've heard good things about
> for actually making changes to your code is Rector. A quick search
> suggests this can handle PHP 5.3 to 7+ upgrades.
>
>
> > But a side effect of this seems to be that the database functionality of
> a
> > completely *different* web application on the same server has broken
> down...
> >
> > I can now no longer use a Windows config application which updates the
> database
> > with new content by http posting new data to the database via php based
> > handlers.
> If you previously used the old ext/mysql (mysql_* functions), these have
> been removed and you should use either MySQLi or PDO instead. Note that
> neither of these are drop-in replacements for the mysql_* functions. To
> aid in the upgrading process you can find shim libraries for ext/mysql
> that act as a bridge. You should replace these with either MySQLi or PDO
> as soon as possible tho to ensure your code continues to work in the
> future as these shim libraries are unlikely to be maintained and will
> stop working in future PHP versions themselves.
>
>
> > I suspect that there is some simple syntrax change that is the cause but
> I don't
> > know how to test it on the site. There are php handlers working as if
> the data
> > came from a web form but it does not, instead a POST call is created in
> the old
> > Windows application and sent to the server.
> >
> > Any ideas how I can go about debugging this?
> > I am thinking about using curl to send the commands to the respective
> handler
> > php file or else I have to create a web form which can post data the
> same way as
> > the Windows App does...
> >
> > Any suggestions on the best approach?
> > curl or a test webpage or something else?
> PHP does not know or care exactly how the POST data was submitted. Data
> submitted through a Curl request will look exactly the same as data
> posted from a form on a web page. Creating a web page with a form that
> submits the same data as you expect to be submitted by another script
> via Curl is one way I have tested APIs in the past.
>
> > One notice from when I worked on the emailing form beginning of this
> week:
> >
> > I was able to enable php errors sent to the calling browser using this:
> > ini_set('display_errors', '1');
> > at the top of the php files.
> In addition the display_errors, you can direct errors to a log file
> using the `error_log` and `log_errors` ini directives (which can both be
> set using ini_set()):
> https://www.php.net/manual/en/errorfunc.configuration.php#ini.log-errors
>
> You should also ensure that your `error_reporting` level includes
> warnings, notices and deprecation notices while upgrading because these
> indicate potential bugs in your change and behavior that may (/ does)
> change in future versions.
>
> Sidenote: As I recall the exact "meaning" of E_ALL changed at some point
> between PHP 5.3 and PHP 7. You can always use '-1' to mean "all errors
> and notices of all types", or you may need to use a more specific error
> reporting level as shown in some of the examples on
> https://www.php.net/manual/en/function.error-reporting.php
>
>
> > Then I got error output related to the include done from a php file to
> the php
> > file doing debug logging, which was used in several php files
> > .
> > I had to change the includes like this:
> >
> > From:  include 'logdebug.php';
> > To:    include_once 'logdebug.php';
> >
> > Otherwise I got a strange error I had not seen before.
> >
> > Could the same be the cause here regarding the following include:
> >
> > include ($_SERVER["DOCUMENT_ROOT"] . '/php/appdbdata.php');
> >
> > It is present in each of the function related php files and uses the
> construct
> > above to make sure the correct file is included no matter where the
> using php
> > file is located.
> >
> > But do I always need include_once with PHP 7?
>
> The behavior of include_once itself hasn't changed between PHP 5.3 and 7
> as far as I recall. Most likely it's another issue that you need to fix,
> rather than swapping out include for include_once, which could itself
> break code if the file is supposed to be included multiple times.
>
>
> Without seeing actual code or error messages it's very hard to advise on
> specific cases.
>
> If you encounter specific problems you can't see how to solve, please
> post the full error message and the related code. It may help you to try
> to produce a short example that reproduces the issue.
>