View RSS Feed

Behind The Code, with DrByte

Is your plugin code safe to use on PHP 5.3?

Rating: 109 votes, 4.62 average.
(Also see the posts about readiness for PHP 5.4 and 5.5 and 5.6 and readiness for PHP 7.0, 7.1, 7.2, 7.3 )

When PHP 5.3 was released, some older features were retired (some removed, some "deprecated", etc).

And if your custom code or your addons/plugins are using those features, things will break and you'll encounter the dreaded "white screen of death".

What do you need to change?

Here's the list I generally follow, along with how I usually remedy it:

ereg('searchtext', 'a_string', $optionalVar) becomes preg_match('/searchtext/', 'a_string', $optionalVar)

eregi('searchtext', 'a_string', $optionalVar) becomes preg_match('/searchtext/i', 'a_string', $optionalVar)

ereg_replace('searchtext',.....) becomes preg_replace('/searchtext/',....);
or if the 'searchtext' parameter is just a single character then just change ereg_replace with str_replace

eregi_replace('searchtext',.....) becomes preg_replace('/searchtext/i',....);

split('x', $var)
- if 'x' is a single character, then split( becomes explode(
- if 'x' is multiple characters, then split('chars', $var) becomes preg_split('/chars/', $var)

"short open tags"
Normally PHP files start with a <?php tag
or individual PHP statements start with <?php
But some commonly-used "shortcuts" require the use of "short open tags", such as just <? instead of <?php.
However, in PHP 5.3 the "short open tags" support is turned off by default, and if your code uses these "short" tags, you will cause errors, resulting in a blank page.
So, if your code uses <? followed by a space, change those to <?php

(NOTE: If it uses <?= then that's equivalent to <?php echo and is okay in PHP 5.4 and newer)

That's the bulk of it. Making those changes should accommodate the majority of issues you might encounter when moving from PHP 5.2 to PHP 5.3

If you're working with very old code, or stuff that was inherited or ported from other systems, the following could be relevant to you as well:

Some very old things
The following session-related functions have been obsolete for quite awhile. Zen Cart has never used them, but people using old code converted from old OSC addons might still try to make use of them.
- session_register()
- session_unregister()
- session_is_registered()
Instead, write new logic to handle sessions in a contemporary way.

$HTTP_POST_VARS and $HTTP_GET_VARS and $HTTP_SERVER_VARS, etc are all officially deprecated. Also never used by Zen Cart, but used extensively in old OSC addons. They should be replaced with their $_POST, $_GET, $_SERVER, etc superglobal equivalents. And never need to be declared as globals. See below.

Global vars
Another pattern I've seen carried forward from old OSC addons is the choice to explicitly declare $_POST or $_GET as global inside a function/method. But, $_POST and $_GET (and other $_XXXXX superglobals) are already global.
So, in a PHP statement that starts with global and includes one of these superglobals, that superglobal can be removed from that statement. And if no other variables are mentioned, the whole statement can be removed.
ie: global $var1, $_POST, $var2; becomes global $var1, $var2;
or global $_POST; would just be removed altogether.

Also handy:
The abbreviated ternary operator ?: was added.

On github I've posted a gist containing some regex patterns which can be used to identify incompatible old PHP code

Related reading:

Submit "Is your plugin code safe to use on PHP 5.3?" to Digg Submit "Is your plugin code safe to use on PHP 5.3?" to Submit "Is your plugin code safe to use on PHP 5.3?" to StumbleUpon Submit "Is your plugin code safe to use on PHP 5.3?" to Google

Code Tips
Zen-Cart, Internet Selling Services, Klamath Falls, OR