WordPress is wonderful and updating the software is usually a breeze. You will get notification on your admin dashboard indicating updates available for plugins, themes, … and WordPress itself. Click a few button and you can initiate the updates. But here is the problem, the update process runs from your browser, what that mean is that if you accidentally close out your browser, the update process is halted prematurely.
Ouch!
Terminating an update prematurely can be a huge problem, as it may corrupt your software environment, I haven’t seen that yet, but it is possible, so the best advise is do updates in small batches, and just be patience and let it finish. And full backups should be done regularly so that you can restore back to a working point.
But in most cases, WordPress is pretty good in recovering from an interrupted update, with one problem that it can’t seem to fix itself, it is stuck in maintenance mode, and that’s what your users see when they visit your website.
No worries, I will show you a simple trick on how to fix this.
Let’s first understand the WordPress Update process. When you initiate an update, you will see something like this:
Please note the 2 red lines, basically WordPress will first enable maintenance mode, do all the requested updates, and then disable maintenance mode. The mechanism it uses seem to be very simple, it places a .maintenance file on WordPress top folder, and when it is done with all the updates, it delete the .maintenance file. So when you interrupt the update prematurely, usually by accidentally closing the web browser, the .maintenance file is never deleted.
How to fix it? just delete the .maintenance file. The simple way to do that is to use your favorite ftp software, connect to your website, locate the .maintenance file, and delete it. That’s it, problem is fixed and you will see your website return to normal magically.
My 2 cents? WordPress is so popular and it is used widely by both technical and non-technical people to create wonderful website. This little glitch seems to be an oversight. There should be ways to avoid this situation. One thought comes to mind is that the overall update process should not rely on a long client session, maybe it should be a batch process in the server, it takes in all the update instructions, execute them, and provide an a-synchronize notification back to the admin user.