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:
- Apache/.htaccess syntax is hypersensitive
- A single error in syntax/idiom can crash the server
- It’s not safe to assume any pre-existing .htaccess directives
- Existing .htaccess directives may conflict with automatically added rules
- 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).
.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! :)
5 responses to “Stop WordPress from modifying .htaccess”
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 :-(
Yeah the post sort of presupposes the use .htaccess, but I do see your point about NGINX, not everybody runs Apache.
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.
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.
I use nginx too.