Blog

Ignoring errors from third party WordPress plugins while developing in debug mode

Screen Shot 2014-03-02 at 11.25.23 AMHere’s the problem: I want to develop in debug mode (i.e. WP_DEBUG set to “true”) to catch all the notices, warnings, and strict standard errors in my theme and plugin code, but several of the third party plugins that I have activated are also puking errors all over the place. I’ve already reported these errors to the developers (and maybe even submitted a pull request) and I’m sure they’ll get fixed eventually, but how do I continue working in debug mode in the meantime?

I could rely on the Debug Bar and Log Deprecated Notices plugins to catch the errors. I’ve tried this, but unfortunately I’ve found that it misses reporting some errors and I don’t know about them until I receive a bug report. Also, Debug Bar currently does not support capturing Strict Standards (PHP 5.4+) errors.

If an offending plugin isn’t required for the site to work, I could just deactivate it. This is not a great solution though because there could be a bug with how the plugin interacts with my code and by deactivating the plugin, we’re not testing any of that during development.

I could turn debug mode off and then just turn it on now and then to check if there are any errors showing up. This is a horrible solution though as I may miss out on catching some errors during development.

Sadly, the former two solutions is what I had been doing. I recently decided that it was no longer acceptable and set out to find a better way.

I now set WP_DEBUG_DISPLAY to false and WP_DEBUG_LOG to true in my wp-config.php for my local dev environment. This stops errors from showing in the browser and instead prints them to a log file at wp-content/debug.log. The advantage here is that we can still inspect the errors by looking at that log file and they aren’t being puked all over the UI, so we can still navigate the site and test it.

Closing and reopening this log file to get the latest entries is tedious, so I open the command line, and run tail -f wp-content/debug.log. The -f will keep the tail command running and when anything is added to debug.log, it will be output to the terminal automatically. So as errors occur, they will instantly show in our terminal. To stop the command from running, simply press Ctrl-C.

This is pretty good, but we’re not much further ahead than before. We still have all these errors from the 3rd-party plugins polluting the the log file:

[02-Mar-2014 15:22:20 UTC] PHP Strict Standards: Declaration of Social_Service_Facebook_Account::child_account_avatar() should be compatible with Social_Service_Account::child_account_avatar() in /wp-content/plugins/social/lib/social/service/facebook/account.php on line 6
[02-Mar-2014 15:22:20 UTC] PHP Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method AKTT::admin_controller() should not be called statically in /wp-includes/plugin.php on line 429
[02-Mar-2014 15:22:21 UTC] PHP Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method AKTT::admin_menu() should not be called statically in /wp-includes/plugin.php on line 429
[02-Mar-2014 15:22:21 UTC] PHP Strict Standards: Declaration of Social_Service_Facebook_Account::child_account_avatar() should be compatible with Social_Service_Account::child_account_avatar() in /wp-content/plugins/social/lib/social/service/facebook/account.php on line 6
[02-Mar-2014 15:22:21 UTC] PHP Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method AKTT::admin_controller() should not be called statically in /wp-includes/plugin.php on line 429
[02-Mar-2014 15:22:21 UTC] PHP Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method AKTT::admin_enqueue_scripts() should not be called statically in /wp-includes/plugin.php on line 429

As you can see, if there was an actual error in my code, it would be very hard to spot it amongst all these third party plugin errors. But not to worry, regular expressions to the rescue again! We can pipe the output through grep to filter out the unwanted errors.

tail -f wp-content/debug.log | grep -v -E "(/wp-content/plugins/twitter-tools|social/)|AKTT::"

The -v option tells grep to exclude any matches. The -E option enables enhanced regular expressions, so we can use things like a pipe character for OR.

Our pattern should match any errors in files in /wp-content/plugins/twitter-tools/ or in /wp-content/plugins/social/. There were also some strict standards errors caused by the Twitter Tools plugin but reported as file /wp-includes/plugin.php. I don’t want to exclude any errors reported by that file as they could be errors from my code as well. Instead, I also exclude any errors containing the string “AKTT::”.

I can continue adding more strings and file paths as I encounter more errors from 3rd-party plugins that I want to filter out.

One thing to note here is that this filtering doesn’t work if you have Xdebug enabled. Our grep filtering assumes that each error only prints one line to the debug.log but Xdebug actually prints a stack trace over many lines:

