What will break once PHP6 is released?

Question

PHP6 haven't been released yet. But because of the majority of websites that uses PHP, once PHP6 is released, programmers would support that version.

PHP6 can break code that works on PHP4 and PHP5. The purpose of this question is to have a nice list of what PHP programmers should be aware of before PHP6 is released. This can help PHP programmers be ready for PHP6.

What will break when PHP6 once released?

Answer 1

Code depending on register globals. ( Should be gone already, but if you're migrating from php4... well. you'll be in for a shock )

Answer 2

Code depending on Magic GPC Quotes ( Supposed to start WARNING us as of 5.3, and should be gone by 6 )

Answer 3

Stuff needing "Safe Mode"

Answer 4

PHP 4 stuff like: $HTTP_GET_VARS and $HTTP_POST_VARS, use $_POST and $_GET instead if you weren't already doing that.

Also in the future the following things are likely to change:

• Open and closing tags (<% %> <? ?>) may be removed. Use <?php and ?> instead.

• datebase functions(mysql_*) will be replaced by the PDO library eventually.

Source: http://www.php.net/~derick/meeting-notes.html

Answer 5

they are also removing support for dynamic breaks, ereg and call time pass by reference.

Answer 6

{} for string offsets is deprecated (but will not be removed for 6.0 though, according to the PHP6 TODO list). Instead, [] is recommended for accessing characters in a string - since it's already the only way to access array members.

So, given $foo is a string, you should prefer $foo[1] to $foo{1}.

Answer 7

This one is less obvious, but I just discovered. Allegedly, __autoload will now get passed fully qualified names to load, complete with namespace/class.

So any existing code that utilizes autoloading will have to be partially re-written to accommodate this fact.

Answer 8

Here is a collection of PHP6 specific changes that can break PHP5 code.

Answer 9

Obviously all deprecated constructs will break (they're deprecated for a reason).

• always use php.ini-recommended (default php.ini-dist is intended for compatibility with poor code)
• always develop with all error reporting enabled, including E_STRICT and E_DEPRECATED

There's one non-deprecated thing that may cause problems: treating of strings as binary blobs.

• use UTF-8, and never assume byte = character.

Strings will behave differently depending on where they come from – they can be interpreted as meaningless bytes (e.g. an image you've stuffed into database) or characters in specific encoding. If your application is ignorant about encodings, you'll have problems.