Yesterday, the site crashed. I was locked out of everything. Also, the site was returning the internal server error, message 500, to all visitors. Well, a long time ago, I learned not to panic about such things. It doesn't pay to panic.
Of course, it's unfortunate when your site goes down. Visitors, especially new visitors, are unfavorably impressed and may not revisit a site to see if the problem was just temporary. Not only that, but I just registered the site yesterday with various directories — what timing. Thanks Satan.
Of course, there's always the flipside to that. What I mean is that God always shows things during trying times and events. He shows things all the time, but they can really stick out during the trying times. What good has come out of a WordPress crash, not that I want to have another any time soon?
So, what happened, why am I telling anyone, and what did I do about it?
WordPress allows for many plugins, just as browsers do (especially Firefox). A relatively new feature with WordPress is one-click upgrade of plugins.
Now, I have many plugins installed. I don't have them all activated (which is not exactly the same thing as being enabled by the way but close). The reason I keep deactivated plugins installed in the same directory or folder as the active plugins is so I will be automatically notified when updates are available. Many times, updates clear up the problem I had with the plugin's earlier version. Also, it helps to keep me from downloading plugins I already tried but that caused some sort of problem (incompatibility with other plugins, etc.).
Yesterday, there was an update available for the "Share This" plugin that I had sitting there deactivated. I clicked the one-click upgrade. Well, the download stalled. I was having lots of Internet-connection crashes yesterday. Sometimes I can go several weeks without an interruption. Some days I have to reinitialize my router or wireless about every hour. My site was also exceptionally slow and stalling out a lot.
So, I closed the page to start over, which I've done before without any problems, only this time, I was instantly cut off from the administration and public site.
Here's what I ended up doing.
I used FTP to rename my plugin directory. That instantly let me back into the administration pages. I named the directory back again. All the plugins were still there with the exception of the "Share This" plugin that I had moved from the HTTP server just in case. Doing this renaming deactivated all the plugins. It also caused WordPress to forget what had been recently deactivated. So, there I was with all my plugins and not being able to remember which were active and which were deactivated before the crash. I remembered many of them, but not every last one. Also, some of them will work, but will cause some subtle problem.
I've gotten into the habit of editing the description line of each plugin to say in all caps and bold what my issues are. I started that long after I deactivated many plugins though and couldn't recollect every reason I deactivated. Remember, becoming a WordPress administrator is a learn-as-you-go proposition.
Well, I thought, "Why not just restore my backups?" I have daily backups. I had forgotten though that my web hosting has an uploading database-file-size limitation. I had only had to upload once. That was to restore all my tags that were lost due to a plugin change. I broke up the tag file manually. I wasn't about to do that with the entire back up file for the whole blog. It's huge. There is a program that can help with that called Big Dump. It looks useful, but it was late, I was tired, and I just didn't want to work with it right then. There had to be another way.
The first thing I did was load the public home page. All I got was a blank with an error message on the title line in the browser. It was truncated, so I did a source view. That allowed me to tell which plugin was involved. I activated that plugin, and that allowed my header to load and a bit of the index. The header and index are parts of the whole page you see when you view a dynamically created webpage. The header is fetched and the other parts and assembled for you to see. The only exception I know of is where caching is involved. I also use caching on this website.
I had to activate the cache plugin, purge the cache, and then disable the plugin in the plugin settings. That way, I could check the effect of turning on each plugin one at a time. I had two browsers open to do this. One was to check how things look to regular visitors who are not logged into the site. Many times, the administrator can see things in the public pages and post that a non-logged in visitor is blocked from seeing.
I turned on each plugin that the public pages were telling me were issues. Pretty soon, the whole site was viewable again but with holes where plugins were still deactivated. At least the pages were loading all the way to the end of the footer. Now, the site was wide open in terms of anti-spam. Therefore, I started up everything that had to do with "security" next. Then I went back to the top of the pages and posts with comments in particular and went down each column looking for the holes. Activating each plugin and checking by reloading (refreshing) each page in both browsers. (Note here that I have caching turned on in my browsers but I have them set to check for changes. I learned that valuable lesson some ten years ago if memory serves.)
So, I finally bumped into a plugin that kept me from seeing anything but a blank page. I had gotten back to where I was before the crash, but I had actually fixed and tweaked some things along the way.
A valuable habit I'm starting as of today is that I will always clean the section on the WordPress plugin admin page that says recently activated plugins. WordPress cleans that part of its log after 7 days, but I'm going to do it manually the moment I'm sure I don't need that log info. Here's why.
I'm also doing a save-as of the page after every change. That way, I will always have the last list of what plugins were active versus deactivated if I run into another crash situation.
The other thing I'm going to have to work on is finding a way to back up the database tables in bite sizes acceptable to the web host's configuration. I can do that manually, but who wants to take the time each day to log in and run backups manually. I don't. I want a backup system that is built with this restore-issue in mind. Maybe there's one out there already like that since I'm certainly not the first person to have run into this, hence "Big Dump" mentioned above.
Well, I hope this will help some people who feel depressed, frustrated, angry, and even panicky.
If so, let me know. Leave a comment about it.