Support Start > Web Hosting Technical Information > Installing and Configuring Custom Scripts > PHP Scripts > Troubleshooting PHP 5.3 Upgrades

This page explains how to troubleshoot any problems you experience when upgrading from PHP 5.2 to PHP 5.3.

Note that the PHP authors also offer a comprehensive guide to migrating from PHP 5.2 to 5.3.

What should I do if my scripts stop working?

If you have any difficulties after switching from PHP 5.2 to PHP 5.3, you should first make sure that all the scripts you use have been upgraded to their latest available version. Outdated scripts are the main cause of problems: for example, versions of Zen Cart and Joomla that are more than five years old can have problems with PHP 5.3 (but those versions also have many other security problems that make upgrading vitally important).

If upgrading your scripts doesn’t help, try the following steps in the “PHP Settings” section of our My Account control panel to see if they fix it. Try them one at a time and test your PHP scripts after each change, undoing the change if it doesn’t help (don’t try them all at once).

1. Try adding magic_quotes_gpc = On to the “Custom php.ini Settings”. This makes PHP 5.3 work more like older PHP versions. If this helps, see the “Support for magic_quotes_gpc disabled” section below for details about how to permanently fix your scripts.
2. Try adding display_errors = On to the “Custom php.ini Settings”. This also makes PHP 5.3 work more like older PHP versions. If this helps, you can leave it on (the “Errors show only in the logs, not on the page itself” section below explains more).
3. Try unchecking the Use eAccelerator option. If this helps, you can leave this setting off, although your script will run a little more slowly than it could if it were compatible with eAccelerator.
4. Try unchecking the Use FastCGI option. If this helps, you can leave this setting off, although your script will run much more slowly than it could if it were compatible with FastCGI.
5. Try setting PHP back to Use PHP 5.2.17. If this helps, and you’re sure you’re using updated scripts, please contact us right away for assistance.

The rest of this page explains some particular PHP 5.3 upgrade issues we’ve seen in technical detail:

• Support for magic_quotes_gpc disabled
• Current working directory is different in callback functions
• Obsolete versions of Joomla don’t display menus
• Warnings about deprecated directives start appearing
• Errors show only in the logs, not on the page itself

However, this is mostly just so we have a chance to document anything unusual. It’s very unlikely that any of these things will happen to you.

Support for magic_quotes_gpc disabled

PHP used to include a feature called magic_quotes_gpc that some scripts relied on. Script authors have been warned against using it for a long time, and the feature was disabled by default in PHP 5.3.

As an interim step, the PHP authors have provided a temporary php.ini option you can enable in PHP 5.3 to make the magic_quotes_gpc work again and buy you some time (although it won’t work in PHP 5.4). You can do this by adding this line to your php.ini settings:

magic_quotes_gpc = On

If you add this, be sure to update your script as soon as possible so that it works without magic_quotes_gpc being enabled. If you leave “magic_quotes_gpc = On” in your php.ini with the future PHP version 5.4, it will cause all your PHP scripts to fail until you remove the setting.

Current working directory is different in callback functions

PHP 5.3 uses a different “current working directory” in shutdown functions than in other code, which can lead to problems if you don’t expect that.

For example, the following code prints the same directory twice under PHP 5.2, but prints different directories under PHP 5.3:

<?php

function callback(&$buffer)
{
  $buffer .= getcwd();
  return $buffer;
}

echo getcwd() . '<br>';
ob_start('callback');

This causes trouble if you’re using relative paths for something like file_get_contents() in callback functions created by ob_start() or register_shutdown_function(), because they’re “relative” to the current working directory. It generates an error message like “PHP Warning: file_get_contents(something): failed to open stream: No such file or directory”.

This is a bug (or at least an inconsistency) in different versions of PHP, as described by others in various places:

• https://bugs.php.net/bug.php?id=24420
• http://www.php.net/manual/en/function.register-shutdown-function.php#92657
• http://www.php.net/manual/en/function.getcwd.php#43451

The solution is to avoid using relative paths in a shutdown function. Always use absolute paths if you can. Something like $path = dirname(_FILE_) . '/'; works.

Obsolete versions of Joomla don’t display menus

If you’re using a very old version of the Joomla software, it has a bug that causes it not to display menus with PHP 5.3, and also has a separate bug that sometimes causes some pages to incorrectly generate 404 errors when using "search engine friendly URLs". The solution is to upgrade to the latest version of the Joomla series you’re using (which you should do anyway, because Joomla versions that have this problem are also vulnerable to “hackers” due to security bugs).

Warnings about deprecated directives start appearing

If you see any new warnings that begin with “PHP Deprecated”, that’s probably because you’ve enabled extra “error_reporting” in your php.ini settings, using something that looks like like one of these two lines:

error_reporting = -1
error_reporting = E_ALL

That setting makes more warnings appear with PHP 5.3 than with PHP 5.2.

You should either delete that line from your php.ini settings completely — or, if you want to be sure that you see every PHP error except these deprecated warnings, change it to:

error_reporting = E_ALL & ~E_DEPRECATED

That will suppress any “PHP Deprecated” warnings.

Errors show only in the logs, not on the page itself

Production PHP servers no longer show errors in the browser by default for security reasons, as described on this page. As it says, the option to show errors in the browser “is a feature to support your development and should never be used on production systems (e.g. systems connected to the internet).”

So by default, errors now appear in logs that only you can see.

You can add this line to your php.ini settings if you prefer to see them the old way:

display_errors = On

But keep in mind that if the error messages include any sensitive information (such as passwords), doing this might allow other people to see that information.

Interestingly, enabling “display_errors = On” also has another side-effect: it can change the HTTP status code that PHP sends to the Web server from 500 to 200 if the script has a problem. In some browsers, notably Firefox, this can mask PHP errors and make real (though possibly incomplete) page content appear instead of a browser error message.

If adding “display_errors = On” fixes a problem you see after upgrading, it does mean that your script has some kind of error — but it’s probably reasonable to leave the setting enabled to avoid the problem.