I’ve enabled strict error reporting in my WordPress development setup by adding ini_set('error_reporting', E_STRICT); to my wp-config.php file. This has revealed numerous issues throughout the codebase.
The most common problem I’m seeing is deprecated reference assignments like $main_query = &new WP_Query(); which triggers warnings such as “Strict standards: Assigning the return value of new by reference is deprecated”.
Additionally, I’m encountering various other strict mode warnings including:
- Constructor redefinition errors for classes like WP_Object_Cache
- “Creating default object from empty value” notices
- Static method call warnings for functions like WP_Http_ExtHTTP::test()
I’m wondering if there’s a clean approach to handle these issues without simply disabling error reporting. Would removing the reference operators be sufficient, or does this require a more comprehensive solution? I’m open to modifying core files if needed, even at the cost of future upgrade compatibility.
Running WordPress 2.7.1 multisite with PHP 5.2.6 and Xdebug 2.1.0. Has anyone dealt with similar strict mode cleanup challenges?
I’ve hit the same problem with old WordPress installs. Those reference operator warnings are everywhere in older versions because PHP changed how object assignment works. Don’t modify core files - create a custom error handler instead. Set it up to filter out just the E_STRICT warnings while keeping other error reporting intact. Write a function that checks the error message and suppresses only the deprecated reference assignment warnings. You’ll still see real issues but won’t get spammed by legacy code noise. WordPress 2.7.1 is way before modern PHP standards, so these warnings are normal - not critical problems you need to fix right away.
I understand your frustration with those strict warnings in older WordPress installations. Those reference assignment warnings indeed stem from outdated PHP practices. While you might consider removing the ampersands, that can lead to broader issues throughout your codebase. A practical approach is to implement a development-specific wp-config file that sets error reporting to E_ALL & ~E_STRICT during regular work sessions. This way, you can still catch significant errors without being overwhelmed by deprecation notices. As for the constructor and static method warnings, they’re part of the usual legacy code scenario; addressing them manually might not be the best use of time.
totally feel u! wp 2.7.1 is reallly old. those strict warnings can be a pain but not a showstopper. think twice b4 touching core files - it’s best to just hide the strict warnings. using error_reporting(E_ALL & ~E_STRICT) lets u see the important stuff.