There is a tension when there is a technical problem and you’re not feeling well: you want to fix it but you may not be in the best frame of mind. I was sick last week and was really irritated when this blog was not loading properly Friday night. Thus began a series of technical support steps that could have ended more smoothly.
One rule of thumb I learned many years ago:
If you are going to make a change to a web site, don’t do it on a Friday.
Inevitably, whatever you change will fail or not act the way you expect over the weekend. I have found that doing things on web sites on Fridays is usually arbitrary, and there’s no good reason not to push it off until Monday. But this is a personal site, so Saturday was good enough. I was annoyed but I could see visitors still hitting the site and I needed the rest.
Sometimes Support Isn’t
I moved web site hosts a couple of months back. It’s been fine but the support isn’t always great. It’s like any help desk support. There are common ailments and common cures, and sometimes the cure and the ailment match.
In this case, I had two issues. One was that content wasn’t loading properly on the web site. It looked like the CSS files were missing (so the content was just streaming down the page, not in its correct layout). That meant I could eliminate some basics, like:
- not the database – content connection that powers WordPress
- probably not access or security issues
The second problem was that I couldn’t access my WordPress administration dashboard, where I could probably fix some of the problems. If you were to do a web search on wp-admin loop, you’d see it’s a common problem.
The tech support had a common cure too: add a trailing slash in the .htaccess file, problem solved. In my case, it didn’t. It also didn’t help that the person editing the .htaccess file on my behalf didn’t comment out his textual comments, and borked my site.
I closed the ticket and decided I’d figure this one out myself. Partly it’s because I like the challenge but also it helps me to learn (and document here) for the next time. This was going to be more complicated and I didn’t want to just email from the sidelines.
Cache Me Outside
First, the content issue.
Check your cache. This is a basic help desk cure. Surprisingly, it does clear up almost as many issues as reboot your computer does. I have led a couple of web developer teams and that was often the first thing they asked me. Also, buy a clue was popular.
This is the browser cache that technical people are referring to. I was pretty sure it wasn’t a cache issue. I’d had the same errors on multiple browsers on multiple devices. That doesn’t mean it’s not a cache issue, it may just mean it’s not your local cache.
Some corporate networks have caching enabled too. If you’ve cleared your local browser cache and forced a new retrieval of content (CTRL-F5), that may get you past the issue.
My site is behind Cloudflare, which caches a copy, so there are a couple of things you can do there:
- pause caching (it’s at the bottom right corner of the Overview page of your Cloudflare dashboard) until you’re ready to turn it on again
- turn on development mode (it’s on the right side of your Overview page) which is a 3 hour pause after which caching turns on again
- purge your cache (it’s under your Caching tab in Cloudflare)
In my case, none of these had any impact.
Again, I wasn’t feeling my best. So perhaps I would have noticed this faster. But Firefox was giving me the mixed content warning – some content was being sent over HTTPS and some wasn’t – and it was blocking the insecure content. When I told Firefox to let it load (after using View Source to see that the CSS URLs were, in fact, to my site), the page loaded fine.
Now I needed to get into my dashboard to add a plugin to fix this problem.
WordPress and the WP-ADMIN Loop
You don’t really need a plugin for this. In the past, I have used the .htaccess file to handle this. It’s simpler and cleaner. It didn’t work for me, but now I’m wondering if I tried again now that my eternal loop is fixed, whether it would. In any event, a plugin can also fix it.
But first I had to get to the dashboard to manage a plugin. I’ll skip the gory details, but it involved the following steps (with the Cloudflare cache in development mode):
- added and removed trailing slash from the .htaccess file line for wp-admin
- renamed the plugins folder. This would normally cause plugins not to load, so if one was causing the loop, it would fix it.
- reset the .htaccess file. WordPress has a default file – it’s different on sites like mine that are Multisite – that you can cut and paste in. No help.
- Turned on wp-config.php’s debugging. No error output.
There were some other suggestions (add ErrorDocument 403 Default to .htaccess was a common one) that didn’t work. The solution in the end was to force the wp-admin to use SSL too. It’s a line you add to the wp-config.php file.
What isn’t clear to me is what caused all of this to happen. I don’t tinker with my site’s back end and certainly hadn’t touched anything in days that could have caused an issue. The single thing I dislike the most about web site hosting is not knowing what the host is doing in the background, automatically.
Let Me Delete Your Content While I’m Here
File this under While You’re Ahead, see also QUIT! I had upgraded Matomo, the web analytics package I run, earlier in the week. I’m confident it had nothing to do with whatever happened to WordPress although the upgrade has uncovered a bug / problem.
As part of this effort to get Matomo working, I reinstalled it. I don’t need archival analytics data so I ended up creating a new database. I returned to CPanel to manage my databases, and delete the old one. Although you can use PHPMyAdmin to manage the innards of the databases, to manage users and delete a database you do it through a different CPanel module.
Hey look, there are other databases that start with PIWI! Let’s delete them! I wasn’t so far out of it that I would have deleted any WordPress databases (all named clearly) but I hadn’t been careful with my other database names. I did successfully delete the old Matomo (aka PIWIK) databases. And also the one for my stock photos, using PIWIGO.
Oof.
Fortunately, I have web backups. As with any technical recovery, I weighed doing a backup restore or just starting fresh. I decided to start fresh, since I hadn’t put a lot of work into the site: not many photos, no retheming, etc.
But I’ll dig a bit deeper to confirm database names next time I think about tidying up. And I’ll do this sort of maintenance – non-critical – work when I’m feeling 100%. No need to rush myself into more work.