htaccess Difference Between Files and FilesMatch

Whilst writing the two recent articles about blocking xml-rpc access and the matching of files in htaccess.

.htaccess uses Files and FilesMatch to control access to files.

For example for the single file wp-config.php

<Files "wp-config.php">
Order Allow, Deny
allow from all
deny from

There’s also

<FilesMatch "\.(gif|jpe?g|png)$">
Order Allow, Deny
allow from all
deny from

So what’s the difference and when should each be used?

Well none really. Its all about presentation and making the reading of the file easier to view.

When reading down better to see the single Files entry and expect a corresponding single file, in this case wp-config.php. And to have a multiple match of files, as given a number of image extensions. Again the FilesMatch leads the reader to expect that the match will be multiple files.

In the above two examples the files section is used to define the matching criteria and to set the actions associated.

I’ve shown two different example of file selection, but both are configured to allow access to their respective matching files to all visitors, except the single IP address.

Both of the above to examples are code added to the file .htaccess in the root of the website with the purpose of governing the access to files of the website.

An example of this code in use is in the blocking of xml-rpc.

Blocking xml-rpc Access

I’ve heard that I should disable xml-rpc on a WordPress website.

Why should I disable it and how?

XML-RPC What is it? And how to Disable.

What is xml-rpc?

This is the connection for the WordPress API interface.

It allows apps such as the WordPress app on an iPhone or Android device to connect to the WordPress website. With the app I can readily edit and crate blogs posts.

No need to navigate to the website with a browser to login and perform these actions.

Trackbacks and Pingbacks whereby the website checks to see who is referencing its post content.

The popular JetPack plugin, developed by Automattic, relies heavily on the use of xml-rpc.

Why would you want to restrict it?

It poses a security risk.

There’s potentially less chance of detection attempting to gain access this way.

Has the potential to be the target for a denial of service attack.

How to restrict it?

xml-rpc is implemented using the file xmlrpc.php.

Access to the file can be restricted completely or limited to configured IP addresses.

To do this we’ll use the file .htaccess, located in the root of the website, restricting file access by IP Address.

Here’s the block of lines which we’ll add to the file.

# block xml-rpc
<Files "xmlrpc.php">
Order Deny,Allow
deny from all
allow from

We’ll chose to set the order as deny first then allow

Order Deny, Allow

This allows us to block all sites with the simple

deny from all

A one line global block on access.

If we are implementing a full restriction on access that’s all we would need.

But to allow access from a single IP address we add the following

allow from

Further instances of this can be added with single IP addresses or ranges.

Further thoughts

Its going to be a compromise. is there a plugin or app which you can’t do without? If the answer is yes then completely shutting down xml-rpc is probably not going to be an option.

Maybe restrict the access to a limited range or IP addresses. Dependant upon what you wish to connect to it this may be an option. Do you only blog with the WordPress app from a fixed location? Then not a problem.

If none of these is an option for you then leaving access to xml-rpc open will be your option.

Anything more?

Yes, you can use one of the WordPress security plugins to monitor and take action against attempts to gain access via xml-rpc.

And there’s the development of the WordPress Rest API – check to see whether there’s an equivalent of your must have app or program which uses this.


WordPress Codex: XML RPC Support

Wikipedia: XML RPC

Using htaccess to Restrict File Access by IP Address

Every so often there’s a new exploit targeted. This shows as an increase in the rate against a particular file.

For example some time ago there were lots of attempts trying to access to the file upload.php in either themes or plug-ins.

This reflects a vulnerability in an inclusion within a number of themes.

With the aim that only authorised users and IP address shall be looking to upload content I looked towards using the .htaccess file to add the restriction.

The .htaccess file is located in the root of the website. It allows local configuration overrides of the Apache web server.

Blocking access by IP Address

Access is restricted using the old favourite of deny and allow.

For example to only allow access from the IP address of

Order Deny, Allow
Deny from all
Allow from

Here we first set the access rule order to be deny, then allow.

Where the order defines the sequence in which the deny and allow rules are processed.