[02-Mar-2014 17:50:44 UTC] PHP Strict standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method AKTT::import_tweets() should not be called statically in /wp-includes/plugin.php on line 429
[02-Mar-2014 17:50:44 UTC] PHP Stack trace:
[02-Mar-2014 17:50:44 UTC] PHP 1. {main}() /wp-cron.php:0
[02-Mar-2014 17:50:44 UTC] PHP 2. do_action_ref_array() /wp-cron.php:100
[02-Mar-2014 17:50:44 UTC] PHP 3. call_user_func_array() /wp-includes/plugin.php:507
[02-Mar-2014 17:50:44 UTC] PHP 4. Social->cron_15_init() /wp-includes/plugin.php:507
[02-Mar-2014 17:50:44 UTC] PHP 5. Social_Request->execute() /wp-content/plugins/social/social.php:1211
[02-Mar-2014 17:50:44 UTC] PHP 6. Social_Controller_CRON->action_cron_15() /wp-content/plugins/social/lib/social/request.php:191
[02-Mar-2014 17:50:44 UTC] PHP 7. do_action() /wp-content/plugins/social/lib/social/controller/cron.php:44
[02-Mar-2014 17:50:44 UTC] PHP 8. call_user_func_array() /wp-includes/plugin.php:429

And so our grep solution will only filter out the first line and still output the entire stack trace. I’ve simply disabled Xdebug as I very rarely need the stack trace, but you could certainly write a script that filters out the appropriate stack traces and drop it in as a replacement for the grep command:

tail -f wp-content/debug.log | filter-errors

Maybe you already have a script to share with us? Or maybe you have a better solution? Please share in the comments.

  • You might check out Ostrichcize by Zach Tollman: http://wordpress.org/plugins/ostrichcize/. It lets you turn off error reporting for plugins and themes specifically, but from inside WP.

  • Very cool, thanks for sharing! Do you know if it suppresses Strict Standards errors as well?

  • Paul

    You can also view the debug log in the Mac console app and use its filter

  • I do not know. I would imagine it does, but I could be mistaken. I haven’t noticed it not catching them yet, but that could just be me…

  • Brady Vercher

    I dug into this myself after switching to PHP 5.4 awhile back because strict notices made developing with debug mode on unbearable. My main goals were:

    1) Only disable errors by specific third-party plugins. I want to see any error generated by my code.
    2) Configure the rules in one location. I spin up and discard a few new WordPress instances every week and wanted my rules to work for all of them.
    3) Use a generic string match to hide pesky errors.

    You can define a custom error handler in PHP, which is how Ostrichcize handles it (that’s where I learned it). It’s a good solution for a single instance, but felt a little limited for what I wanted to do (single config, generic string match).

    Instead, I registered my own error handler and included it using the php.ini “auto_prepend_file” directive. I ended up using that prepend file to include debugging methods, compatibility functions, and my custom error handler (even global plugins, but that’s a different project). One thing to watch out for is that only the latest registered error handler is used, so if a plugin like Query Monitor registers its own, you may need to override it afterward to continue using your custom rules.

    Here’s the error handler and rules I’ve been adding to over a few months in case anyone else finds this method useful: https://gist.github.com/bradyvercher/6556705

  • tollmanz

    I would love to cover your use case in Ostrichcize. That said, if you want the code to live outside of WP, you’d need to implement some sort of symlinking scenario. Additionally, by loading the code outside of WP, you have the benefit of setting the error handler well before any 3rd party code runs. This was a challenge with Ostrichcize.

  • Brady Vercher

    I couldn’t think of a way to make it work with Ostrichcize, otherwise I would have gladly opened an issue or pull request. The code doesn’t necessarily need to live outside of WP as long as the rules are shared. Maybe some sort of central config file?

  • tollmanz
  • tollmanz

    I actually cannot say for certain. I’ve opened a ticket to take a look into it: https://github.com/tollmanz/ostrichcize/issues/16. Would love feedback from you if you decide to install the plugin.

  • Pingback: The Weekly WordPress News, Tutorials & Resources Roundup No.60()

  • Pingback: WordPress????, ??, ???? #2 | wptuts – WordPress????()

  • I got annoyed having to turn xdebug on/off and restarting MAMP, so I wrote a little script to filter out entire xdebug blocks if they match my filters:
    https://github.com/bradt/xdebug-log-filter

  • Pingback: How to ignore errors form third party plugins while developing | wptips()

  • Pingback: Como ignorar errores de otros plugins mientras desarrollas | wptips()

Comments Elsewhere