I am moving my sites over to a new server. They are written in PHP4. Are there any compatibility issues with running PHP4 code on a PHP5 server?The only one I'm certain of is the get_class() function returns the name in it's original notation, i.e. upper/lower case and can cause conflicts if you have named the class one way and call it another.www.php.net is a bible... if you had looked carefully, you would have found this :
<!-- m --><a class="postlink" href="http://www.php.net/manual/en/migration5.phpThere">http://www.php.net/manual/en/migration5.phpThere</a><!-- m --> are absolutely loads and loads of issues.
You cannot reasonably expect an application to go from 4 to 5 (or indeed ANY version to any other) without problems.
All applications must be absolutely rigorously tested when doing such a migration. Lots of apparently small things can introduce bad bugs (reference handling, for instance).
Generally speaking anything which uses OO is going to fail when going PHP4 to PHP5, because the object model is completely different.
A migration like this is nontrivial and will take a lot of developer time to validate.
MarkAs someone who is in the process of this migration. I shall tel you this bluntly
Expect LOTS of issues. and i mean LOTS.
unless you adhered to PHP5 coding conventions while writing your current site, you will need to go through your code line by line to ensure it works. I have spent weeks doing this for a migration from PHP4 to PHP5. A lot of differences were simple quote locations that completely killed the entire page.
this is how i have upgraded.
Installed a new platform with PHP5 and SQL5
Copied the Databases and Website to the test bed.
went through page by page by page modifying and making sure all pages worked exactly as necessary.
Backed Up live database
Downed Live server.
upped new server with PHP5 and SQL5
Restored Live data
Copied upgraded pages to new live server.
Total downtime to end user? 5 minutes.
Carefull to note though. if you do this method. While you're coding anything on the test server, you can't make changes to the live server or they'll never show up again unless you rewrite them as well on the test server.
AlsoI made no changes to the databases or the data structures so that i could easily swap the data to the new live server without the need to reconvert anythingIt seems like the vast majority of PHP4-to-PHP5 problems I see are due to the legacy code using techniques that are not supported by the new server's configuration settings, not an integral incompatibility between versions. Most common is the dependence on the register_globals setting, which had its default setting changed from ON to OFF around PHP 4.4, I think. Also, code which uses short_open_tags ("<?" and "<?=") often fails when the new server has that option turned off (which is a good idea, so as to avoid confusion with XML tags).
Of course, none of us use such deprecated techniques, so it will only be legacy code we didn't write that will have those sorts of problem, right?
It seems like the vast majority of PHP4-to-PHP5 problems I see are due to the legacy code using techniques that are not supported by the new server's configuration settings, not an integral incompatibility between versions. Most common is the dependence on the register_globals setting, which had its default setting changed from ON to OFF around PHP 4.4, I think. Also, code which uses short_open_tags ("<?" and "<?=") often fails when the new server has that option turned off (which is a good idea, so as to avoid confusion with XML tags).
Of course, none of us use such deprecated techniques, so it will only be legacy code we didn't write that will have those sorts of problem, right?
I agree, also get people scared they will never upgrade and php4 will be alive forever. Though watch the xml library usage as there were a lot of changes, a lot of the 4 ones were marked experimental. The <!-- m --><a class="postlink" href="http://alexandre.alapetite.net/doc-alex/domxml-php4-php5/">http://alexandre.alapetite.net/doc-alex ... php4-php5/</a><!-- m --> sorts a lot of them out.It's really all about testing. Even though the majority of code will probably work (depending on what techniques you used), there will be lots of bugs.
If your existing applications have any regression tests, run them ALL.
If they don't have regression tests, then you're in more trouble. Devise some way to get decent code coverage on testing.
At an absolute minimum:
* Load every distinct PHP page in the application
* Submit every form that you can at least once
But more desirably:
* Achieve decent function coverage throughout the application
I appreciate that this is difficult, and I know of no test cover measurement tools for PHP (Perhaps you can knock something up which uses the output of APD profiler?).
---
Another issue is that the worse the quality of the applications in PHP4, the harder it will be to validate that they're working in PHP5 - for example, if you run with error_reporting(E_ALL) (which you should, ALL the time), and you run through your validation tests on PHP4, how many notices do you get on the error log?
A well constructed application should aim for zero E_NOTICEs under normal operation. However, I have seen plenty which emit more than that on a regular basis.
Does the application use the @ operator or error_reporting to suppress errors in many places? If so, things which previously worked on PHP4 could fail on PHP5, but generate absolutely no notices, thus failing silently (or perhaps apparently working).
Markwhich had its default setting changed from ON to OFF around PHP 4.4, I think. 4.2, but don't feel bad; it was five years ago...
<!-- m --><a class="postlink" href="http://www.php.net/manual/en/migration5.phpThere">http://www.php.net/manual/en/migration5.phpThere</a><!-- m --> are absolutely loads and loads of issues.
You cannot reasonably expect an application to go from 4 to 5 (or indeed ANY version to any other) without problems.
All applications must be absolutely rigorously tested when doing such a migration. Lots of apparently small things can introduce bad bugs (reference handling, for instance).
Generally speaking anything which uses OO is going to fail when going PHP4 to PHP5, because the object model is completely different.
A migration like this is nontrivial and will take a lot of developer time to validate.
MarkAs someone who is in the process of this migration. I shall tel you this bluntly
Expect LOTS of issues. and i mean LOTS.
unless you adhered to PHP5 coding conventions while writing your current site, you will need to go through your code line by line to ensure it works. I have spent weeks doing this for a migration from PHP4 to PHP5. A lot of differences were simple quote locations that completely killed the entire page.
this is how i have upgraded.
Installed a new platform with PHP5 and SQL5
Copied the Databases and Website to the test bed.
went through page by page by page modifying and making sure all pages worked exactly as necessary.
Backed Up live database
Downed Live server.
upped new server with PHP5 and SQL5
Restored Live data
Copied upgraded pages to new live server.
Total downtime to end user? 5 minutes.
Carefull to note though. if you do this method. While you're coding anything on the test server, you can't make changes to the live server or they'll never show up again unless you rewrite them as well on the test server.
AlsoI made no changes to the databases or the data structures so that i could easily swap the data to the new live server without the need to reconvert anythingIt seems like the vast majority of PHP4-to-PHP5 problems I see are due to the legacy code using techniques that are not supported by the new server's configuration settings, not an integral incompatibility between versions. Most common is the dependence on the register_globals setting, which had its default setting changed from ON to OFF around PHP 4.4, I think. Also, code which uses short_open_tags ("<?" and "<?=") often fails when the new server has that option turned off (which is a good idea, so as to avoid confusion with XML tags).
Of course, none of us use such deprecated techniques, so it will only be legacy code we didn't write that will have those sorts of problem, right?
It seems like the vast majority of PHP4-to-PHP5 problems I see are due to the legacy code using techniques that are not supported by the new server's configuration settings, not an integral incompatibility between versions. Most common is the dependence on the register_globals setting, which had its default setting changed from ON to OFF around PHP 4.4, I think. Also, code which uses short_open_tags ("<?" and "<?=") often fails when the new server has that option turned off (which is a good idea, so as to avoid confusion with XML tags).Of course, none of us use such deprecated techniques, so it will only be legacy code we didn't write that will have those sorts of problem, right?
I agree, also get people scared they will never upgrade and php4 will be alive forever. Though watch the xml library usage as there were a lot of changes, a lot of the 4 ones were marked experimental. The <!-- m --><a class="postlink" href="http://alexandre.alapetite.net/doc-alex/domxml-php4-php5/">http://alexandre.alapetite.net/doc-alex ... php4-php5/</a><!-- m --> sorts a lot of them out.It's really all about testing. Even though the majority of code will probably work (depending on what techniques you used), there will be lots of bugs.
If your existing applications have any regression tests, run them ALL.
If they don't have regression tests, then you're in more trouble. Devise some way to get decent code coverage on testing.
At an absolute minimum:
* Load every distinct PHP page in the application
* Submit every form that you can at least once
But more desirably:
* Achieve decent function coverage throughout the application
I appreciate that this is difficult, and I know of no test cover measurement tools for PHP (Perhaps you can knock something up which uses the output of APD profiler?).
---
Another issue is that the worse the quality of the applications in PHP4, the harder it will be to validate that they're working in PHP5 - for example, if you run with error_reporting(E_ALL) (which you should, ALL the time), and you run through your validation tests on PHP4, how many notices do you get on the error log?
A well constructed application should aim for zero E_NOTICEs under normal operation. However, I have seen plenty which emit more than that on a regular basis.
Does the application use the @ operator or error_reporting to suppress errors in many places? If so, things which previously worked on PHP4 could fail on PHP5, but generate absolutely no notices, thus failing silently (or perhaps apparently working).
Markwhich had its default setting changed from ON to OFF around PHP 4.4, I think. 4.2, but don't feel bad; it was five years ago...