There are a few hosts that do not give you an easy ability to see php errors that might happen. The first step is to edit your wp-config.php in your installation root directory.
Add these lines:
// Tell wordpress to enable error reporting
define('WP_DEBUG', 1);
// Do *not* display errors to the screen
define('WP_DEBUG_DISPLAY', 0);
// Tell wordpress to create a log file
define('WP_DEBUG_LOG', 1);
// Tell wordpress we don't want the extra info
define('E_DEPRECATED', 1);
Next step is to tell WordPress to ‘avoid’ giving you all the damn notices you might be getting. Edit the wp-settings.php file that is in the root of the wordpress installation.
Search for:
if ( defined('E_DEPRECATED') )
error_reporting(E_ALL & ~E_DEPRECATED & ~E_STRICT);
and replace the error_reporting line with this:
error_reporting(E_ALL & ~E_DEPRECATED & ~E_STRICT & ~E_NOTICE);
This will tell the debug.log to not record anything that’s deprecated strict or notices.
Once you do this, if any errors occur you will find in the wp-content directory a file called debug.log, then you can look at that log for what the error is and fix it. (or tell someone who can fix it).
/wp-content/debug.log
- Phil (Frumph)
Thanks for the ideas. I’m not a WordPress expert by any means, but I wonder if this is the best way of doing it. Any changes to wp-settings.php will get lost during an upgrade, and also defining E_DEPRECATED (or redefining in the case of PHP 5.3 or newer) to have the same value as E_ERROR (1) is asking for trouble.
the ~ before the E_DEPRECATED means to ‘not include’ in the error reporting
I know that, but it only works if it’s correctly defined as the value 8192:
http://www.php.net/manual/en/errorfunc.constants.php
It doesn’t work in your case because you redefined E_DEPRECATED to be 1, which is the same value as E_ERROR. So you are doing a bitwise AND (&) with ~1, which results in hiding all fatal runtime errors, rather than hiding deprecation warnings. That’s definitely a bad idea!
Well thats the thing, it does work on my machine, it’s currently creating a debug.log with *only* php errors inside of it.
Also, WP doesn’t currently let you hide E_DEPRECATED warnings in a clean manner, so I reopened this ticket with a new proposal to solve it:
http://core.trac.wordpress.org/ticket/11987
E_DEPRECATED is a PHP constant, new in PHP 5.3, when PHP introduced deprecated warnings. If it exists, we exclude E_DEPRECATED warnings, as WordPress does a few things that is deprecated in 5.3 to ensure PHP 4 compatibility.
(E_STRICT is excluded from E_ALL, but in PHP 6, it is included. Hence why we also include that if PHP 5.3 or greater.)
WP_DEBUG_DISPLAY == false does not hide any errors, it simply doesn’t force them to be displayed (and thus it falls back to the server setting). They are forced on when WP_DEBUG is true.
The inline documentation for this was confusing and in some cases incorrect, so I wrote up new documentation a few days ago.
If you *don’t* want errors displayed, as the example shows, then do this:
define(‘WP_DEBUG’, true); // Turn on WP debug mode
define(‘WP_DEBUG_DISPLAY’, false); // WP won’t force-display them
define(‘WP_DEBUG_LOG’, true); // Log them to wp-content/debug.log
ini_set(‘display_errors’, 0 ); // Set the global config display_errors to off.
Hope that all makes sense.
I also noticed you suggested a core hack. I’d suggest instead forgoing WP_DEBUG all together — the whole point there is to get E_NOTICEs, which includes WordPress-specific deprecated warnings and debug material.
Instead, just let WordPress set its standard non-debug error_reporting level and do exactly what WordPress would do to turn on a log:
ini_set( ‘display_errors’, 0 );
ini_set( ‘log_errors’, 1 );
ini_set( ‘error_log’, WP_CONTENT_DIR . ‘/debug.log’ );
Hope that helps!
In my shared host, all the WP errors go to file errors.log without any hack to config.php file. But I think this post is nice for some situation, thank you.