The actual order in which the rules are presented within the .htaccess file doesn’t matter. Based upon the order either the deny rules will be processed first or the allow ones.

Beware – if the order in the above were set to Order Allow, Deny, the result would be to prevent access to all. The single address would be allowed, followed by all attempts at access being denied.

The restriction can be further adapted to incorporate the files structure. Either individual files or directories.

<Files /index.php>
Order Deny,Allow
Deny from all
Allow from

In the above example a specific file is entered. The index.php file in the root of the website.

An alternative is a match, without the directory structure, with the simple name of the file.

This is the form which we will use, replacing /index.php with upload.php. It will then be restricted in whatever directory it is found, accounting for the potential themes and plug-ins.

<Files upload.php>
Order Deny,Allow
Deny from all
Allow from

Pattern matching, which follows the regular expressions may be used. For example to prevent access to certain file types:

<Files ~ “.(inc|zip|rar)$”>

Here I’ve prevented access to compressed files and includes.

When matching multiple files FilesMatch is used in preference to Files. Although either may be used, its easy to read and gather the implication of the code within the .htaccess file where FilesMatch is showing an expectation of multiple matches, as opposed to the single file.

PHP Fatal error: include_path=’.:/usr/share/php:/usr/share/pear’

A fresh install and an installation of WordPress via the Debian apt package management gave the error

PHP Fatal error: include_path='.:/usr/share/php:/usr/share/pear'

On a development computer I chose to install WordPress via the package manager as opposed to creating Apache site directories.

With MySQL and Apache installed WordPress is added by executing, at the command prompt

apt-get install wordpress.

However, when I first navigated to the website at localhost/wordress/ rather than seeing the start of the me WordPress website creation sequence I had a blank white screen, the so called white screen of death!

Debug reporting can be enabled within the file wp-config.php, located in the root of the website. Here’s the 3 debug options, as disabled:

define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);

The packaged Debian version relocates this to the directory


Editing the file config-localhost.php I enabled debug logging setting my chosen options to true.

Still with a blank screen shown I chose to look at the Apache error log.



tail -f /var/log/apache2/error.log

The last few lines of the log file are:

PHP Warning: require_once(/etc/wordpress/config-localhost.php): failed to open stream: Permission denied in /usr/share/wordpress/wp-config.php on line 19
PHP Fatal error: require_once(): Failed opening required '/etc/wordpress/config-localhost.php' (include_path='.:/usr/share/php:/usr/share/pear') in /usr/share/wordpress/wp-config.php on line 19
PHP Warning: require_once(/etc/wordpress/config-localhost.php): failed to open stream: Permission denied in /usr/share/wordpress/wp-config.php on line 19
PHP Fatal error: require_once(): Failed opening required '/etc/wordpress/config-localhost.php' (include_path='.:/usr/share/php:/usr/share/pear') in /usr/share/wordpress/wp-config.php on line 19

The error suggested that Pear was not installed.

To check to see if pear was installed at command prompt I typed pear

neil@abc:/home/neil# pear
bash: pear: command not found

I then installed pear using

apt-get install php-pear

Giving the following:

Suggested packages:
The following NEW packages will be installed:
0 upgraded, 1 newly installed, 0 to remove and 107 not upgraded.
Need to get 264 kB of archives.
After this operation, 2,108 kB of additional disk space will be used.
Get:1 testing/main amd64 php-pear all 5.6.16+dfsg-2 [264 kB]
Fetched 264 kB in 0s (625 kB/s)  
Selecting previously unselected package php-pear.
(Reading database ... 218176 files and directories currently installed.)
Preparing to unpack .../php-pear_5.6.16+dfsg-2_all.deb ...
Unpacking php-pear (5.6.16+dfsg-2) ...
Setting up php-pear (5.6.16+dfsg-2) ..

A restart of Apache

service apache2 reload

To my disappointment – no effect it still showed the error

Tue Dec 22 13:57:38.596887 2015] [:error] [pid 24889] [client ::1:41744] PHP Fatal error: require_once(): Failed opening required '/etc/wordpress/config-localhost.php' (include_path='.:/usr/share/php:/usr/share/pear') in /usr/share/wordpress/wp-config.php on line 19

