On Fri, 10 Sep 2021 22:18:09 +0100, AllenJB <php.lists@xxxxxxxxxxxxx> 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. I chose 7 over 5.4 since those were the only alternatives when changing site php version and my own private webhosting uses php 7.0 (and cannot be downgraded) so doing that would help me test stuff there before going to the active server... I think my php code is very simple really, and all of the database functionality resides in one file appdbdata.php. The other php POST data handlers do not contain database functions. Just calls to the main db file functions. It is created as a way to put selected data from a local MS-SQLServer database onto the webserver database so it can be used for our hardware management Android app used by the customers. It basically use it for validation of licensing and retrieval of version info and such. And the Windows application as well as the Android app interface via http POST calls to php files on the webserver. >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. I looked briefly on these pages but I could not find mention of "breaking changes" in fact the word break does not appear anywhere on the pages... >If you previously used the old ext/mysql (mysql_* functions), these have >been removed and you should use either MySQLi or PDO instead. Well, these are all the database related calls that exist in my appdbdata.php file: MySql call usage: ----------------- mysql_connect mysql_close mysql_query mysql_error mysql_select_db mysql_affected_rows mysql_fetch_array mysql_fetch_field mysql_fetch_row mysql_num_rows mysql_num_fields I don't think they have been *removed* in 7.0, I have created a test webpage where I can call various php files to test operations. So far I have only tested report functions like showing the content of a table etc, and that all works... So I get some access to the database anyway. The error message from the application on Windows when trying to store new data indicate that writing to the database might be a problem. But I have not come to writing yet in my debug tests with the new test form so I don't really know exactly what is going on. >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 will have to look at MySQLi going forward (after finishing the test webpage and used it later. > > >> 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. OK, that is the way I have figured it would be easiest to accomplish too! So I am building a webpage supporting all of the php handlers so I can test each function individually. >> 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. I realize that but I am at the start of troubleshooting so this was a first call for help. It is about 6-7 years since I wrote this system first so I have a bit of catching-up to do... >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. Thanks for the offer! Will do. -- Bo Berglund Developer in Sweden
