I apologize for the delay in responding.
You could try setting the error_reporting in php.ini directly.
I have run across some plugins that temporarilty change the error_reporting level while they perform some function then restore the value. I don’t remember which plugins but that may be why your notices are still appearing in the log file.
If you’re getting a ton of notices then I recommend cloning the site to a dev or local server, disabling all plugins, selecting a default theme like TwentySixteen, and activating plugins one by one until you encounter the problem you’re trying to isolate.
Contact me at wpmission.com if you want any help. I actually enjoy this kind of detective work.
Hi Chris
Thanks for responding
Yeah I already tried changing the error_reporting value in the php.ini file – this had no effect. The implication from other strands I have been looking at is that the WP_DEBUG is not affected by error_reporting settings, but I could be wrong.
There is really no clear guidelines about this anywhere that I can find. It means that WP_DEBUG is pretty much useless- there is at leats one plugin firing off 50 NOTICEs a second and filling the logs…
Maybe if you can check to see if error_reporting level effects WP_DEBUG output on a setup you have?
It seems to me that the biggest problem with WordPress is a lack of debugging tools – everytime I upgrade, something breaks (I am running a multisite with a fair number of sites on it). These are all production sites and the only response I get from anywhere is to switch off all the plugins, set the theme to 20nn, blah blah…. This is not an option – I just need to be able to see what is going wrong and where, but I reach a dead-end…
Sorry for the rant π
I just discovered something that may help you.
Calling _doing_it_wrong will use the native PHP function trigger_error with E_USER_NOTICE by default which starts its log message with “PHP Notice:” just like E_NOTICE, possibly making you think that your error reporting setting is not taking effect.
To verify that run-time notices were disabled, I added the function from this thread to var_dump the reporting level (with E_ALL exploded) and it matched the error_reporting( E_ALL & ~E_NOTICE ); in my mu-plugin.
I then set error_reporting( E_ALL & ~E_NOTICE & ~E_USER_NOTICE ); and the log entries stopped.
So, it would seem you have a plugin that is calling _doing_it_wrong a lot. Disabling those minor user notices should help trim down your log file while you work on the major issues.
In my case, Pods is calling is_user_logged_in before bbPress thinks it should so bbPress says _doing_it_wrong. I’m not sure how to solve that.
Hope that helps.
You can also disable the _doing_it_wrong notices:
add_filter( 'doing_it_wrong_trigger_error', '__return_false' );
Here’s another option for the excessive _doing_it_wrong‘s that will write only the E_USER_NOTICE‘s to a separate log file.
if ( WP_DEBUG ) {
error_reporting( E_ALL & ~E_NOTICE );
}
function secondary_error_handler( $errno, $errstr, $errfile = '', $errline = 0, $errcontext = array() ) {
$entry = '[' . date( 'd-M-Y H:i:s e' ) . '] ';
$entry .= $errstr . PHP_EOL;
$entry .= $errfile . ':' . $errline . PHP_EOL;
$entry .= str_repeat( '-', 10 ) . PHP_EOL;
error_log( $entry, 3, WP_CONTENT_DIR . '/doing-it-wrong.log' );
// must return true to bypass normal error handler
return true;
}
set_error_handler( 'secondary_error_handler', E_USER_NOTICE );
http://php.net/manual/en/function.set-error-handler.php
http://php.net/manual/en/function.error-log.php
(edited)
Thanks Chris
That looks good… I can see that I can edit the functions.php file and add the filter, but any ideas how I can do this for all sites on a multisite? Would I have to do something to the WP core?…
Cheers,
Andy
Make a new mu-plugin for it or add it to your mu-plugin that has the error_reporting line if you’re still using that.
doh! of course! Thanks again…
Andy