Preface

I woke up today and received an email:

I knew something was going to go wrong again, and sure enough:

The backup WordPress site was unable to log into the backend dashboard using /wp-admin due to a failed automatic plugin upgrade. However, if you don't log into the backend and just visit normally, there is no problem. In other words, it's not a big deal; it's just that for some reason (in my case, it was due to a failed automatic plugin upgrade, though it can also be caused by a failed theme upload) the backend dashboard cannot be accessed normally.

---

When encountering this kind of problem, sometimes my mailbox receives an email sent by the problematic WordPress (this is due to a new feature since WordPress version 5.2: when a plugin or theme error is detected, it will automatically send an email notification to the administrator, even if the backend is completely inaccessible). There is a link inside, and clicking it directly allows you to log into the WordPress backend and manage it. However, most of the time, this email is not received...

---

Given that this problem has occurred more than once, and every time it happens I basically forget how I handled it last time, I decided to record the handling process just in case. Of course, I can also write a quick blog post about it.

Summary of Handling Methods

Where the cause of the fault can be clearly located

For example, my plugin upgrade failure this time, or the failure caused by changing to a new theme, has a very clear cause, so it can be handled in a targeted manner. For instance, rename the directory where the plugin is located as shown in the figure below:

Then restart WordPress (if it is deployed via Docker, restart Docker; if it is deployed via source code, restart the corresponding service). At this point, if you can enter the backend normally, you can handle the problematic plugin (re-upgrade, delete, or re-upload and install as needed).

However, I still couldn't get in. The reason might be that more than just this one plugin upgrade caused it, so I had to treat other plugins in the same way one by one until I found all the related plugins.

Note: There is also a trick here. For example, I directly sort by the most recently modified time, and then start renaming from the most recently modified:

After finally renaming 3 plugin folders, I was able to enter the console normally:

Then rename the 3 renamed folders back to their original names and refresh:

It returns to normal status. Then, whether to delete it or enable it and upgrade depends on your own needs.

If it is caused by upgrading a theme, the handling method is similar. You can delete or rename the folder of the theme originally used, then rename another theme folder to the folder name of the originally used theme, and restart.

Where the cause of the fault cannot be located

For this type of problem, you have to rely on WordPress's debug mode. By enabling debug mode, WordPress will send errors encountered during the startup process towp-content/debug.logfile. Through the problems recorded in the log file, you can locate the cause of the fault.

Editwordpress/html/wp-config.php, and find the following content:

define( 'WP_DEBUG', false );

As shown in the figure below:

Change it to:

define('WP_DEBUG', true); #开启debug模式
define('WP_DEBUG_LOG', true); #将启动错误信息写入log文件
define('WP_DEBUG_DISPLAY', false); 

define('WP_DEBUG_LOG', true); #Write startup error messages to the log filewp-content/debug.logdefine('WP_DEBUG_DISPLAY', false);

Then save the changes to wp-config.php. At this point, you can use the

define( 'WP_DEBUG', false ); #其他两条直接删除即可。

Summary

Remember to turn off debug mode after handling:”define( ”WP_DEBUG”, false ); #The other two lines can be deleted directly.“If it is a multi-node WordPress synchronization deployed in the manner described in the article "

Home Data Center Series: WordPress Multi-Node "Semi-Automatic", "Near" Real-Time Synchronization Solution