WordPress – We LOVE It!
So you have just hopped over to your favorite blog. Comes up lickety split since you have your favorite caching plugin working – QuickCache or SuperCache are my faves. “I’m so proud of this blog. Great articles. Super graphics. I just can’t wait to login and post a new…” Uh oh. WTF??? “Firefox has detected that the server is redirecting the request for this address in a way that will never complete” What is THIS fresh h*ll??
Yeah, so this happened to me this morning. I had this problem a few times across the years. There is no single solution to this one. There are a bunch of reasons that this can happen. Permissions problems. Misconfiguration in the .htaccess file. Blocking software like WordFence or SpyderSpanker (if there’s misconfiguration in there – love those two plugins though so do NOT want to cast any aspersions..) might be acting a bit overprotective. Yeesh. Where to start?
Direct Access to login?
Let’s try the direct wp-login.php page and see what happens. And… nothing. “Firefox has detected…” Yeah, yeah, yeah, I *GET* it.
Different Browser
Maybe something is bogged in this browser – since I have 5 Firefox browser instances open with about 10 tabs open in each one – the life of a web guy. Pop open IE – hate it, but there won’t be anything in the cache. And again, no.
Low-hanging fruit – the .htaccess file
I often configure my .htaccess file to only allow logins from my IP address, so that was an educated guess. But, alas, I don’t see that I have locked out everyone but me. Though that IS the cumulative effect. Next.
Permissions
So I checked my file perms via FTP. There is a suspicious perm on the wp-config file. Why might that be set to a 755? Shouldn’t be. Alarm bells go off. Change back to a 644. Nope. I have seen issues where permissions issues will cause problems that surface in a variety of ways, but this wasn’t the case. That’s one possibility. And I’m certainly not going through all the WP files. That was the glaring issue and it didn’t fix the problem.
Plugins
Maybe a plugin updated? I have a number of sites and while I probably should log more about what I do on a daily basis, I don’t. No idea when I updated any of this stuff, though it looked like maybe the second of January. Let’s disable those plugins. And try to login yet again. Nope. Not it. Okay, let’s try disabling a few more. Nope. And a few mor… – oh heck, disable them all. Boom. Nope.
Well, maybe there’s a call going on in there that isn’t or shouldn’t be happening, let’s delete all the plugins (I already downloaded the whole site for safekeeping). Go to file manager in the cPanel – a heckuva lot faster than FTP – goodbye files! And – browser – and… “Firefox has detected…” Ugh.
Okay. This has all taken about 15 minutes or so rooting around and trying the lower level cures.
Backups
Okay, since that didn’t fix it, I have more important things that need doing today. Let’s go to our backups. Backup on the S3 servers over at Amazon. LOVE this system. We are all about some BackupBuddy and having several backups can go a long way towards resolving these issues. It’s the hardcore way OF resolving these issues, but my time is better spent being productive and not wasting the morning “Let me try this. Maybe it shouldn’t be capitalized (Apache can be SOOOO picky)…” and yet more troubleshooting fun. Nope, it’s time to get ugly.
I have 3 backups going back to the second of January. Typical since that seems to be about when that issue likely started occurring. Let’s start with the most recent. Download all of them just so we can get out of S3. Grab the most recent version of importbuddy.php. Delete all directory files. Upload importubddy.php and the most recent zip file backup. Go. 3 minutes later, comes up like a champ as far as viewing. And on to the admin page – nope.
Delete everything again – go to an earlier backup. Nope. None of them solved the issue. Whatever is causing the issue, either occurred on Jan 2 or before. NOW we need to get neanderthal, or at least cro-magnon, on it.
Reinstall WordPress
Delete all the files again and get this beeyatch up and running. Leave mySql database there for now to see if we can salvage anything out of this without a huge amount of screaming and hollering. Upload the WordPress 3.8 zip file. Extract in place. Run the famous 5 minute install. On that server it only takes a couple of those 5 minutes. I put in the information for my existing database with all the same settings – table prefixes, user, etc. Hadn’t actually tried this before, so it was new territory. Let’s see if we can over-install like that. And yes, we can.
Success?
Oh my yes. It’s coming up with an admin login screen. w00t! And login. Yup. There are my 400-some posts all safe and secure. A lot of pages. Nice. Now we need to upload all the files and folders we deleted a few minutes ago to make sure things are found properly. FTP upload. Made the mistake of loading a web page and moving around a bit as I still wanted to assure myself that all was well. “Active theme is broken, switching to default.” or something like that. Then messages about plugins being deactivated as they are not there anymore/yet. Crap. If I had just left well enough alone, I probably wouldn’t have had to re-activate everything, but it is what it is. At least I don’t have to find a new creative way to extract all my data from the mySQL database and import it.
Resetting the site and cleanup
10 minutes later after everything uploads, I am re-activating plugins. A few at a time is the safest at this point. And there actually IS one that doesn’t want to be activated. It isn’t that important a plugin so I’m not sweating that one. A few config modifications that either were not able to be carried over or such and we are off to the races.
WordPress DID put in it’s own defaults doing the over-install. So none of the posts were coming up properly. Change the permalink structure was my guess and yup, that was the problem. I prefer the /%category%/%postname%/ structure. That is resolved. And now I’m posting this 🙂
Site up. Site still has all prior pages and posts. And I’m on to my PLANNED morning. Time to resolve? About 45 minutes.
Insights and Takeaways
HAVE backups in a format that you can use. Know how to use them. Troubleshoot it methodically from easiest to the hardest cures. The recovery gets progressively more time consuming as you move along. I was really just hoping that it was the .htaccess file keeping me out.
If this hadn’t worked?
Actually I would have replaced the most recent version of backup on the site and just let that run until I had time to get to it most likely. This site isn’t a killer if I can’t make a post or get to admin today. But, next step would be scavenging the database files directly. Fresh install and then push the database into my local sql server and just pulling all that stuff out in an export. I would have put it into a clean local DesktopServer WordPress site here and done my best to extract the data in a fashion that would have allowed for me to do a direct SQL push into the target site. Now THAT would have been ugly. would have then gone on to scavenging the
Follow
