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’.

This article is directly applicable to WordPress on an Apache based server. For WordPress Multi-site or other web servers (Nginx, IIS, etc) please review the official WordPress documentation as rules and configurations may differ.

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]
# END WordPress

To break down what these rules are defining we’ll start at the top and work our way down.
  • 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 localhost

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 localhost

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 our Heroic Support®.

What’s New in WHM 58 & What to Look For

In the 58 update of WHM & cPanel several rather large changes have been made to improve upon user experience and to expand available features. As cPanel works to continually expand and improve their offerings, we like to do our best to keep everyone informed and updated. Here are some of the highlights and items to look out for as the 58 update moves to release tier.

What to prepare for?

When large WHM updates, similar to this one, are released, there are often certain items that may exclude a server from being eligible for the update. These are often referred to as ‘update blockers’ within the official documentation. The items here are changes related to these ‘update blockers’.

  • CentOS 5 & CloudLinux 5 are no longer supported by WHM on and after update 58
    • CentOS 5 itself, and therefore CloudLinux 5, are becoming end-of-life status on March 31 of 2017, due to this and software limitations that these OS’s cause, cPanel is removing support preemptively.
  • Servers’ processors must now support 64-bit processing
    • Any older servers with 32-bit (x86) processes will no longer be supported by cPanel/WHM.
  • For a more detailed list of Upgrade Blockers please see: https://confluence2.cpanel.net/display/ALD/58+Release+Notes
  • These update blockers will require a migration in order to update to WHM 58: Feel free to contact our Heroic Support® if you are experiencing these blocks.

What is new?!

On this release cPanel has included a lot of highly-requested features and improvements. This provides for a lot of new opportunities, but with so many changes, it’s easy to lose track of all the great new features that were added. Here are the highlights:

  • Addon Domain to account conversion tool
    • With this new feature you are now able to easily convert an Addon domain into a full-fledged cPanel account.
  • Roundcube is now provided via RPM’s
  • Support for Dovecot’s mdbox storage format
    • Previously email files were stored on a ‘flat file’ manner, one file for each email. Now a user’s complete email storage can use the mdbox file format.
    • For users with large numbers of emails this should help reduce issues and concerns about using up too many disk Inodes.
  • Dovecot now supports email subaddresses
    • Email users can now append their address in a manner that will automatically deliver a message to a specific folder.
    • E.G.: username+Important@email.com will deliver a message directly to the ‘Important’ folder for the username@email.com address.
  • EasyApache 4 has been released
    • It is the default on new WHM installations
      • Existing servers will need to upgrade manually, once upgraded this cannot be reverted.
    • Now fully supports PEAR and PECL
    • EasyApache config tools have been completed as well
      • Provides useful tools to manage EasyApache 4 profiles
    • PHP-FPM support is now included, although it’s not fully refined yet and must be activated outside of WHM.
      • Contact Heroic Support for assistance on setting up and deploying PHP-FPM.
  • Multi-PHP Manager released
    • With EasyApache 4 being released the new Multi-PHP manager has been completed as well.
    • Servers can now operate while providing multiple PHP versions with ease.
  • PHP 7 is now supported and provided via EasyApache 4
  • AutoSSL
    • Free domain-validated SSL certificates are provided by cPanel (powered by Comodo)
    • As of WHM version 58.0.17, and above, AutoSSL now supports Let’s Encrypt as an SSL provider; for more details, see our KB article here.
Free cPanel-provided hostname SSL’s have been provided since WHM release 56 as well.
  • WHM now provides Composer by default
    • Composer is a dependency management tool for PHP-based projects, used frequently in the development and deployment of PHP-based apps, sites, or projects.
    • The WHM provided version does support Composer’s internal update mechanism to stay updated.

What has been changed?

Based on user feedback cPanel will make changes to presets, or default settings, as well as providing updates for 3rd-party tools included in WHM. This section encompases these types of updates.

  • Munin has been updated to provide the 2.0 version
    • Munin is a free system, network, and infrastructure monitoring tool.
  • Reject SPF failures is now enabled by default.
    • This will ensure that servers are checking incoming mail for valid SPF records and will reject Emails which result in a failure.
    • Provides an easier setup for WHM and helps prevent spam.
  • Prevent ‘nobody’ from sending Email now enabled by default.
    • Apache traditionally runs as the ‘nobody’ user and this change to the settings will ensure that by default servers are secure from Apache sending mail.
    • Helps to prevent compromised or unsecure sites for sending outgoing spam.
  • Dovecot now functioning as the local mail delivery agent
    • Exim will now receive inbound messages, connect to Dovecot via LMTP (Local Mail Transfer Protocol) and then deliver the messages.
  • WHM’s internal version of PHP has been updated

