Preface

I got an email today:

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

The backup site of wordpress cannot use /wp-admin to log in to the backend dashboard due to the failure of automatic plug-in upgrade. However, there is no problem if you do not log in to the backend and just access it normally. In other words, there is no big problem. It is just because of some reasons (in my case, it was due to the failure of automatic plug-in upgrade, but also due to the failure of uploading the theme) that the backend dashboard cannot be accessed normally.

---

When I encounter this kind of problem, sometimes I can receive an email from the problematic WordPress in my mailbox (this is because of a new feature of WordPress since version 5.2: when an error is detected in a plugin or theme, an email will be automatically sent to notify the administrator, even if the backend is completely inaccessible). There is a link in it, which can be directly clicked to log in to the WordPress backend and manage it, but most of the time, this email cannot be received.

---

Since 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 process in case of emergency. Of course, I can also write a random article.

Summary of treatment methods

Can clearly locate the cause of the fault

For example, if my plugin upgrade fails or fails after changing to a new theme, the cause of the problem is very clear, so you can deal with it in a targeted manner, such as renaming the plugin directory as shown in the figure below:

Then restart WordPress (if it is deployed in Docker mode, restart Docker, if it is deployed in source code, restart the corresponding service). At this time, if you can enter the background normally, you can handle the problematic plug-in (re-upgrade, delete, or re-upload and install as needed).

But I still can't enter. The reason may be that more than one plug-in has been upgraded, so I can only treat other plug-ins in the same way until all related plug-ins are found.

Note: There are also some tips here. For example, I directly sort by the time of the most recent modification, and then modify it from the most recently modified:

Finally, after changing the names of the three plugin folders, you can enter the console normally:

Then change the three renamed folders back to their original names and refresh:

It will enter the normal state, and then you can delete it or enable it for upgrade, depending on your needs.

If it is caused by upgrading the theme, the solution is similar. You can delete or rename the folder of the original theme, then change the name of other theme folders to the same folder name as the original theme and restart.

Unable to locate the cause of the fault

For this type of problem, you need to rely on the debug mode of WordPress. By turning on the debug mode, WordPress will send errors encountered during the startup process towp-content/debug.logIn the log file, the cause of the fault can be located through the problems recorded in the log file.

editwordpress/html/wp-config.php, find the following:

define( 'WP_DEBUG' , false );

As shown below:

Change it to:

define('WP_DEBUG', true); # starts debug mode define('WP_DEBUG_LOG', true); # writes startup error information to the log file define('WP_DEBUG_DISPLAY', false); 

Then save the changes to wp-config.php and you can now runwp-content/debug.logThe reason why wordpress cannot start normally is due to the information location in the file.

Remember to turn off debug mode after processing:

define( 'WP_DEBUG', false ); #Just delete the other two.

Summarize

如果是通过文章”Home Data Center Series WordPress Multi-node "semi-automatic" and "nearly" real-time synchronization solution“中所述的方式部署的多节点wordpress同步，则建议在除了主节点之外的其他节点中禁用插件的自动更新功能，因为这种方式在主节点自动升级更新了插件之后，其实其他节点都可以通过syncthing的同步功能跟着升级插件，只不过这种同步不一定会被本地的插件感知到(重启一下其他节点的wordpress就能正常识别了)。

Therefore, if other WordPress nodes have automatic updates turned on, the local plug-in may detect the new version and try to upgrade automatically. However, since it has already been upgraded, some errors will occur. This is why I think the probability of triggering fatal failures after other WordPress nodes automatically upgrade plug-ins is greatly increased.