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.
