{"id":2009804,"date":"2022-04-17T23:25:10","date_gmt":"2022-04-17T23:25:10","guid":{"rendered":"https:\/\/wpx.net\/blog\/?p=2009804"},"modified":"2023-11-01T11:38:39","modified_gmt":"2023-11-01T11:38:39","slug":"wp-debug-critical-error-on-this-website","status":"publish","type":"post","link":"https:\/\/wpx.net\/blog\/wp-debug-critical-error-on-this-website\/","title":{"rendered":"When WordPress Gets in the Way of Fixing Errors"},"content":{"rendered":"\n

This blog post will be somewhat different from what I usually write for my column at WPX. For starters, it will be shorter than the average, which \u2014 as the WPX team has delicately tried to suggest on more than a few occasions already \u2014 might not be that bad by itself.<\/p>\n\n\n\n

But more importantly, this column is not structured as a solution for a specific problem. Instead, it shows how a bit of recently added functionality actually makes it more difficult to diagnose and fix WordPress runtime errors and tells you how to overcome this unhelpful behavior as you rush to fix things.<\/p>\n\n\n\n

I will share with you the SOP (standard operating procedure) I follow when I have to fix an issue that has caused the appearance of the infamous “There has been a critical error on this website” message. It is not a solution for any specific issue; it is simply the first step one must take to understand why<\/strong> their WordPress website broke.<\/p>\n\n\n\n

I will be referring to this SOP many times in later blog posts, so I might just as well put this article up first. Hence, the whole raison d’\u00eatre<\/i> for today’s column.<\/p>\n\n\n\n

<\/span>The Site is Experiencing Technical Difficulties \u2014 But Why?<\/strong><\/span><\/h2>\n\n\n\n

WordPress is built using the PHP programming language. Like most modern programming languages for the web, PHP is what we call a scripting (the more technical term is ‘interpretative’) language.<\/p>\n\n\n\n

In very simplistic terms, you can think of PHP code as a theatrical script. At the beginning of the performance, the audience does not know what will happen. Only as the actors come on the set and begin doing their stuff, the story begin to unravel. If something unplanned happens \u2014 say, the lead hurts his knee while lunging to save his love interest during the second act and can’t continue, there is no elegant way to end the performance.<\/p>\n\n\n\n

For the longest time, WordPress handled errors like theatrical directors handled botched live performances: inelegantly. Unexpected events would cause weird error messages to appear on the screen. Sometimes the browser window itself would become completely blank, which became popular as the “WordPress White Screen of Death”.<\/p>\n\n\n\n

<\/span>The “Fix”<\/span><\/h2>\n\n\n\n

As part of the 5.2 release, the WP Core dev team shipped a feature called “PHP Error Protection” which intended to end this. In the words of WP Core,<\/p>\n\n\n\n

\n

This administrator-focused update will let you safely fix or manage fatal errors without requiring developer time. It features better handling of the so-called \u201cwhite screen of death,\u201d and a way to enter recovery mode, which pauses error-causing plugins or themes.<\/p>\n\n\n\n

WordPress 5.2 “Jaco” Release Notes<\/a><\/cite><\/p>\n<\/blockquote>\n\n\n\n

Once you have upgraded to WordPress 5.2 and ever since, a broken WordPress instance will no longer show a blank or a weird-looking page upon hitting a PHP error, but instead will show a polite notice that something is wrong.<\/p>\n\n\n\n

Your visitors will see a “The site is experiencing technical difficulties” when they access public-facing pages. Users who try to access the back-end will see a second line: “Please check your site admin email inbox for instructions.”<\/p>\n\n\n\n

\"\"\/<\/figure>\n\n\n\n

WordPress will also send a message to the site admin email address in which there will be a link to enter the wp-admin dashboard in a special emergency mode with all plugins disabled, and the theme replaced with the default Twenty-Twentysomething.<\/p>\n\n\n\n

<\/span>The Problems of the New Default WordPress Behavior<\/span><\/h2>\n\n\n\n

The biggest issue with this new feature is that it doesn’t necessarily work as promised at all (“This update will let you safely fix or manage fatal errors without requiring developer time.”). Sure: the ‘magic link’ will disable the offending plugin or theme, but will do nothing to address the root cause for the malfunction.<\/p>\n\n\n\n

If the fatal error occurred immediately after a plugin or theme update, the sysadmin will probably put two and two together, and roll back the offending update. But what if this error is not spotted immediately? Or if the error occurs within an obscure branch of code that gets executed infrequently? Or \u2014 less likely but definitely not out of the question \u2014 the error is caused by a change to the web server configuration like an upgraded PHP version?<\/p>\n\n\n\n

Regardless of the root cause, the person responsible for the website will only know there is a problem but not where to look for that problem. In a manner, WordPress is actively trying to hide the error from the admin, even at the expense of disabling what might be core website functionality.<\/p>\n\n\n\n

Disabling a plugin or a theme \u2014 even worse! \u2014 is rarely the preferred solution simply because we tend to install plugins and themes because we need<\/strong> them. A plugin might be there to make a vital change to the standard way WordPress works. If it causes errors, disabling it does not fix anything but simply introduces a different problem, which might be much bigger and costlier.<\/p>\n\n\n\n

That is why, if a plugin that is vital to the operation of a website breaks, the site owner needs to fix it immediately, not to remove it. The polite message presented by WordPress actually puts us farther back on our path of finding the root cause of an issue and fixing it. So let’s see how to get past it.<\/p>\n\n\n\n

<\/span>Enter WP_DEBUG mode<\/span><\/h2>\n\n\n\n

WordPress has a powerful mode created for troubleshooting various issues. It instructs WordPress to either log and\/or show on screen all warnings and errors which PHP reports. On a development or staging website, this mode is usually kept enabled at all times, so that every warning or error is noticed immediately.<\/p>\n\n\n\n

However because these error reports might reveal privileged information, it is a good practice to keep this mode disabled on production websites.<\/p>\n\n\n\n

If you maintain a mission critical WordPress website, I assume you always test every update and configuration change on a separate staging website first. But things happen, and if\/when some bug breaks through, it is no longer viable to try to reproduce the issue on a staging website. Your number one task should be to restore normal operation to your production website. So let’s break the glass and enter WordPress debug mode.<\/p>\n\n\n\n

This involves adding several commands to the wp-config.php file. Most WordPress troubleshooting guides will show you those 3 lines:<\/p>\n\n\n\n

\/\/ Enable WP_DEBUG\ndefine('WP_DEBUG', true);\n\/\/ Write errors to a log file located at wp-content\/debug.log\ndefine('WP_DEBUG_LOG', true);\n\/\/ Show errors on screen\ndefine('WP_DEBUG_DISPLAY', true );<\/code><\/pre>\n\n\n\n
WP_DEBUG is a global on\/off switch; if it is set to ‘false’, it doesn’t matter if either WP_DEBUG_LOG or WP_DEBUG_DISPLAY is set to ‘true’ \u2014 errors will not be logged or shown on screen.<\/p>\n\n\n\n
However, the hidden failure of the well-meaning ‘Critical Error with Your Site’ error message is that you will still be unable to see any errors because the error handler page is cutting you off from the website. You need to also turn off fatal error handling in order to see the actual error.<\/p>\n\n\n\n
\/\/ Disable Fatal Error Handle\ndefine('WP_DISABLE_FATAL_ERROR_HANDLER', true );<\/code><\/pre>\n\n\n\n
<\/span>Faster Access to WP_DEBUG Settings<\/span><\/h2>\n\n\n\n
As mentioned above, these 4 commands need to be placed within wp-config.php<\/code>. However, this means that when I am done fixing the error, I need to come back and edit at least two of them to ‘false’ (WP_DEBUG and WP_DISABLE_FATAL_ERROR_HANDLER).<\/p>\n\n\n\n
I have been doing this for way too long and it has become really boring. Also, I no longer find it optimal. So these days, I prefer to do something else: I add all of these settings to a new file called wp-debug.php<\/code> that looks as shown below (observe the opening tag which allows PHP to recognize the file as code:<\/p>\n\n\n\n
<?php\ndefine('WP_DEBUG', true);\ndefine('WP_DEBUG_LOG', true);\ndefine('WP_DEBUG_DISPLAY', true );\ndefine('WP_DISABLE_FATAL_ERROR_HANDLER', true );<\/code><\/pre>\n\n\n\n
I then open wp-config.php<\/code> and place the following line at the very beginning (after its own <?php<\/code> opening tag):<\/p>\n\n\n\n
<?php\ninclude (__FILE__ . '\/wp-debug.php');<\/code><\/pre>\n\n\n\n
The ‘include’ directive instructs PHP to insert the mentioned file in this very place. However, if the file does not exist, php will not signal an error but will simply continue execution from the next line.<\/p>\n\n\n\n
When I am done with error diagnostics and fixing, I have two choices to exit the debug mode. I can re-open wp-config.php<\/code> and comment on the include statement:<\/p>\n\n\n\n
<?php\n\/\/ include 'wp-debug.php';<\/code><\/pre>\n\n\n\n
Or, I can instead simply rename wp-debug.php<\/code> to something like wp-debug.php.disabled<\/code> .<\/p>\n\n\n\n
<\/span>What Next?<\/span><\/h2>\n\n\n\n
As I said earlier, figuring out the specific reason for the error that triggered the PHP error protection is outside the scope of this article. I have planned other articles that will discuss how to read and interpret PHP error messages; how to anticipate problems due to PHP version changes; how to restore previous versions of plugins and themes from either the command line or via plugin, and so on.<\/p>\n\n\n\n
The purpose of this column is to set the groundwork, and to show you how to get rid of a well-meaning but sometimes counter-productive feature.<\/p>\n\n\n\n
If you are a customer of WPX, you can simply take advantage of their industry-leading \u2018Fixed For You<\/a>\u2018 guarantee and let their friendly and qualified support staff take over. You can tell them that you have disabled the PHP Fatal Error Handler, and have enabled WP_DEBUG mode \u2014 I am sure that they will appreciate what you have done to help them investigate and fix the issue.<\/p>\n\n\n\n
<\/span>Recap<\/span><\/h2>\n\n\n\n
In this column, I explained how WordPress behaves when there are errors in the programming code. I showed you how to change the default behavior which conceals the cause of the error and puts the whole website in a basic mode, and how to activate the powerful debug mode in order to identify the issue and fix it.<\/p>\n\n\n\n
Regardless of whether you will do the fixing on your own, or you will ask for help from your hosting company, this is the very first step to take on the path of solving the issue.<\/p>\n","protected":false},"excerpt":{"rendered":"
This blog post will be somewhat different from what I usually write for my column at WPX. For starters, it will be shorter than the average, which \u2014 as the WPX team has delicately tried to suggest on more than a few occasions already \u2014 might not be that bad by itself. But more importantly, […]<\/p>\n","protected":false},"author":3,"featured_media":2015368,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"cybocfi_hide_featured_image":"","footnotes":""},"categories":[86],"tags":[],"ppma_author":[111],"class_list":["post-2009804","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wordpress"],"blocksy_meta":[],"authors":[{"term_id":111,"user_id":3,"is_guest":0,"slug":"ivan-arnaudov","display_name":"Ivan Arnaudov","avatar_url":"https:\/\/secure.gravatar.com\/avatar\/168c2caf170cc2d43ef2ec57bc8af7347f86a5f5e825ee86026e52878df349b2?s=96&d=mm&r=g","0":null,"1":"","2":"","3":"","4":"","5":"","6":"","7":"","8":""}],"_links":{"self":[{"href":"https:\/\/wpx.net\/blog\/wp-json\/wp\/v2\/posts\/2009804","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wpx.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/wpx.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/wpx.net\/blog\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/wpx.net\/blog\/wp-json\/wp\/v2\/comments?post=2009804"}],"version-history":[{"count":11,"href":"https:\/\/wpx.net\/blog\/wp-json\/wp\/v2\/posts\/2009804\/revisions"}],"predecessor-version":[{"id":2016418,"href":"https:\/\/wpx.net\/blog\/wp-json\/wp\/v2\/posts\/2009804\/revisions\/2016418"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/wpx.net\/blog\/wp-json\/wp\/v2\/media\/2015368"}],"wp:attachment":[{"href":"https:\/\/wpx.net\/blog\/wp-json\/wp\/v2\/media?parent=2009804"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wpx.net\/blog\/wp-json\/wp\/v2\/categories?post=2009804"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wpx.net\/blog\/wp-json\/wp\/v2\/tags?post=2009804"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/wpx.net\/blog\/wp-json\/wp\/v2\/ppma_author?post=2009804"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}