Upgrading PHP FAQ
What is this forum for?
You or your host have upgraded PHP and, despite your best efforts, the site has broken, and you can't find what the problem is. Or maybe you're thinking of upgrading, and want some idea of places where the site might break if you do.
A bit of history, and where to find out what happened.
PHP's developers have tried very hard over the years to maintain backward-compatibility, so that scripts written for older versions of PHP will continue to run in newer ones, but they can never be 100% succesful. They give advance warning of changes that can break older scripts, and the bigger the change in versions the bigger the version number change. A list of backward-incompatible and other significant changes are chronicled in the history section of the manual.
The transition from PHP4 to PHP5 was very big: not just in the way objects were passed to functions was completely overhauled to match the way other languages did it, but when PHP 5.0.0 was released in 2004 development of PHP 4 basically stopped. See migration5 for an almost full list.
The above list does miss a couple of things, basically because it focusses more on things in PHP4 that don't work in PHP5 instead of the other way around (which makes sense when you're migrating). In PHP 4, $foo->bar()->baz() was bad syntax; in PHP 5 it's legal (as long as $foo->bar() returns an object with a baz() method!). Also, in PHP 5 it's possible to write foreach($array as &$element) to access each element of an array by reference (instead of having to write foreach($array as $key=>$element) and using the key to reassign the new value back into the array). But there is a significant gotcha to this: after the loop finishes, $element will still exist, and it will still be a reference to the last element in the array! If you happen to use the same $element variable later in the same scope, there's a good chance you'll clobber your array. unset will detach the reference.
The transition from 5.0 to 5.1 shook out a lot of the bugs found during use of 5.0, and introduced a number of features that had been put on hold. Backwards compatibility was maintained. An overhaul to date/time handling was introduced, and PDO (the recommended database interaction interface: mysql_query() is just so last century) was enabled by default. migration51
Version 5.2 made a few changes that were not compatible with 5.1 and a few more rough edges were smoothed out (like having __toString() work as expected instead of only in a couple of special situations). Mostly, however, it was devoted to additional functionality.
migration52. Migrating from 5.2 to 5.3 (migration53) gives you additional significant features like closures and namespaces (mmm ... closures ...), at the expense of a few backward incompatibilities (e.g., namespace is now a reserved word).
Migrating to 5.4 (which, not surprisingly, is outlined in migration54) is a similar jump. It removes a lot of stuff that should have already been removed from any software that is being maintained - things like magic_quotes and safe_mode - are gone. It has also adds a number of refinements to the syntax, and things called traits to ease code reuse across class hierarchies without requiring inheritance.
Speaking of things that are gone, the MySQL extension is now deprecated and notice has been given that the mysql_* functions will be removed in the future; they should not be used in any new software and existing software that uses them should be getting modified now if you don't want to be left stranded .
Migrating from 5.5 to 5.6 is simpler (migration56); there are only a few things that might break, but mostly only in somewhat esoteric situations. A few more things have been deprecated (most notably for most users, the use of $HTTP_RAW_POST_DATA). Of greater interest is what has been added: syntax for exponentiation, and a cleaner way of specifying variadic functions (instead of a lot of fiddling around with func_get_args); namespaces can use functions and constants from other namespaces as well as classes; constants can now be (constant) expressions instead of merely literals; and there is now an inbuilt debugger as well as server.
If PHP is supposed to be so backward compatible, why has my site suddenly stopped working?
Before ripping into your code or throwing it out, check your configuration: almost certainly there will be differences in the php.ini file that your old installation had and the new one. If you still have the old habit (pre-XML days) habit of writing "<?" instead of "<?php" you'll want to know that php.ini-recommended has short_open_tag turned off. Similarly, if you're still in the bad habit of using plain variables for submitted form fields and session data, instead of the $_POST, $_GET, $_REQUEST, and $_SESSION arrays that were introduced in PHP 4.1, the default setting of register_globals in both php.ini-recommended and php.ini-dist is off. In both cases you could just turn them on if you needed to, but if you don't take the opportunity to upgrade your code you'll be left even further behind (if you continue to insist on having register_globals turned on you will not be able to use PHP 5.4).
So: check all the obvious things. Is it plugged in? Is it turned on? Is it installed? Compare your old php.ini with the new one. (Windows users: are all the extension .dll's enabled that should be enabled?) For each difference you find (like I say, you'll almost certainly find some), find out why they are different and how changing that setting affects PHP's behaviour. There are two places to find out information about each .ini setting: the list of ini settings is one starting point, and the other is the documentation contained in the php.ini file itself. After checking php.ini, remember that many of the settings can be further modified by .htaccess files and the like: if you upgraded your websever at the same time (which is not uncommon), you will want to walk yourself through any configuration changes there too.
"Warning: Unknown: Your script possibly relies on a session side-effect which existed until PHP 4.2.3. Please be advised that the session extension does not consider global variables as a source of data, unless register_globals is enabled. You can disable this functionality and this warning by setting session.bug_compat_42 or session.bug_compat_warn to off, respectively" Whaarrrgarbblll?!
Best Practice to avoid this error message:
- Upgrade to PHP 5.4.
Second Best Practice if that's infeasible in the short term:
- Turn the php.ini setting "session.bug_compat_42" off.
- Don't use session_register() and session_unregister() to work with session variables any more. Use the $_SESSION array.
Last edited by Weedpacket; 11-02-2014 at 06:45 AM.
is this work from php 4 to 5?
The post was written to accommodate several different migration paths. To find out if that is one of them, read the post.
Originally Posted by oneonesip
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)
Tags for this Thread