How can I prevent WordPress and plugins from overwriting my .htaccess file? I use Wordpress to set the structure of my permalinks; so I doubt it is practical to deny all permissions to the file.

If it is unlikely that WordPress is responsible for overwriting the file, advice on determining what is responsible would be helpful.

I recently added these rules to .htaccess to redirect traffic to HTTPS.

    RewriteCond %{HTTPS} off
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

One day later, I found that .htaccess had reverted to its previous state. Following is a portion of the .htaccess file as I intend it.

# BEGIN W3TC Page Cache core
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteCond %{HTTPS} off
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
    RewriteCond %{HTTPS} =on
    RewriteRule .* - [E=W3TC_SSL:_ssl]
    RewriteCond %{SERVER_PORT} =443
    RewriteRule .* - [E=W3TC_SSL:_ssl]
    RewriteCond %{HTTP:Accept-Encoding} gzip
    RewriteRule .* - [E=W3TC_ENC:_gzip]
    RewriteCond %{HTTP_COOKIE} w3tc_preview [NC]
    RewriteRule .* - [E=W3TC_PREVIEW:_preview]
    RewriteCond %{REQUEST_METHOD} !=POST
    RewriteCond %{QUERY_STRING} =""
    RewriteCond %{REQUEST_URI} \/$
    RewriteCond %{HTTP_COOKIE} !(comment_author|wp\-postpass|w3tc_logged_out|wordpress_logged_in|wptouch_switch_toggle) [NC]
    RewriteCond "%{DOCUMENT_ROOT}/wp-content/cache/page_enhanced/%{HTTP_HOST}/%{REQUEST_URI}/_index%{ENV:W3TC_SSL}%{ENV:W3TC_PREVIEW}.html%{ENV:W3TC_ENC}" -f
    RewriteRule .* "/wp-content/cache/page_enhanced/%{HTTP_HOST}/%{REQUEST_URI}/_index%{ENV:W3TC_SSL}%{ENV:W3TC_PREVIEW}.html%{ENV:W3TC_ENC}" [L]
# END W3TC Page Cache core

This code redirects traffic with a status of 301 as expected, until the .htaccess file is overwritten.

--Update-- By placing comments in several sections of the .htaccess file and observing which one was overwritten, I found that plugin W3 Total Cache overwrote the entirety of the section commented with

# BEGIN W3TC Page Cache core

If you place your "custom" directives outside of any # BEGIN ... / # END ... comment markers then WordPress (and plugins) should not overwrite them when they update. (Of course, if you have plugins that don't "play nice" then they could do anything to .htaccess if you let them, so you would need to do something like what @haz suggests in this case.)

In your case, you can simply place those directives above the # BEGIN W3TC Page Cache core comment. For example:

# Custom directives
RewriteCond %{HTTPS} off
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

# BEGIN W3TC Page Cache core
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteCond %{HTTPS} =on
    RewriteRule .* - [E=W3TC_SSL:_ssl]

You don't need to repeat the RewriteEngine On directive (providing it occurs somewhere in the file). And your directives are not using RewriteBase anyway - but again, RewriteBase should only occur once in the file. (The last instance of each of these directives is what controls the entire file.)

(Aside: The parentheses around the RewriteRule pattern are superfluous in your directive.)

  • 1
    This solution worked without requiring that I disable access to .htaccess by all plugins. – Jacob Quisenberry Oct 22 '17 at 17:57

Wordpress will definitely rewrite your .htaccess file under certain circumstances, such as if you change Permalinks.

Like you, we have a bunch of custom things in out .htaccess file, which I'd prefer to leave in the hands of our devOps guys rather than Wordpress.

The easiest way if you have access to the server is to change the file permissions on .htaccess

& chmod a-w .htaccess

This removes write access for all users. If you don't have shell access to your Wordpress instance, your hosting provider might provide a file explorer type setting where you might be able to alter your file permissions.

Alternatively, you could change the file ownership:

& chown root:root .htaccess
& chmod 644 .htaccess

This may not work depending on your Apache user settings, and is almost certainly not an option provided by your hosting provider.

A third option you can use, which once again requires you to be in control of your server, is to put your immutable settings (such as as your HTTPS rewrite) into a different include file in your VirtualHost settings.

<VirtualHost *>
    ServerName www.mysite.com
    DocumentRoot /var/www/mysite.com/wordpress/
    Include /var/www/mysite.com/custom-apache-settings.conf

As haz stated in his answer, WordPress will (and should be able to) overwrite the .htaccess.

You can use mod_rewrite_rules filter to add you own, though. To keep it simple, you could add a file .htaccess.custom, put your rules in there and add its content to $rules in the filter. Don't forget to return $rules.

  • wordpress should never be able to overwrite any file outside of the uploads directory, unless you enjoy having hacked sites – Mark Kaplun Oct 9 '17 at 7:25
  • 1
    Whether the backdoor sits inside the uploads directory or not doesn't really matter, your WP (and, depending on your paranoia, system) has to go. Also making WP unable to overwrite files makes it a pain to keep core & plugins updated, which I consider a much bigger security risk. – janh Oct 9 '17 at 7:32
  • it makes it "pain" only if you are lazy and like your sites to be hacked (no personal attack intended). No change to the coding enviroment should be able to be done without explicit human consent. – Mark Kaplun Oct 9 '17 at 8:25
  • .... out of the 6 minor releases of 4.7 5 broke some functionality. I can't see how having a broken web site for who know how much time is less painful than doing an attended update which should take 2 minutes, and if it fails you can immidiately restore backup, something which is harder to do when the site was running with bugs for a while and new content was added in that period of time – Mark Kaplun Oct 9 '17 at 8:32
  • I totally agree with you in theory. However, in practice, most WP sites aren't run by professionals, and for them (and the internet at large), a (partially) "broken" site is much, much better than an un-updated, insecure site. Without auto-updates (or easy update mechanisms that just require a few clicks, not fiddling with rights), lots (I'm betting: the majority) of sites wouldn't get updated at all. – janh Oct 9 '17 at 9:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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