WordPress .htaccess File in Action: Usage Basics

WordPress and .htaccess - Plesk

Yes, WordPress reigns supreme as a CMS, so most modern developers will have encountered WordPress in their daily activities. We’re using this tutorial to explain how one of WordPress’s most important components works. See why the .htaccess file is so important to WordPress functionality, and learn more about configuring your own .htaccess file.

What exactly is a WordPress .htaccess file?

If this is totally familiar to you – great! But if you’ve never heard of the .htaccess file – there’s a reason for that. In almost all cases the .htaccess file will be hidden in your root directory. And sometimes you simply won’t have an .htaccess file at all.

Note that .htaccess is not something unique to WP at all. In fact, it relates to the Apache web server that drives countless websites – including WordPress. So .htaccess is basically a web server configuration file. Your Apache server will look for the .htaccess document whenever it starts your website. And if it exists – it will obey the instructions in it.

Essentially, the .htaccess file helps configure specific Apache settings in order for the web server meet your specific application needs. This could include toggling on or off server functions. Or for example, making a redirect where users who do not add “www” in front of a domain name gets redirected to www.yourdomain.com.

.htaccess is also a way to tighten up security because you can also set privileges for some files. Meanwhile, you can block bots and add additional file handling capabilities via MIME types. Many settings in the .htaccess file are relevant for developers who use it to customize their WordPress.

Creating a default .htaccess file for use in a WordPress instance

Creating a wordpress .htaccess file

Every new WordPress installation will come with a .htaccess file as soon as you install it on Apache. But note that the .htaccess file will be hidden so you must select “show hidden files.” Or a similar option in your operating system. Note that occasionally a WordPress site won’t have a .htaccess file – for example, because of permission-related issues.

Here we’ll explain how to create an .htaccess. The process is broadly similar for most file managers – including those coming with Plesk or cPanel. Alternatively, you can use your computer to create the file and simply upload using a file manager or FTP.

You need to navigate to the root directory of your WP instance – it’s usually simply called public_html. Here, create a new text file and call it “.htaccess”. You can then open this file in a plain text editor of your choice. You’ll notice a few lines of text which basically specifies the default settings for your WordPress site. By  default, the WordPress .htaccess file will contain the following code:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

To make your own file, simply copy the code above and paste it into the .htaccess file you just created. Then save the file, closing your text editor. That’s it, you have just made a brand new .htaccess file. We suggest you visit your website to make sure that it is working. Because a .htaccess file which is not correctly specified will lead to errors, including the dreaded 500 internal error.

Fine-tuning your WordPress instance using the power of .htaccess

When we talk about WordPress performance – not everything depends on WordPress configuration itself. So certain aspects are directly related to web server configuration. Since .htaccess gives you some additional ways on how to control Apache on the level of the certain website . You may use it to fine-tune your WordPress site overall performance.

Browser Caching

Browser caching allows visitors to save items from your web pages. In this case they don’t need to download them again and again while visiting your website. Usually it helps to reduce bandwidth and reduce page loading time.

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType text/css "access 1 year"
ExpiresByType application/pdf "access 1 month"
ExpiresByType text/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 3 days"

File Caching

Server-side file caching helps to serve multiple visitors within the same cache. As a result, the server load reduces and the speed of each page view increases.

Cache htm/html files for 1 week:

<FilesMatch ".(html|htm)$">
Header set Cache-Control "max-age=43200"

Cache plain text files, css and js files for 1 week:

<FilesMatch ".(js|css|pdf|txt)$">
Header set Cache-Control "max-age=604800"

Cache images for one month:

<FilesMatch ".(gif|jpg|jpeg|png)$">
Header set Cache-Control "max-age=2592000"


Disable caching for dynamic files:

<FilesMatch "\.(php|pl|cgi|spl|scgi|fcgi)$">
ExpiresActive Off

Gzip compression on Apache

By enabling gzip compression, you can reduce the size of html, js and css files up to 70%:

<IfModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file \.(html?|txt|css|js|php|pl)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*

Proper character set

In order to inform the browser about certain character set usage required to render the page, you need to specify the page’s character set.

AddDefaultCharset utf-8

Disable image hotlinking