What has been removed?

cPanel will often remove redundant, legacy, or unneeded items or features; some of those to keep an eye out for are:

  • Removed ‘Mailserver Selection’ page from WHM
    • In previous releases WHM removed support for Courier and as such this screen is now unused.
  • Bandmin has been removed
    • Bandwidth usages can still be seen and monitored in:
      • Home >> Account Information >> View Bandwidth Usage, or
      • Home >> Metrics >> Bandwidth
  • Stunnel support has been removed
  • Security Advisor has been removed – check on new vs. existing

For more information and details on the various changes coming in the 58 release of WHM and cPanel, please see the official release notes here: https://confluence2.cpanel.net/display/ALD/58+Release+Notes

If you have any questions or are not comfortable making these changes yourself, please feel free to contact Heroic Support®.

How To Boost Web Server Performance with Nginx and Apache

Apache is the most commonly used web server software on the Internet, and for good reason.

Its long history, general reliability, thorough documentation and active support community have helped it grow to include support for nearly anything a web developer can think to throw at it. But Apache’s universal support has not come without some trade-offs.

Why Apache Alone May Not Meet Your Needs

Apache excels at serving web pages, but its resource requirements (particularly memory) increase as it’s given more to do, thanks to the way Apache manages processes. Apache’s process management is governed by its Multi-Processing Module (MPM). The most common are prefork, worker, and event.

Each time a new request comes in, Apache creates a new process to handle it.

  • In prefork mode, each process contains a single thread (the code which runs inside of a process).
  • In worker mode, each process can contain multiple threads, each handling a single connection.
  • In event mode, each process can contain multiple threads, but each is able to handle more than one connection at a time.

Regardless of the MPM, new processes still are being created to handle new incoming requests (although worker creates fewer than prefork, and event creates fewer than worker).

As requests keep coming in and new processes are created to handle them, CPU and memory usage continue to increase. That drives up load, slows the server down, and ultimately (should the amount of incoming requests far exceed the server’s capabilities) could cause it to become unresponsive. With Apache, scaling up typically requires adding RAM or CPU cores to cope with greatly increased traffic.

And that’s the essential problem Nginx aims to solve: Scalability.

Unlike Apache, Nginx does not create new processes to handle incoming requests. It runs with a set number of processes, typically only one per CPU core, and each of its few processes uses a single thread to handle many requests (potentially thousands) at the same time.

Because of this, Nginx’s resource requirements don’t tend to increase with incoming requests as do Apache’s. And thanks to its small footprint, it’s also able to do the job considerably faster.

One Server’s Weakness Is Another’s Strength

While Nginx’s processes management can be much more efficient and it can serve pages at lightning speed, it’s important to note that the potential performance gains with Nginx are most dramatic when serving static content.

That’s because, unlike Apache’s all-in-one approach, Nginx can serve only static content natively (html, images, javascript and css, etc.). To keep it as lightweight as possible, Nginx relies on separate applications such as PHP FastCGI Process Manager (FPM), Tomcat, or Apache to serve dynamic content.

Unless your site is mostly comprised of static pages, you may decide that there’s not a tremendous amount to be gained by switching from Apache to Nginx outright, given that you’d still need to rely on another application to serve the dynamic content.

And that’s the beauty of using the more-powerful Apache and the more-nimble Nginx together.

In terms of resource usage, Apache doesn’t really care what type of content it’s serving. Processes are created and threads are spun off based only on the number of incoming requests. That makes it somewhat less than ideal for serving extremely large amounts of small, static resources.

By allowing Nginx to serve the static content and pass requests for dynamic content to Apache, you can (for a small amount of overhead up front) effectively eliminate the drain on resources that otherwise would have been caused by having Apache serve all that static content.

Meanwhile, Nginx is caching as it serves, making future requests that much faster still.

This setup, in which Nginx listens on the standard web port (typically 80) and transparently passes requests to the appropriate server, is called a reverse proxy configuration.

Depending on your site’s composition and the number of static resources served, you could find that pairing Nginx and Apache can yield dramatic results.


  • Apache, assuming it already is installed and running, would need to be configured to run on another port.
  • After switching the Apache port, sites on the server would not be accessible at their normal URLs until Nginx is installed, properly configured, and running.
  • Nginx handles virtual hosts (vhosts) differently than Apache, and each existing virtual host entry would need to be recreated for Nginx.
  • Some control panel software, such as cPanel/WHM, does not officially support Nginx (although WHM/cPanel plugins are available).
  • The installation, configuration, troubleshooting and maintenance of Nginx is not supported by Liquid Web on any platform; do not attempt to install any software or modify any configuration files unless you have fully researched the process and know how to address any potential issues that may arise.

Find More Information in Our Knowledge Base