1 post tagged “drupal”

View other items tagged “drupal:” Photos, Audio, Videos, Books or Links. View “drupal” on Vox.

PHP Fatal error: Non-static method FOO::FOO() in (...)

Mar 3, 2008
Post a comment

After bumping up the PHP 5.2.x on one of our servers Friday night, I got reports from some of our clients that certain websites would not work anymore. After investigating this problem, I found that ~~most~~ all of ~~the~~ my problems were in Joomla, Mambo and Drupal plugins/extensions which those people used.

Of course no offense to those three systems (and their developers and people using them ;-)), but I googled the error and found that many people reported similar issues on support forums of those three. At least the top results suggest that. On the list of offenders are also shops such as the very popular OSCommerce. Anyway - just let me stress this again - no offense meant (but you need to fix your code :-P).

On to the fix.

The offending code, could look like (this example is from Mambo's AKO_Book extension):

MENU_Default::MENU_Default();

Digging into this, you will probably find a class that would look similar to this:

<?php
class MENU_Default {
function MENU_Default() {
// do something
}
}
?>

At first I (paniced and) thought that effectively all static calls without a "static" keyword are broken in PHP5.2.5. But after investigating and raising a bit of havoc on IRC and internals@ (Sorry!), Bjori shed some light into/onto my confusion and figured out that this is just a static call to the constructor of a class.

And calling the constructor of a class directly is just wrong. And static calls to the constructor have not been allowed since 5.0.0. (I am not sure why no one reported issues before but I guess since I wrote our customers that the update was smooth, they just had to dig up something. :-))

The fix is simple and should have been there to begin with:

// currently:
MENU_Default::MENU_Default();
// replace with:
new MENU_Default();

(By the way - it really helps if you set log_errors = On in your php.ini or via php_value in your <VirtualHost> because you are then able to track all errors without reproducing them a dozen times, which is sometimes hard because they might be hidden in a wizard-like process and customers are generally not very good at describing what they did to get the error - they will just say, "It doesn't work!".)

Issues like that are to be traced back to PHP4's more 'lax interpretation of OO. Even on PHP4 coders should have written the latter, but no one forced them to. And because I know the pain of upgrading a system like Joomla/Mambo, Drupal and others - especially once you put a lot of customization in it, I hope this helps someone out there fix their issues.

Debatable is still if any version of PHP5 should really consider this to be a fatal error. Or if this call should be subject to E_STRICT which was introduced in PHP5 to ensure forward compatibility of code, which sounds like the best fit for this. I believe in the E_STRICT way.

I know and understand that there are probably about a dozen technical reasons to E_FATAL instead, but in my (very) humble opinion to make people aware with E_STRICT and to add a note that E_STRICT will eventually turn into E_FATAL in PHP6 would have been the right path to persue here.
Less breakage and more awareness - they make the "we told you so"-argument more valid. Everything but that just adds to the user's general fear to adopt PHP5 and to finally get rid off PHP4.

On a side note - I feel that I need to add that we only allow those old versions to run because we patched them for our clients and because we use an application firewall called mod_security. mod_security is customizable through rule sets and we constantly update them to combat known attacks (e.g. XSS, comment spam, ...).

If you don't have those resources available to yourself, you need to consider an update of the PHP application more sooner than later.