WordPress permalinks settings page should work with IIS 7.0 URL Rewrite Module

[ruslany]

WordPress is able to determine if it is running on Apache and then it offers "Pretty Permalink" options and also auto-generates mod_rewrite rules necessary to support pretty permalinks. However, when WordPress is running on IIS then WordPress always uses "Almost pretty permalinks" with index.php in the URL.

Now, that IIS has a built-in support for URL rewriting, it would be benefitical for WordPress users if WordPress offered "Pretty Permalinks" option when running on IIS 7.0 with url rewriter installed. Also WordPress can auto-generate IIS rewrite rules necessary to support "Pretty Permalinks". This capability will greatly simplify the permalink configuration task for users who host WordPress on IIS.

I already have a patch ready for this enhancement. See attached file for an example how it works.

If you decide to accept this enhancement feel free to assign bug to me to provide the patch.

[ruslany]

Permalinks with IIS URL Rewriting

[DD32]

You can attach a Diff of your changes to this Trac ticket.

[ruslany]

I am working on preparing the diff file: adding comments, etc. Should provide it shortly.

[westi]

It is getting late to include this into version 2.8

Any news on when you might be able to share a patch file?

[ruslany]

The patch with proposed fix is attached. Sorry it took so long. Let me know if you have any questions about the patch or if you need help with testing of patch.

[ruslany]

The patch contains modifications to the following files:

1. /wp-admin/includes/misc.php – added functions to add and remove rewrite rules to/from IIS configuration file
2. /wp-admin/options-permalinks.php – changed the page rendering logic so that it displays “pretty permalinks” options if IIS has URL rewriter installed. Also added logic to render different messages when user saves permalinks configuration when IIS with URL rewriter is used.
3. /wp-includes/functions.php – added function to determine if URL rewriter is installed and loaded in IIS
4. /wp-includes/rewrite.php – added function that generates IIS rewrite rules
5. /wp-includes/vars.php – added a variable that is used to check if IIS 7 is used.

I have tested the patch on Windows Server 2008 with IIS 7 and URL rewrite module installed. I tested it with PHP 5.2.8 and PHP 5.2.9.

[westi]

Thank you for the patch.

I will work through and review and possibly make a few changes to better match the coding style and then get the code into trunk for wider testing.

[ruslany]

Cool! Once it is in the trunk I will test it more on various platforms.

[peaceablewhale]

