I have a very simple problem: I want to modify the .htaccess file. It seems I'm not the only person and I've seen the other questions and googled the issue. Nothing helps. Something keeps overwriting the file, sometimes causing it to throw an http 500 on the entire site.

What I already know or tried:

  • I should place the custom htaccess rules outside the Wordpress block (marked by # BEGIN/END wordpress)
  • There is also another block from the caching plugin. My custom rules are outside this block too.
  • Emptying the cache or en/disabling caching altogether does not trigger the problem.
  • At first I put my custom rules between other BEGIN and END blocks that I gave a custom name, but I wasn't sure if Wordpress really looked for # BEGIN wordpress or just for # BEGIN, so I now use an entirely different name.
  • Some sources suggested chmodding the file (-w) so that it can't be changed anymore. I tried this already, it doesn't work, it just gets recreated.
  • There are no clear steps to reproducing the problem. Sometimes it'll last an entire evening without overwriting my code, another time all it takes is two minutes.
  • When the file is overwritten, sometimes it retains part of my custom rules. Between one and two thirds usually, it seems pretty arbitrary. This regularly makes the entire site go HTTP 500 and I have to restore it over ssh (git checkout .htaccess).
  • I've grepped/read through some Wordpress' source code and it all seems to be coded as it should. I indeed see it checking for the BEGIN and END blocks (though the code is uncommented and ugly).
  • I've also added fclose(fopen('htaccess-changed','w')); to the Wordpress function that writes the .htaccess file, but to no avail. The htaccess file got broken again but the htaccess-changed file is never created.
  • Even if I were to give up and just restore a working .htaccess version with every pageload, then still it wouldn't work because the damn thing throws http 500s from time to time. And having a cronjob run every minute is also... I mean come on, do I have to resort to such methods? Even if I did, it might be down randomly for a full minute. And nevermind it being bad practice on a shared webhost.
  • My best guess at the moment is that a wordpress-cron triggers it, but it seems so random that I can't figure out which. It just happened three times in five minutes (finally thought it's reproducible, but nope it doesn't happen anymore now) and the most frequent cron is every quarter hour.

So I've been on this bug for a few days but I'm starting to simply run out of things to try. The site can't go live when it randomly breaks of course.

Any suggestions where to look for the code that overwrites the .htaccess file, and how to make it leave my modifications in place?

Installed plugins: Cherry plugin, Contact form 7, Register Plus Redux, W3 Total Cache and WooCommerce.

Update: The htaccess-changed file has been created, but in the wp-admin directory! I'm also saving the datetime and request-uri, and this shows that it can happen on any request. Mostly I see admin-ajax requests though, and those often happen at a very high rate, which would explain the htaccess file being completely broken (i.e. the requests interfere). Weird that nobody else experiences this though. But at least it's something in the admin panel... but what... Ideas?

  • You say you could restore the .htaccess over ssh. Couldn't you just change/modifiy the file over ssh ? – bestprogrammerintheworld May 4 '14 at 7:13
  • @bestprogrammerintheworld Obviously yes, but then anywhere beween ten seconds and 24 hours later Wordpress will overwrite it. – Luc May 4 '14 at 10:12
  • I don't WP itself would overrite it, maybe some plugin would do it. Do you have any cache plugins? (w3 total cache, w3 super cache etc), security plugins (Like WP Better Security etc) – bestprogrammerintheworld May 4 '14 at 10:15
  • @bestprogrammerintheworld Yes, W3 total cache (like I said in my post). Purging the cache doesn't cause the problem though. Maybe something else but I wouldn't know what else gets triggered. – Luc May 4 '14 at 11:14
  • I really think W3 Total Cache interacts with htacess somehow as well. But try to inactive the plugin temporarily and see if it's the same problem... – bestprogrammerintheworld May 4 '14 at 11:18

You could try changing the permissions on the .htaccess file itself.

755

7 - owner - read/write/execute
5 - group - read/execute
5 - everyone else - read/execute

Neither WP or a plugin can edit/overwrite it; but then you would need to manually change it from there on out.

Maybe that will help you narrow down the issue.

  • As I mentioned in the question already, I tried chmodding so that it couldn't write to it anymore. But it seems to have recreated the file or something, and anyway, it's a workaround and no fix. What if something really does need to change the htaccess file? It's additional manual work to change it then. But regardless, I tried and it didn't work anyway. Edit: Actually, the chmod is currently 644 (same as you suggest but without execute permissions), so it would make no difference. – Luc May 4 '14 at 15:42
  • Could you give the code that you tried when trying to chmod the file? Only the owner should be able to overwrite the file if done correctly. – Douglas.Sesar May 4 '14 at 15:45
  • I can give you the code but it wouldn't matter since, like I said, the current chmod setting (determined by stat .htaccess) is already set to 0644/-rw-r--r--. – Luc May 4 '14 at 15:52
  • If the file is 0644 then find out which apache user is the owner; that may help you narrow down what is editing your file. It should only be able to be written to by the owner or root user. – Douglas.Sesar May 4 '14 at 15:59
  • It's shared hosting so I can't create a dummy user and make it owner of the file. I think either the webserver (they seem to have made a custom one or modified one) runs as root or impersonates the user that I can login via ssh with. I can deny myself write permissions though, and I tried that already, but it didn't help since it can still be recreated or chmodded back. – Luc May 4 '14 at 16:19

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.