It’s not always a good idea to allow others to use your images on their website with a direct link. Especially considering your server resources and bandwidth. The solution is simple:

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?bing.com [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?google.com [NC]
RewriteRule \.(jpg|jpeg|png|gif)$ – [NC,F,L]

Disable Directory Browsing

Additionally, directory browsing may give a lot of useful information for those who plan to hack your website. To fix this you may use the following:

Options -Indexes

Important files protection

Finally, it’s possible to protect vital files including local php.ini ( if any ), wp-config.php and error logs:

<FilesMatch "^.*(error_log|wp-config\.php|php\.ini|\.[hH][tT][aApP].*)$">
Order deny,allow
Deny from all

WordPress .htaccess usage – In conclusion

To sum up, you need your .htaccess for WordPress to work the way it should. Meanwhile, understand that your .htaccess file can also give you more control over your server features and performance. At the same time, keep an eye out for errors inside the .htaccess file since they may lead to inaccessibility of your website.

If you’re interested in getting exceptional performance for your website, solid security and simple management, try WordPress Toolkit with Plesk. Many have found this to be the optimal solution for their WordPress-based business.

All You Need to Know about the New WordPress Toolkit 3.5 [ VIDEO ]

Plesk WordPress Toolkit 3.5

Your needs come first so rest assured that we’re constantly evolving Plesk to bring you more value. Hence, the release of WordPress Toolkit 3.5, introducing an assortment of new security measures, a reimagined installation experience and more. Read on for a detailed overview of the updates you wanted, a WordPress Toolkit tour, plus WordPress Toolkit 3.6 spoilers.

Quick Tour of the updated WordPress Toolkit

Our pal Joe Casabona was one of the first to take the new WordPress Toolkit 3.5 for a spin. Here’s him demonstrating how easy it is to install and secure your WordPress, update multiple sites, clone and create a staging environment. All in just over 7 minutes!

New WordPress Toolkit Security Measures

New Plesk WordPress Toolkit 3.5 Screenshot 1-new-security-measures

First, you’ll likely see this notification pop up or find your previously secure instances suddenly marked as insecure. But don’t be alarmed – this just means you need to review and update the security status of your WordPress instances. Why? Because WordPress Toolkit 3.5 introduces 8 new security measures.

New Plesk WordPress Toolkit 3.5 Screenshot 2 - new security measures list

1.    New Hotlink Protection

Preventing other websites from displaying, linking or embedding your images (hotlinking), as this quickly drains your bandwidth and can make your site unavailable.

2.    Disable unused scripting languages

This security measure removes support for the scripting languages WordPress doesn’t use, like Python and Perl. Thus, blocking their related vulnerabilities. Available if you have the corresponding Hosting Settings management permission.

3.    New Bot Protection

Blocks bots that overload your site with unwanted requests, causing resource overuse. Note that you may want to temporarily disable this if you also use a service that scans your site for vulnerabilities, since it may also use bots.

4.    Disabled file editing in WP Dashboard

This measure prevents you from editing plugin and theme file sources directly in the WordPress interface. This is an extra protection layer for the WordPress instance in case an admin account is compromised so no malicious executable code gets into plugins or themes.

5.    Block access to sensitive files

Now you can choose to block files like wp-config.bak and wp-config.php.swp, from public access as they contain sensitive information, like connection credentials. Thus, also preventing exposure of files with info used to determine your WordPress instance. Also included are files like logs, shell scripts and other executables that may exist on your WordPress instance and whose security can be compromised.

6.    Block author scans / user ID phishing

These scans find registered usernames, especially WordPress admin, and brute-force attack your site’s login page. The above block prevents this, but note that depending on your site’s permalink configuration, you may also be preventing visitors from accessing pages that list all articles by a certain author.

7.    Block access to .htaccess and .htpasswd

Attackers who gain access to .htaccess and .htpasswd files can exploit your site to a variety of breaches. These files aren’t usually accessible by default, but sometimes they might be. This is where this security measure steps in.

8.    Disable PHP execution in cache directories

If a compromised PHP file ends up in one of the cache directories of your site, executing it can lead to compromising the whole site. So this measure disables execution of PHP files in cache directories to prevent such exploits. However, certain plugins and themes may ignore WordPress Security recommendations and store valid PHP executables in their cache anyway. So you can disable this security feature for them to work, or find a more secure alternative, as recommended.

You’re in Control of Security Updates

You should be able to supervise any website-affecting changes so WordPress Toolkit won’t automatically apply these new security measures on existing installations. So upon opening your list of WordPress instances after the WordPress Toolkit 3.5 update, you’ll see a one-time notification about this.

On that note, you’ll now see that two existing security measures are now less restrictive. First, the “Security of the wp-includes directory” checker now excludes the wp-tinymce.php file to avoid potential issues with Gutenberg and other editing  plugins. Second, the “Security of the wp-content directory” measure now prevents the execution of PHP files only in the wp-content/uploads directory.

New Plesk WordPress Toolkit 3.5 Screenshot 3 - control security updates

These checkers will be reapplied automatically for convenience and do not reduce WordPress security in any noticeable way.

New WordPress Toolkit 3.5 Installation Experience

WordPress Toolkit previously offered two installation options: Quick and Custom. Both had unfortunate shortcomings. ‘Quick’ didn’t ask you questions, but also didn’t give info on the parameters to use when installing WordPress. ‘Custom’ gave you control and displayed everything, but you had to fill out the form.

New WordPress Toolkit installation experience

Now users can make an informed choice whether to confirm defaults and install WordPress quick, or take time to change the options they want. With the new, unified WordPress installation, you can still install WordPress in one click, but you’ll always know how it’s happening. Meanwhile, you can change all relevant installation parameters when necessary.

Bonus: You now have to enable automatic updates of plugins and themes within a more streamlined form, without Search Engine Visibility and Debug Mode.

WordPress Toolkit - Automatic update settings

The final change to the WordPress installation process is the ability to install on any domain from any accessible subscription. This is available anytime you click WordPress in the left navigation panel, even if you’re a reseller or server admin. One small step for WordPress Toolkit, one giant leap for adminkind.

New Plesk WordPress Toolkit 3.5 Screenshot 6 - install on any domain from any accessible subscription

WordPress Classic Plugin anyone?

If you’re not yet ready to use Gutenberg, you have a new ‘WordPress Classic’ plugin set. It also has a sibling ‘WordPress Classic with Jetpack’. However, note that we don’t plan to add immediate support for ClassicPress.

WordPress Classic plugin

Updates to CLI

We updated the CLI command for the new WordPress installation. Specifically adding -auto-updates, -plugins-auto-updates, and -themes-auto-updates to the plesk ext wp-toolkit install command. And plesk ext wp-toolkit –clear-wpt-cache to clean WordPress Toolkit cache and handle issues with invalid cache data like corrupted WordPress distributive lists, or broken lists of languages and versions.

WordPress Toolkit 3.6 Spoilers

The Plesk team fixed a record 43 issues reported by customers and over 140 bugs reported overall. Moving forward, WordPress Toolkit 3.6 will lay foundations for the upcoming release of Remote Management for WordPress Toolkit. Plus, we’re continuing the switch to the new UI, this time redesigning the Clone and Sync procedures along with more relevant user-requested improvements. We’re also busy improving our internal process so we can deliver more high-quality stuff in less time, so stay tuned!