Despite the fact that PHP 5 is still not yet supported by all of the webs main hosting companies, the show must go on and this means the ongoing development of PHP 6. The minutes of all the PHP developers meetings are available on the www.php.net website and provide us with a fairly reliable look at what we can expect from PHP 6. The exact location of the minutes is http://www.php.net/~derick/meeting-notes.html. This document is over 83 KB and your most likely not going to read it all, I however have gone through it intermittently over the last few days and although there are a tonne of proposed changes, only three of these proposed changes are likely to be seen as major and having an effect on the general PHP developer population. The three major changes are that register globals, magic quotes and safe mode are all to be ditched.
Register Globals is a PHP directive that when turned on automatically sets all EGPCS (Environment, GET, POST, Cookie, Server) variables as global variables. This means that to use a post form variable you need only reference it by its name and not by its full location within the post array. For example to access the value of a form (submitted by the ‘POST’ method) textfield called firstname with register globals on one would simply use $firstname, however with the register globals directive switched off one would have to use $_POST['firstname'].
Enabling register globals appears then to be more convenient but it is also more of a risk as writing insecure code becomes a lot easier. The reason for this is that with register globals on a developers script can be injected with all sorts of variables including HTML form values and URL get values (which can easily be manipulated by a hacker). With EGPCS variables and internal variables that are defined in the script itself so easily available the programmer can mistakenly open a ‘door’ or a ‘hole’ to a hacker by simply getting confused. A great example of a potential security risk created by bad coding with register globals on is available on http://ie.php.net/manual/en/security.globals.php (see example 29-1 near the top). Although register globals was turned off by default as off PHP 4.2, many webhosts use earlier versions of PHP and others simply manually set the directive to on. To eliminate any risks associated with having register globals on then the development team of PHP 6 decided to get rid of the directive altogether. This means that any scripts which made use of the register globals directive must be rewritten before being ported to PHP 6 as they will not work otherwise.
Next there’s magic quotes, this directive when switched on automagically escapes incoming data (such as POST form values) to any PHP script. This means that you will not have to run addslashes() to prevent MySQL (and others which escape characters with a slash) returning a syntax error when a user enters in a ‘ (for example) in a form textfield. Magic quotes (when switched on) helps beginners code more safely and it’s more convenient as addslashes gets run by PHP without any explicit calls by the coder. The magic quotes directive can however be set to on or off without any influence from within the script itself as input parameters are escaped before the script starts, this means that developers have the cumbersome task of having to first check if it is on and then having to run or not run addslashes() accordingly. Unexperienced programmers could simply assume it is either on or off and code accordingly which will of course effect the portability of an application as obviously some servers will have it switched on and some will have it switched off. In an effort to clean up the code and remove any ambiguity the developers of PHP 6 have decided to remove magic quotes functionality altogether, this is fairly significant and will require code rewriting for those applications and scripts that relied on the magic quotes directive being on (without checking) before these same applications and scripts will work on PHP 6.
Safe mode too is on the way out. PHP safe mode is an attempt to solve the shared-server security problem (according to PHP.net anyhow). When PHP safe mode is on lots of functionality is turned off and other functionality needs a higher degree of authorization (such as UID checks) to run, not only does this frustrate many developers whose hosts have safe mode on but it also gives off the impression that PHP is completely safe with safe mode on, even the most inexperienced PHP coders know this is not the case. The particular section of the developers meeting minutes corresponding to safe mode is found at http://www.php.net/~derick/meeting-notes.html#safe-mode. I don’t believe that the removal of safe mode will require major code changes for applications and scripts to work on PHP 6, please tell me though if I’m wrong on this one (it has been known to happen…)
Although the minutes of the meeting are not final it’s looking like PHP 6, if developed according to them is likely to go through an even longer ‘probationary’ period with webhosts than PHP 5 did (and is still doing) as an awful lot of scripts stand to be broken with any rushed migration to version 6 of this very popular web programming language.