Hey folks, I’m working on a WordPress project and I’ve cranked up the error reporting to E_STRICT in my wp-config.php file. Now I’m seeing a bunch of warnings about stuff like passing values by reference and other deprecated practices.
For example, I’m getting this error:
Strict standards: Assigning the return value of new by reference is deprecated in /htdocs/site/wp-settings.php
This happens with code like $wp_the_query = &new WP_Query();
I’m wondering if I can just remove the & symbol without breaking things. Or do I need to do something more complicated?
I’d rather not turn off error reporting completely. That feels like sweeping the problem under the rug.
I’m using WordPress 2.7.1 mu and PHP 5.2.6 with Xdebug 2.1.0.
Has anyone dealt with cleaning up these kinds of warnings in WordPress core files? I’m okay with modifying them, even if it means I can’t easily upgrade later. Any tips or experiences you can share?
hey there, i’ve run into this too. removing the & is usually fine for newer php versions, but be careful with core files.
instead, try using a custom error handler to log strict warnings without breaking stuff. something like:
set_error_handler(function($errno, $errstr) {
if ($errno === E_STRICT) {
error_log($errstr);
return true;
}
return false;
});
this way u can track issues without halting everything. hope that helps!
I’ve dealt with similar issues in WordPress development, and it can be a real headache. In my experience, simply removing the ‘&’ symbol is usually safe for newer PHP versions, but it’s not always that simple with WordPress core files.
One approach I’ve found effective is to create a custom error handler that logs these strict warnings without halting execution. This way, you can track issues without breaking functionality. Something like:
set_error_handler(function($errno, $errstr, $errfile, $errline) {
if ($errno === E_STRICT) {
error_log("Strict: $errstr in $errfile on line $errline");
return true;
}
return false;
});
This lets you keep strict error reporting on while giving you more control over how it’s handled. You can then review the log periodically and address issues systematically without disrupting your development workflow.
As for modifying core files, I’d caution against it unless absolutely necessary. It can make upgrades a nightmare. Instead, consider using hooks and filters to override problematic functions where possible.
Having worked extensively with WordPress, I can relate to your frustration with strict error reporting. While removing the ‘&’ symbol might work in some cases, it’s not always the best solution for core files.
Instead, consider using a compatibility plugin that addresses these deprecated practices without modifying core files. This approach maintains easier upgradeability while reducing errors.
Alternatively, you could create a custom mu-plugin that uses the ‘plugin_loaded’ hook to dynamically replace problematic functions with updated versions. This method allows you to tackle specific issues without touching core files directly.
Remember, these strict standards warnings don’t usually affect functionality, so prioritize addressing them based on their impact on your development process. Balancing error reporting with practical development needs is key in WordPress projects.