I considered the permissions of the file in the directory /etc/wordpress, assigning to it the apache permissions

chown www-data:www-data /etc/wordpress/config-localhost.php

Once more I revisited the website at /localhost/wordpress

Success! I was now getting the WordPress installation.

Open IceDove Email Link in IceWeasel

Links in IceDove email messages weren’t opening in IceWeasel.

How to configure IceDove link options?

I found reports on the Internet that the file ~/.mozilla-thunderbird/default/<profile>/prefs.js should be edited as follows:


I considered IceWeasel’s configuration, available through the about:config

To make mailto links in firefox (iceweasel) open thunderbird (idedove) automatically, type about:config in the address bar and edit (or insert if it doesn’t exist) the following key and value => icedove

There’s a pop-up window to confirm that you know what you are doing:

Changing these advanced settings can be harmful to the stability, security and performance of the application. You should only continue of you are sure of what you are doing.

I'll be careful,  I promise!

I scrolled down the list and changed the entry to IceWeasel.

This didn’t work!

I used the popup dialogue when clicked on the link

  1. From the pop-up menu, select “New”.
  2. From the next pop-up menu, select “String”.
  3. In the pop-up dialog box “Enter preference name”, enter
  4. In the pop-up dialog box “” enter /usr/bin/iceweasel

Subsequent to following the dialogue I tried returning to the preferences and the config editor.

I was only able to find the one entry for IceWeasel in my search. Closing and restarting IceDove

The settings achieved through the linked dialogue proved to be used in place of any settings selected within the preferences.

dpkg: warning root’s PATH should usually contain sbin

Whilst updating a computer:

apt upgrade

It listed all the gets and then concluded with this error:

dpkg: warning: 'ldconfig' not found in PATH or not executable
dpkg: warning: 'start-stop-daemon' not found in PATH or not executable
dpkg: error: 2 expected programs not found in PATH or not executable
Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and /sbin
E: Sub-process /usr/bin/dpkg returned an error code (2)

I chose to resolve by editing root’s .bashrc (/root/.bashrc)file adding an export reference for the path at the end of the file.

export PATH=/sbin:/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin

You’ll need to login afresh for the change to be adopted.

SDDM Fails to Show, Requires Command Line Login First

The computer was showing a command line login. The SDDM login was failing to show.

Once logged in, if I waited a while and then pressed any key the SDDM login screen would appear. Username and password to be entered as usual.

Interestingly in the top bar it was the US layout which was selected (no others available).

I also found that entering the wrong password I was returned to the login screen once more, where the gb layout was shown.

Through searches on the Internet I found this reference

Manjaro forum: sddm very slow to show up

Whilst not my answer, the included reference to this article

Manjaro forum: sddm not loading properly on boot

provided the solution.

The recommendation was to add the haveged package.

First install the package: apt get install haveged

Whilst the recommendation was to enable and start haveged:

systemctl enable haveged
systemctl start haveged

I chose to restart the computer to view whether the problem was persisting.

Problem solved! Albeit still with US layout.

Create Website Thumbnails from the Command line

Creating a new portfolio page for a website I was looking for a simple to use thumbnail creator.

The thumbnail creator should have the following criteria:

  •  minimum of steps, one would be ideal
  • easily repeatable
  • consistent output sizing

I wanted to avoid:

  • resizing the browser to specific dimensions for the next batch. Once closed reproducing the exact sizing from before is problematic
  • not reliant on an external reference, such as the old thumbnail service by Alexa, or the ShrinkTheWeb.

I knew that I could take a screenshot of the browser, either with one of the browser tools or a screen capture program. This could then be transferred to the Gimp for image editing and saving. Or maybe save the images and do a batch conversion with a tool such as XnConvert.

I wanted to keep the thumbnail creation both simple and easily reproducible.

Looking through my previous articles I one about taking screenshots from the command line using wkhtmltopdf.

neil@local:~$ wkhtmltoimage –width 1200 –height 1000

