A few times recently I’ve awoken to discover that one of my main sites, Lingerie Brands, has been down for several hours thanks to a corrupted .htaccess file. After taking a bit of advice I changed the permissions on my file to make sure it could not be written to. A week or two of uninterrupted traffic and I relaxed thinking all was well again.
Imagine my horror this morning though when I awoke and discovered a mail from my friend Lee telling me the site had been down all day. I logged into my FTP account and sure enough, the .htaccess file had been altered – again. The addition of a single “s” after all the wordpress stuff had knocked my entire site over.
So Who’s Been Dicking Around With My Damned Site??!!!
Well, as it transpires my issue is all thanks to a technology improvement at Clook. One of their support chaps informed me that
“We’ve recently changed the PHP setup slightly which makes scripts like WordPress, Joomla etc. run better as it gives them better permissions on the files. However it looks like your wordpress installation is now able to write to the .htaccess and its writing to it incorrectly”
At this point I was relatively unconcerned, after all wouldn’t Clook be able to sort this issue out for me by pushing their magic techie type buttons just like they always do?
Ummm… Apparently Not!
I was then asked if any of my plugins controlled the .htaccess file (there’s nothing I use that directly says it alters it) so I suggested one which dealt with redirects which was only on LB and one other low traffic site and therefore could be the culprit. Clook responded with
“I would definitely check into that first plugin, especially since it’s only installed on the one site. Since it does manage redirections, it could very well be the culprit. Please let us know what you find.”
I was unable to work out from the code if anything in there might be the villan of this piece but then I’m no programmer, so given that their new setup is clearly causing issues in some scenarios I felt certain they’d want to confirm or deny if that particular plugin could be causing the issue so they could perhaps gain insight for future situations. They were certainly interested enough to ask me to tell them about it.
Alas, “Unfortunately such coding issues are beyond our scope of support.”
Ah. OK then. I suppose they have to draw the line somewhere.
So It’s All Down To A Process of Elimination
Basically, this issue is likely to be down to a plugin performing wicked deeds somewhere. So all that Clook can suggest is a process of elimination. I switch off plugins I think might be causing the issue and wait to see if it happens again.
I find this sort of situation immensely frustrating. I can’t find out what is causing it because I have to wait for it to happen again (if my plugin purge doesn’t fix it), and I can’t stop it from happening again because of the new and improved write access. Perplexed I asked Clook if their new setup was changing file permissions and they told me that in fact
“Our changes don’t make it so that WordPress can modify the permissions on a file, but rather so that it can modify necessary files without you first having to change permissions.
This is noticeable when you try to make changes to a theme. Before the upgrade, you would have to individually modify the permissions on any files (header, footer, etc) before you could make changes to them, then you’d have to change the permissions back. Now that is not necessary.”
Well That’s Quite Good Isn’t It?
Quite a good, convenient change for most Clook users (they did say most people were very happy when I casually mentioned how I personally thought it was shit!). Also, it probably prevents the odd scenario where forgetful people change the permissions to “Yeah baby overwrite me!” and then forget to change them back, subsequently resulting in website hackage and general unhappiness all round.
It’ll also make the whole WordPress setup / customisation process easier.
Do I Like It?
Frankly no, I don’t like it one little bit. I hate the fact that I have handed control of my .htaccess files in particular to WordPress which can sometimes behave in unexpected and unstable ways thanks to its “aggregate” nature, which often results in conflicts. I don’t like that I now have an issue on a rather large site that I can exert no control over whatsoever. Honestly, I feel like an ancient occupant of Troy who has just wheeled in a rather attractive and unexpected garden ornament that’s just convieniently big enough to hold an entire murderous army and retired to bed for the evening. It’s only a matter of time!
It just seems nonsensical that I know where the issue comes from, how it can be stopped, and I simply can’t protect my file from it.
Ah Well, I Needed To Sort Out Uptime Monitoring Anyway
One reason this has been so damaging is that it’s tending to happen when I’m asleep here in Australia. This means the site has been down for an entire UK workday twice now, and I think there have been 2 or 3 other shorter outages which I’ve caught before too much damage was done. Lingerie Brands has gotten to a size where it probably should be monitored, so at least this situation means I’ll stop procrastinating and get it all sorted out. It will mean I’ll probably get woken up at some ungodly hour of the morning if (when) it happens again and will be incredibly grumpy the next time I contact Clook about it.
I did enquire if they might consider adding an opt out sort of system but was told they’ve applied it over all servers for consistency. If I want a customised setup I’ll need to pay for one.
Would I Still Recommend Clook?
Hmmm… I do still really rate their service. Despite me being severely pissed off about this issue I was still very impressed with their support which was prompt, curteous, and as helpful as they could be within the constraints of their role. However, I am deeply uncomfortable about not being able to prevent files I want protecting being overwritten. It just doesn’t feel right and I feel as if my control over my sites has been compromised.
Still, I certainly won’t be moving my site elsewhere so the fact I’m prepared to work through this issue rather than jumping ship must mean I still love them really. Only time will tell if continuing to use them is sustainable.
Now… Who Owes me a Favour?
I’m off to find some technically able type to look at the code of my suspect plugin to see if it is indeed the culprit. I certainly hope so, there’s nothing else I’m using that should be dicking about with the .htaccess file, but it’s always so hard to tell with WordPress!