Understanding the Default WordPress .htaccess

When maintaining a WordPress site you may find yourself attempting things that normally would work and find that they have unexpected results. This is usually due to how WordPress' default .htaccess rules manipulate the configurations and provide 'pretty permalinks'.

The Default Rules

The default WordPress .htaccess rules are responsible for how WordPress is able to support 'pretty permalinks'. Without these rules in place, WordPress permalinks would not resolve correctly. This feature allows your URLs to look much cleaner and more readable without over complicating or cluttering your website's files structure.

The default rules look as follows:

# 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


• First, you see a comment as indicated by the hashtag; this symbol `#` is used to denote a comment in .htaccess files.
• Next you see an opening brace for Apache's internal "IfModule" function; this specifies that the contained rules should only be used with the "mod_rewrite" module for Apache.
• The Rewrite module is enabled.
• The RewriteBase is declared; this defines the 'root' folder that should be applied to rewrite rules.
• The next line is the first rewrite rule, this rule defines that if an "index.php" file is specifically called then no rewrite is needed.
• The next two lines are both defining rewrite conditions; these conditions are specifying that if no file or folder can be found at the given URL the next rule should be applied.
• Finally, the last rewrite rule before the close brace is for the "IfModule". This rule will only be applied if no file or folder can be found for the URL. If that occurs, the request will be passed to WordPress before providing the client a response.

While this breakdown may be enough of an explanation for some, this is still a very complex chain of rules. The rules are best described and summarized as this: "If Apache itself cannot find the file or folder requested then the request should be dealt with by WordPress directly."

An interesting result of this is that technically all WordPress pages are a 404 result in the context of Apache and only until PHP and WordPress receive the request can any content be resolved for a response.

Tips for Custom Rules

There usually is not a consistent cause for issues experienced when dealing with .htaccess rules on a WordPress site. As the cause can fluctuate from site to site, and even rule to rule, it's hard to provide an extensive explanation for the issues. It is also important to note that plugins and themes can also affect how certain rules are managed as well.

A common rule that causes odd behaviour and provides mixed results usually relates to allowing access based on specific IP address. These rules usually look like:

<Files wp-login.php>
Order deny,allow
Deny from all
Allow from 198.11.109.98 localhost
</Files>


The rule above will deny all IPs access to wp-login.php unless the IP is listed in the 'Allow from' line. While it should work by default, occasionally this can cause issues. If it does, the usual fix is to define the error documents. This would look like:

ErrorDocument 401 default
ErrorDocument 403 default
<Files wp-login.php>
Order deny,allow
Deny from all
Allow from 198.101.159.98 localhost
</Files>


Having these error documents defined explicitly will ensure that when an unapproved IP attempts to access the page they are rejected and are sent a proper error page.

As there are various issues that can come up and each has their own solution, we simply cannot cover them all here. If you believe you are experiencing configuration issues related to those rules mentioned here feel free to contact support. Our sister brand, Nexcess, also offers fully managed WordPress hosting that will help to take care of any implementation issues.