It was easy to put in the website address, an appropriate file name and click return. Done within a few seconds I had a thumbnail of a website capture and saved. Replace the website URLs to work my way through the list.

Create websites from command line:

I did find that pages employing flash had empty spaces. For example this one from Lily Oakes’ website, which incorporates content from YouTube.:

Create websites from command line:

Also one or two with sliders, which were taking longer to render, had missing content. These would be later visited using the slower more fiddly method with browser, screenshot and Gimp.

How to Redirect HTTP to HTTPS Using .htaccess File

With the emphasis on sites being hosted using https rather than http there’s also the redirect of the old website references, to the new encrypted https.

The .htaccess file in the root of the the web site supports the use of redirect rules.

Using htaccess file’s the Rewrite Condition and Rewrite Rule pairing we’ll redirect the http website pages to their corresponding https encrypted version.

Let’s start with the simple redirection.

We’ll begin by redirecting the non encrypted page to the encrypted website. For now we’ll ignore the finer point of serving up the same page.

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP-HOST} [R,L]

In the above example I’ve assumed that redirects don’t already exist. So I’ve added the first action to turn on the rewrites.

This is followed by the condition which we are testing for and the rule to be applied if the match is successful.

In the above we are testing to see if the page is encrypted using https. If not then replace the current URL with the server host name.

The rule, as shown, has 3 parameters: the string to match; the replacement string and some flags for the web server.

In this example

  • (.*)  – take all of the characters in the URL
  • %{HTTP-HOST} is the old website server host server name.
  • [R,L] The R tells the web server (Apache) this is a temporary redirect. Whilst the L to stop any further processing if the rule matches.

Now to take this a step further.

Clearly, entering a page which you have visited before, only to find that you are viewing the root of the website, will not be conducive to a happy website audience. Your visitor won’t care so much that it’s encrypted. It will also affect your website rankings and listings.

Let’s add the extra part to maintain our viewed page.

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R,L]

Now when the old page is visited it redirects to the encrypted one.

The final improvement is to tell the browser and search engine robots that this change is permanent by setting the value of R to 301.

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]


The last part of the line details the type of redirect.

  • 301 is a permanent redirect. change the simple R flag to R=301.
  • 302 is temporary.

It can be very difficult to force a browser to revert after setting a permanent redirect. For this reason it’s best to use a temporary one whilst testing.

Do not duplicate RewriteEngine On.

I’ve seen .htaccess files with a RewriteEngine Off. Make sure your redirect rule isn’t outside of these two tags.

But if when testing your redirect is found not to be working check that it’s within an active RewriteEngine section.

If you have more than one redirect rule in what order in the sequence should this https redirect rule be placed?

Put your https redirect early in your list of redirects.

It’s efficient to handle the specific rules early on. Every rule that is tested is additional server processing giving rise to a slower server and a slower site response. Clear and precise rules should be listed first.

Website Error 406 Not Acceptable

I like to run WordPress websites showing their URL as friendly URLs. The permalink setting of Post name ( is selected for this.

However, on a new WordPress website after clicking on Save changes I was getting a screen showing a 406 not acceptable error.

406 not acceptable

I investigated making this setting manually, editing the file .htaccess.

The section relevant to the permalinks was empty:

# BEGIN WordPress

# END WordPress

I was expecting something more akin to this:

# 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

As a workaround I added in the rewrite code and uploaded to the website. Refreshing the permalink page there was no difference. Reviewing the .htaccess file once more the content between the WordPress lines was once more empty.

Other content within the file was retained an actioned.

Searching the Internet for more details I found reference to ModSecurity.

And here it is on the control panel:

406 not acceptable :control panel modsecurity

Whats the default setting for ModSecurity? Is it active and can it be turned off?

To begin I clicked on the ModSecurity icon.

406 not acceptable :control panel configure modsecurity

In the top row click on the Disable button

406 not acceptable :control panel disable modsecurity

Confirm Disable all.

There you have it: Correcting the 406 Not acceptable error by disabling ModSecurity.