Continuous corruption of htaccess file for WordPress on Digital Ocean

I have a WordPress/WooCommerce site hosted on a Digital Ocean droplet that periodically goes down with Server 500 errors.

After checking the apache logs, I can see it’s caused by the .htaccess file, that when inspected, has been altered incorrectly.

Read More

The most common cause is a line break hasn’t been inserted, merging 2 lines into one:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
--> RewriteBase /RewriteRule ^index.php$ - [L] <--
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

As this is a clients site, the downtime is problematic. I am considering making the .htaccess file readonly, but am concerned this may have unintended side effects.

My suspicion is that it is a poorly written plugin that is trying to add a poorly formatted rewrite rule, but don’t have any way to see which plugin last modified the file. I can’t really go down the route of disabling all plugins and re-enabling one by one.

Has anyone experience this before or have a solution to fix it?

Related posts

2 comments

  1. This is caused by a bug in WordPress that I reported. It happens when “flush_rewrite_rules()” is called simultaneously by two PHP processes.

    Since WooCommerce calls flush_rewrite_rules() often, it’s possible that eventually two of them happen at the same time from two simultaneous requests, and your .htaccess file gets corrupted. (Other plugins that do this can have the same problem.)

    Unfortunately, the bug isn’t getting much traction over there.

  2. I had this happen to me mid last year. Since the client pays me handsomely it didn’t feel like too much work to clone the site onto my laptop and edit my hosts file so that localhost is the client’s domain as far as my laptop can tell.

    And it turns out it was indeed a plugin that caused the problem, a redirection plugin to be specific. It wasn’t the one I would usually use for my sites so I just took note of what redirection rules the client had added with that bad plugin, replaced it with my chosen redirect plugin and manually put in all the redirection rules from the earlier plugin.

    In retrospect it does seem like a lot of work, but hey, that’s why the client pays me well. Plus how else was I going to enable/disable the plugins without affecting the production server?

Comments are closed.