Tip: WordPress Pretty Permalinks on Windows IIS Server

Summary:

A review of two solutions to configure WordPress Pretty Permalinks on Windows IIS Server. This post will help resolve Web.Config errors.

Background

I was working with a client who has his self-hosted WordPress website running on a GoDaddy Windows IIS Hosting Account and encountered some issues with Pretty Permanent Links that I thought were worth sharing.  In brief, the client was having troubles configuring Pretty Permalinks on both his primary WordPress install (root folder) and a second WordPress install under a sub-directory i.e. http://www.example.com/blog on his IIS account.

Why the two installations?

The customer wanted to be able to maintain two separate WordPress templates, one for his primary site at www.johnzada.com and a second template for his blog entries. As he did not allow users on the site maintaining a single user database was not an issue so to reduce server overhead, we decided against a multi-site installation and choose two individual WordPress installations.  As an aside note, both are hosted within the same MySQL Database so that sharing content i.e. users is possible over time.

The following two errors were encountered with Pretty Permalinks on the Windows server:

1. By default, index.php was included in the sites URL.  For example – a default category directory was listed as: http://www.johnzada.com/index.php/on-canada-arctic-edge/
2. The WordPress installation running in a subdirectory would load the home page without any troubles, however, any sub-pages or posts would return a 404 error back to the primary blog.

Solution 1 – Remove index.php from WordPress URL

Pretty Permanent links are available on all active Windows IIS servers.  In our case, Microsoft IIS 7+ web server with the URL Rewrite 1.1+ module and PHP 5 running as FastCGI.   By default, WordPress displays links to posts and pages as :

http://example.com/?p=N

where N is the Post ID number. It works on all server environments, but it doesn’t look as nice as some of the other options.  Using mod_rewrite or lighttpd you can produce much nicer permalinks (see WordPress’s instructions on  Pretty Permalinks). There are many different formats, but the most common, and most versatile looks like:

http://example.com/2012/post-name/

or in my WIndows IIS installation, “Almost Pretty” – notice the index.php embedded in the url as:

http://example.com/index.php/2012/post-name/

These settings are configured under the Permalink Settings under your WordPress installation and look something like this:

Pretty permanent links work on most servers including Apache, IIS, Nginx, and Hiawatha to name a few, however, in all cases require some configuration on the server-side.  In most cases, WordPress will attempt to create the necessary .htaccess (in the case of Apache) automatically when you enable PermLinks however in the case of our Windows Hosting, this was not the case.

Where’s my .htaccess file?

WordPress’s index.php and .htaccess files should be together in the directory indicated by the Site address (URL) setting on your General Options page. Since the name of the file begins with a dot, the file may not be visible through an FTP client unless you change the preferences of the FTP tool to show all files, including the hidden files. The same argument holds true for Windows IIS counterpart Web.config

What is missing in Web.Config

Ruslan Yakushev a Program Manager at Microsoft published a great walkthough on how to enable Pretty Permanent Links on IIS 7 and above.  His walkthrough can be found here, however in brief, you need to create a new URL rewrite rule for WordPress and include it in Web.Cofig.

<rewrite>
<rules>
<rule name=”WordPress” stopProcessing=”true”>
url=”.*” />
<conditions logicalGrouping=”MatchAll”>
<add input=”{REQUEST_FILENAME}” matchType=”IsFile” negate=”true” />
<add input=”{REQUEST_FILENAME}” matchType=”IsDirectory” negate=”true” />
</conditions>
url=”index.php” />
</rule>
</rules>
</rewrite>

This rule will try to match any requested URL. If the URL does not correspond to a file or a folder on the file system, it will rewrite the URL to the Index.php file. At that point, WordPress will determine which content to serve based on the REQUEST_URI server variable that contains the original URL before it was modified by this rule.

Solution 2  – Running WordPress under a Subdirectory

The WordPress installation running in a subdirectory would load the home page without any troubles, however, any sub-pages or posts would return a 404 error back to the primary blog.  What appeared to be happening is that the URL Rewrite request in the web.config under the WordPress installation in the root folder was taking precedence over both sites.

Building on our knowledge of the Windows IIS Web.Config file, the question was how to have Web Server recognize both installations of WordPress.  I admit, I played around trying to configure one Web.Config file to work with both sites, however defaulted to the easiest solution and created a second Web.Config file in the root of the subfolder i.e. http://example.com/blog.

Here are two hints to save you a bit of time:

1. The Rule Name has to be different then the root folder
2. You need to tell the Web Server to ignore the previous set of rules with :  <clear />

Both are accomplished with the following web.config rule:

<rewrite>
<rules>
<clear />
<rule name=”Blog” stopProcessing=”true”>
url=”.*” />
<conditions logicalGrouping=”MatchAll”>
<add input=”{REQUEST_FILENAME}” matchType=”IsFile” negate=”true” />
<add input=”{REQUEST_FILENAME}” matchType=”IsDirectory” negate=”true” />
</conditions>
<action type=”Rewrite” url=”index.php” />
</rule>
</rules>
</rewrite>