Fun With WordPress

Fun With WordPress

I really didn’t want to post techie stories on my blog so early, it’s supposed to be about chocolate after all. But the experience I had putting my new website live was too interesting not to share, and posting about it could save someone else the many hours it took me to resolve it. So read on for the mystery of the transmogrifying website.

The transmogrifying website

Some background – my site was built with WordPress, which was not a technology I have worked with before. While developing my site I had turned on URL protection, so that only people with a password could see the site in progress. So when the site was ready all I had to do was turn off the URL protection feature, perform a quick test, then share the link address with the world. In theory… 

The first person I sent the link to responded with “Are you sure?”. When I went to check my new chocolate business’ website again it had turned into a Coffee Shop! Of course, not literally a coffee shop, this story is not quite that strange, but the website for a coffee shop. Which was surreal enough for me.

Dead End Investigation

When I went into the WordPress admin screens I could see lots of extra pages and blog posts had appeared in my website, and it just so happened that the coffee shop page was the one that WordPress had chosen as my homepage. So I didn’t just have a coffee shop there, I had a clothes shop too, and more. Not to mention lots of blog posts containing random “Lorem Ipsum” text.

Luckily I had a backup from the previous evening, so I restored it and reapplied the minor changes I had made that day. Mid way through reapplying the changes, new pages and posts started to appear in my site again. Restore the backup again, all looks fine, wait a few seconds, there’s the coffee shop again. 

The content that appeared was obviously some kind of demo content from a WordPress theme or plugin, so my next course of action was to identify the guilty component so that I could disable it. I tried using Google searches for text in the pages, and Bing image searches for images that matched some of the graphics, but no luck. I tried browsing through the demo sites included in all the themes installed on my site, but could not find the right content.

My next idea was to look at the WordPress logs. At which point I discover that WordPress logging is off by default, and the config file that controls the logging is one of the files that I need to restore from backup. So I need to restore the backup and turn on logging before the guilty component finishes adding extra pages and posts. And then I discover that by default WordPress only logs Errors and Warnings. Whatever is creating these extra pages and posts is succeeding in what it is attempting, so is unlikely to generate any Error log entries. If I want more detailed logging I need to create my own custom plugin, which is certainly beyond my current level of WordPress expertise. So another dead end.

progress at last

Then I start pondering why my site was OK yesterday, when the backup was made, but is having problems now when it is restored. The only difference seems to be the URL protection, which operates at a lower level than WordPress, so should by independant from it. But it is the only difference, so I turn it back on and restore my site again, and this time it stays OK. So now I have a working site, but no-one can see it without the password. Progress. Sort of.

So what is it that is adding content as soon as the Protected URL is turned off? It occurs to me that there must be some sort of queue of actions or scheduling tool in WordPress. A search on Google reveals that there is a scheduling tool, and that I can install a plugin to see the scheduled tasks. So I install the Crontrol plugin, and the first thing I see is an error at the top of the Crontrol dashboard stating that a scheduled task failed due to an HTTP 403 error. Bingo! This error means that access is forbidden, and is what you would see if you tried to access a protected URL without the password. 

Looking through the list of scheduled tasks in Crontrol, most of them run daily or less often, but the one that jumps out at me is one that is scheduled to run every 2 minutes. This explains why I would get a short amount of time with the correct website after each restore before the additional pages and blog posts started to appear. It turns out that the guilty task is connected with a plugin that runs a wizard that my WordPress host uses to install some other standard plugins and demo content when a new site is created. Either the wizard stalled when it first ran, or my turning on Protected URLs caused it to get stuck. And since then it had been trying to write its demo content every 2 minutes and failing due to the Protected URL. 
I updated the scheduled task to run daily, and was able to restore my website without it being overwritten at once. I then worked with my WordPress host to clean up the half run wizard and remove the scheduled task entirely. And I finally have a chocolate website that stays as a chocolate website.

Thanks to SiteGround tech support for their help in cleaning up the wizard, and for spotting some mixed content errors that I have now fixed.

And I promise to get back to chocolate next time!