iis web.config rule 5 not working

[eduplessis]

Rule 5 not working

<rule name="WordPress Rule 5" stopProcessing="true">
    <match url="^[_0-9a-zA-Z-]+/(wp-(content|admin|includes).*)" ignoreCase="false" />
    <action type="Rewrite" url="{R:2}" />
</rule>

have to change to

<rule name="WordPress Rule 5" stopProcessing="true">
   <match url="^[_0-9a-zA-Z-]+/(wp-content.*|wp-admin.*|wp-includes.*)" ignoreCase="false" />
   <action type="Rewrite" url="{R:1}" />
</rule>

And we need to remove the 2 tab in the begining of the file.

Here is the details for the workaround :

The problem arises when using multi-site in wordpress.

Once wordpress is installed and run on an IIS server, we can make WP to generate the rewrite rules to be used for IIS using this page: ​http://worpress-website.com/wp-admin/network/setup.php

Usually, you just have to copy & paste the rules into the web.config file, BUT there is one rule not working well. Here is what we must replace to make it work :

Original generated rule :

<rule name="WordPress Rule 5" stopProcessing="true">

    <match url="^[_0-9a-zA-Z-]+/(wp-(content|admin|includes).*)" ignoreCase="false" />

    <action type="Rewrite" url="{R:2}" />

</rule>

Modified (working) rule :

<rule name="WordPress Rule 5" stopProcessing="true">

    <match url="^[_0-9a-zA-Z-]+/(wp-content.*|wp-admin.*|wp-includes.*)" ignoreCase="false" />

    <action type="Rewrite" url="{R:1}" />

</rule>

That's about it! I'm pretty sure there is another way to get the rule working. Maybe just changing "R:2" to "R:1" without modifying the parenthesis would also work.

Problem was that, with the original rule, WP redirected to "admin" instead of "wp-admin" which leads to a 404 page not found.

This was tested using WordPress 3.1 on IIS 7 and Windows Azure.

Includes patch for wp-includes/rewrite.php and wp-admin/network.php

carlospaulino: Since I saw your question in #wordpress-dev: The patches look fine to me (Assuming that's the correct fix here of course!) - As you've noted, always make a comment after uploading that you've added a patch, Trac doesn't send emails out when someone just adds a attachment.

Replying to dd32:

carlospaulino: Since I saw your question in #wordpress-dev: The patches look fine to me (Assuming that's the correct fix here of course!) - As you've noted, always make a comment after uploading that you've added a patch, Trac doesn't send emails out when someone just adds a attachment.

Thanks for the feedback!

Marking this for needing testing. Once we've confirmed this on an IIS environment, I think this is good for 3.3. Sending a note to ruslany.

The rewrite rule proposed in the patch is correct. Tested it with URL Rewrite test pattern tool:

url path like this: foobar/wp-content/foobar.php generates {R:1} as wp-content/foobar.php, which is what is expected.

Not sure why the original rule referred to {R:2}. May be there was a mistake in translation of the mod_rewrite rule from the htaccess file?

mod_rewrite also uses $1: ^[_0-9a-zA-Z-]+/(wp-(content|admin|includes).*) $1. I imagine IIS parses it the other way, as I haven't seen a bug report on that. In fairness, it makes more sense the IIS way.

In [19018]:

Use correct capture group in IIS7 multisite subdirectory rewrite rules. props carlospaulino, eduplessis, ruslany. fixes #17708.

IIS parses the regex patterns in a very similar way to mod_rewrite. Actually, if mod-rewrite rule uses this pattern "^{[_0-9a-zA-Z-]+/(wp-(content|admin|includes).*)", then it may be better to use exact same pattern in IIS for consistency reason. That pattern will work fine in the rewrite rule as long as {R:1} is used. I have just tried that in URL Rewrite module as well.}

I got confused here. I thought that mod_rewrite and IIS were consistent in which marker they used, prior to [19018]. Turns out mod_rewrite was set up for $1 and IIS was set up for {R:2}. Both do process the pattern the same way.

So we're good here.

Maybe $force should be set to false as well if $blog->path == $current_site->path and $blog->domain == $current_site->domain.

Nuking either the main site or the root site can take a network to its knees.

Pardon the random comment (#14), that belonged on #19009.