Spring Sale! Save 30% on all books w/ code: PLANET24
Web Dev + WordPress + Security

Stop WordPress from modifying .htaccess

[ Perishable Press : Stop WordPress from modifying .htaccess ] By default, depending on file permissions, WordPress automatically will modify the contents of your site’s .htaccess file. It does this on several occasions, adding and/or updating the rewrite rules required for WP’s permalink functionality. This post explains how this works, why it can be dangerous, and how to stop it from happening.

What WordPress does

When permalinks are enabled on your site (under General > Permalinks), WordPress automatically will modify your .htaccess file with the latest rewrite rules. So if your .htaccess file has owner write access (very common), WordPress will write to the file with a block of directives similar to the following:

# 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 far as I know, this only applies to non-Multisite WP installations (i.e., WP doesn’t automatically add the rules required to enable WP Multisite, although I could be wrong about this). In any case, for regular WP installations, WordPress will add these rules whenever permalinks are invoked. Here are some details:

  • # BEGIN WordPress and # END WordPress serve as markers used by WordPress
  • If the markers do not exist, the permalink rules will at added at the end of the .htaccess file
  • If the markers do exist, whatever code located between the markers will be updated automatically
  • So you can move your permalink rules (to someplace other than at the end of the file) by moving the entire block of code (markers included)
  • If you have customized your permalink rules between the markers, the changes will be overridden by WordPress
  • There is no way to remove the empty line before the closing marker :(

So the big moral of the story here is that you need to add any custom .htaccess rules outside of the BEGIN and END markers. Otherwise WordPress will overwrite them with the default permalink rules.

Why its bad

So given the previous points, if you have:

  • Custom permalink rules inside of the BEGIN and END markers, WordPress will remove them
  • Custom permalink rules outside of the markers (e.g., not using any markers), then WP will add another set of rewrite rules at the end of the .htaccess file

Either of these scenarios can be dangerous, especially if the custom rules are required for site functionality, navigation, etc.

For example, at my WordPress Bookstore, I use custom permalink rules to account for variations in store items, custom/short URLs, and more. So in my .htaccess file, the permalink rules are highly customized, and proper store functionality depends on a very carefully crafted set of directives.

So because the block of custom rules is not wrapped with BEGIN/END markers, WordPress was taking liberty and adding its own default set of permalink rules at the end of my .htaccess file. These default rules were redundant and could have interfered with normal functionality, especially if my custom rules had not been written properly (e.g., if I had omitted the L flag).

And it would have been disastrous if I had made the mistake of wrapping my custom rules with the BEGIN/END markers.. then WordPress would have overwritten everything and things definitely would have been broken (badly). Incidentally, the only reason I didn’t use the WP markers is because, as an .htaccess aficionado, I think they look horrible, especially with that stupid blank line. Ironically it’s this superficial aesthetic preference that prevented complete site breakage, but I digress.

Do you think the millions of other WordPress users are as careful with the contents of their own .htaccess files? I shudder to think at the frustration and wasted time brought about by this default WP functionality. Here are a few good reasons why automatically modifying the .htaccess file is never a good idea:

  1. Apache/.htaccess syntax is hypersensitive
  2. A single error in syntax/idiom can crash the server
  3. It’s not safe to assume any pre-existing .htaccess directives
  4. Existing .htaccess directives may conflict with automatically added rules
  5. Any additions to .htaccess should be tested thoroughly before going live, especially when other rules may be in play

Before looking at ways to stop WordPress from changing the .htaccess file, it is important to understand that taking any steps to prevent the default behavior may cause something to not work as intended. Really it’s not a big deal, however, as .htaccess files by default are not writable on many servers; so lots of WordPress users already operate in this capacity without issue. </disclaimer>

Make it stop

So now that we’re all on the same page with WP’s auto modification of the .htaccess file, let’s look at how to prevent it from happening (or not).

Update! For another, arguably better technique to prevent WordPress from modifying your .htaccess file, check out my recent tutorial, Stop WordPress from Changing .htaccess.

Method 1: Lock it down

The cleanest way, in my opinion, is to make the .htaccess file “read-only”. By changing the file permissions to read-only, WordPress will not be able to modify it. As explained in this support thread:

“WordPress specifically checks if both the home path and the .htaccess file in the home path are writable, using the PHP is_writable function. If it’s not writable (aka, read-only), WordPress does not attempt to write to it. If you’re on a Linux based hosting system, make the .htaccess file have 444 or 440 or 400 permissions. Use the smallest one that still works.”

For example, on my server, a chmod value of 444 worked like magic. But on your server depending on configuration, you may need to dial it down even further, using 440 or even 400. Always best to test thoroughly, and/or ask your host if any doubt.

So the permissions change is a solid solution, but understand that it will prevent anything — WordPress, plugins, themes, etc. — from making changes to the .htaccess file. Consequently you yourself won’t be able to make changes to the file via SSH/SFTP/etc. So for example, if you want to quickly block a brute-force attack, you’ll need to set the permissions of your .htaccess file back to 644 (or whatever) in order to make any changes.

Depending on how frequently you need to modify your .htaccess file, this can get tedious. So if locking down file permissions doesn’t seem like an ideal solution, you may want to consider method #2..

Method 2: Add a filter

If you want to stop WordPress from automatically updating your permalink rules, but also want to ensure that the file is writable for other purposes, then you can add the following filter via plugin (or theme functions, etc.):

// Stop WordPress from modifying .htaccess permalink rules
add_filter('flush_rewrite_rules_hard','__return_false');

This will prevent WordPress from modifying the permalink rules in your .htaccess file (or web.config file, if using Windows server). The only downside to this approach is that you’ll have to be mindful of any changes that WordPress makes to its default permalink rules, and update your .htaccess file accordingly. Fortunately this is rare; in my 10+ years working with WordPress, the permalink rules have been changed only once.

Method 3: Customize outside of the markers

As mentioned previously, if you don’t mind WordPress and plugins writing to your .htaccess file, you can simply add and custom .htaccess rules outside of the BEGIN/END markers. That way WordPress can keep the permalink rules up to date, and other plugins can continue to do whatever they want to your .htaccess file. Of course, implementing custom rewrite/permalink rules without actually modifying WP’s default rules is easier said than done ;)