Changed the keywords in order to let people notice and test it during the Marathon (​http://wordpress.org/development/2009/04/the-super-awesome-wordpress-24-hour-has-patch-marathon/)

[peaceablewhale]

The patch doesn't seem to work with IIS 7.5 on Windows 7 Beta x86 with URL Rewrite Module 1.1 installed. PHP/5.2.9-2 Non-Thread Safe. The permalink options are still in the format of ${ServerHost}/wordpress/index.php/${permalink}. Saving "/archives/%post_id%" in Custom Structure does not generate any rule in web.config and no warning about web.config is displayed.

On the other hand, the misc.php part of WordPressURLRewrite.patch has a conflict with the current trunk revision. I will attach a patch for that (not replacing WordPressURLRewrite.patch).

[peaceablewhale]

New patch to resolve conflict between WordPressURLRewrite.patch and the current revision of misc.php in trunk

[ruslany]

peaceablewhale, thanks for testing the patch and reporting the bug. That problem was caused by an incorrect detection logic which failed to detect URL rewriter when fastcgi impersonation was turned on. I've attached new patch that has a fix for this bug, plus it is also has all the conflicts in misc.php resolved.

[peaceablewhale]

Thanks Ruslan. The new patch works now. I have tested the followings:

1. Enable permalink when the web.config file does not exist and the folder is writable

=> Permalink was enabled successfully and a web.config file with the "wordpress" rule was successfully generated

2. Enable permalink when the web.config file does not exist and the folder is non-writable

=> The patch generated a message asking the user to "update" the web.config file
=> Question: Should more instructions be given to guide the user how to create the web.config file and add the necessary rule?

3. Enable permalink when the web.config file exists with the "wordpress" rule and the file is writable

=> Permalink was enabled successfully

4. Enable permalink when the web.config file exists without the "wordpress" rule and the file is writable

=> Permalink was enabled successfully and the "wordpress" rule was added to web.config successfully

5 Enable permalink when the web.config file exists with the "wordpress" rule and the file is non-writable
=> Permalink was enabled successfully and the user was asked to update the web.config file

6. Enable permalink when the web.config file exists without the "wordpress" rule and the file is non-writable

=> Permalink was enabled successfully and the user was asked to update the web.config file

7. Disable permalink the web.config file exists with the "wordpress" rule and the file is writable

=> Permalink was disabled successfully and the "wordpress" rule in web.config was removed

8. Disable permalink the web.config file exists with the "wordpress" rule and the file is non-writable

=> Permalink was disabled successfully BUT the web.config file was not updated and there is no notice to the user
=> Suggestion: Add a notice asking the user to remove the "wordpress" rule in web.config manually

By the way, an extra question, does this patch work with URL Rewrite Module 1.0?

[ruslany]

Cool. Thanks a lot for testing this!

With URL rewrite 1.0 the patch will not be able to reliably determine the presence of the URL rewrite module, so the permalinks settings will work as if no url rewriting is enabled. Only with URL rewrite 1.1 it is possible to reliably determine the presence of the module because v1.1 sets a server variable indicating that URL rewriting is enabled.

[peaceablewhale]

As Ruslan is looking into adding the notice to remove the rewrite rule if web.config is not writable, I am not going to add the "tested" keyword to this report until he has uploaded a new patch or confirmed that the notice is a "won't fix".

[ruslany]

The notice about removing the rule manually is "won't fix". This is how it works on Apache with .htacess file. Changing that would greatly complicate the logic in the options-permalinks.php page. Plus having this rewrite rule left over in web.config file will not do any harm.

I've attached a new version of the patch which contains minor modification to the information text for the user that explains where to place the rewrite rule inside of web.config file.

[peaceablewhale]

I've tested the new patch and all the 8 conditions tested before now produce expected results.

Regarding the new string, should a slash be added before <configuration> to indicate that it is the root element? In addition, I think that "in web.config file" should be changed to "in the <code>web.config<code> file" (added "the" before web.config and "web.config" should be inside a <code> element).

Since they are minor changes, I've marked the patch as tested.

[ruslany]

Thanks! Since this patch has been already tested and the proposed changes are minor, I am not going to attach another patch. Those changes can be easily made when the patch is checked in.

[Denis-de-Bernardy]

broken patch

[ruslany]

Removed svn:ingore and fixed the conflicts in misc.php

[ruslany]

I've removed the svn:ignore and fixed the conflicts with misc.php. I've changed the milestone back to 2.8.

[hakre]

Small benefit in putting vars in another order and resuse an evaluation.

[Denis-de-Bernardy]

commit? wontfix?

[peaceablewhale]

Tested the new patch. Nothing wrong.

[ryan]

Looks good to me although I would rename is__writable() to something like win_is_writable() because I thought it was a typo for is_writable() at first. :-)

I'll give this a test to make sure apache is still happy. I think westi is going to look at IIS. I'll try to get IIS setup as well. We should be able to get this into 2.8.

[Denis-de-Bernardy]

per ryan's comment

[Denis-de-Bernardy]

there you go

[Denis-de-Bernardy]

against 11256

[Denis-de-Bernardy]

see also: #6631, related to the wp_is_writable function.

[sivel]

From Ryan in #wordpress-dev:

Anyone want to cleanup this patch to better match our coding style (cuddled braces, etc.) and make sure it doesn't break apache rewrite rules?

Cleaned up patch coming in a few moments. My testing shows that this does not seem to interfere or break the apache rewrite rules.

[ruslany]

Tried the cleaned up patch. Works as expected.

[ryan]

(In [11350]) Support IIS 7.0 URL Rewrite Module. Props ruslany. Hat tips to peaceablewhale, hakre, Denis-de-Bernardy, sivel. fixes #8974

[frumph]

Reopening:

• function iis7_save_url_rewrite_rules()
• function iis7_add_rewrite_rule()

These functions need to handle multiple rewrite rules in the rewrite.php for WPMU and future additions to the rewrite rules, right now it's only working for the single rewrite rule, if you add another one it errors the web.config file out on iis7.

Also the creation of the web.config file doesnt happen until you go to the settings - permalinks section itself so flush_rules() on upgrade isn't creating the web.config file - not sure if that's on purpose.

[peaceablewhale]

It seems that the Apache mod_rewrite rules don't support MU either. In addition, the flush_rules behavior appears by design.

[Denis-de-Bernardy]

Please open a WPMU ticket.

[bforchhammer]

For reference: ​MU #1040, ​MU #991