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 <php.lists@allenjb.me.uk> 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. >