Method 4: Do nothing

Last but not least, you can always just let WordPress update your .htaccess file as it pleases. A couple of points about this strategy:

  • Only recommended if you do not need any custom permalink rules
  • While it should be fine to let WordPress core make changes, it’s your call as to whether or not plugins et al should enjoy the same write privileges

So in case you’re thinking, “what a nutjob, telling me to not allow WordPress to do whatever it wants”, relax. I’m saying that there are scenarios where WP’s auto-writing can be dangerous. But if you’re always using the default permalink rules, then you’re probably safe allowing WordPress to make changes automatically. WordPress is a well-tested and generally reliable piece of software ;)

Notes

In the process of setting .htaccess permissions for a couple of my own sites, I managed to take a few notes for future reference. You can ignore this section if you are not making any permissions changes. Otherwise, you may find it useful.

Default .htaccess permissions   = 644 (rw- r-- r--)
Read-only .htaccess permissions = 444 (r-- r-- r--)

Online tool: CHMOD Calculator

Note: When WordPress does NOT have write access to the .htaccess file, making a change to the Permalink settings results in an admin notice that says, “You should update your .htaccess now”. Additionally a set of .htaccess rules will be displayed near the bottom of the page. Otherwise, if WordPress does have write access to the file, these items will not be displayed.

Thanks for reading. Remember to vote this November! :)

About the Author
Jeff Starr = Designer. Developer. Producer. Writer. Editor. Etc.
WP Themes In Depth: Build and sell awesome WordPress themes.

5 responses to “Stop WordPress from modifying .htaccess”

  1. Avi Hayun 2016/10/14 2:23 am

    Jeff,

    The main reason why changing the htaccess is not a god methodology for wordpress is NginX web server which doesn’t have an htaccess file.

    I wish wordpress would change the permalinks to work using an other mechanism.

    I also hate the idea that plugins feel free to tamper with the htaccess file as they see fit – who knows if this plugin’s author knows exactly what he does !? – if not my site can crash in a loud boom :-(

    • Jeff Starr 2016/10/14 7:21 am

      Yeah the post sort of presupposes the use .htaccess, but I do see your point about NGINX, not everybody runs Apache.

  2. I’ve had my .htaccess file locked down with 444 permissions for many years. There have been too many times where a plugin has trashed parts of my file while trying to make it’s own changes. That’s also why I often make a extra manual backup of my .htaccess file before making too many changes.

    I do like your second method of adding a filter, but I fear it would not stop some of the damage I’ve seen from plugins rather than WordPress itself. I suspect some plugins look for their own markers and cause damage because something else in the file is similar to their marker and the search hasn’t been coded carefully enough.

  3. Desmondo Bernfeld 2016/10/24 8:45 am

    I’ve had my .htaccess file locked down with 444 permissions for many years.
    @doug smith | i hope you found a solution now … being locked out for many years :). i assume its a typo and very funny

    there would be ways to port it to nginx. In most cases, at least nowadays, people with nginx servers have shell access. It would be really easy to port.

    i think jeff starr’s solution is better than the php based detection since it is faster and on a earlier level (faster too).

    So make your port to nginx or use a heavy loading IDS to distrurb 99% of your legit traffic by trying to catch 1% of bad requests.

  4. Mindaugas 2016/11/11 4:09 am

    I use nginx too.

Comments are closed for this post. Something to add? Let me know.
Welcome
Perishable Press is operated by Jeff Starr, a professional web developer and book author with two decades of experience. Here you will find posts about web development, WordPress, security, and more »
Digging Into WordPress: Take your WordPress skills to the next level.
Thoughts
I live right next door to the absolute loudest car in town. And the owner loves to drive it.
8G Firewall now out of beta testing, ready for use on production sites.
It's all about that ad revenue baby.
Note to self: encrypting 500 GB of data on my iMac takes around 8 hours.
Getting back into things after a bit of a break. Currently 7° F outside. Chillz.
2024 is going to make 2020 look like a vacation. Prepare accordingly.
First snow of the year :)
Newsletter
Get news, updates, deals & tips via email.
Email kept private. Easy unsubscribe anytime.