Make WordPress Core

Opened 13 years ago

Closed 12 years ago

Last modified 12 years ago

#17708 closed defect (bug) (fixed)

iis web.config rule 5 not working

Reported by: eduplessis's profile eduplessis Owned by: nacin's profile nacin
Milestone: 3.3 Priority: normal
Severity: critical Version: 3.1
Component: IIS Keywords: has-patch needs-testing
Focuses: Cc:

Description

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.

Attachments (1)

17708.patch (1.3 KB) - added by carlospaulino 12 years ago.
Includes patch for wp-includes/rewrite.php and wp-admin/network.php

Download all attachments as: .zip

Change History (16)

#1 @eduplessis
13 years ago

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.

#2 @eduplessis
12 years ago

  • Severity changed from normal to critical

#3 @nacin
12 years ago

  • Milestone changed from Awaiting Review to 3.3

@carlospaulino
12 years ago

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

#4 @carlospaulino
12 years ago

  • Keywords has-patch added; needs-patch removed

#5 @carlospaulino
12 years ago

  • Cc carlospaulino added

#6 follow-up: @dd32
12 years ago

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.

#7 in reply to: ↑ 6 @carlospaulino
12 years ago

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!

#8 @nacin
12 years ago

  • Keywords needs-testing added

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.

#9 @ruslany
12 years ago

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:1}. May be there was a mistake in translation of the mod_rewrite rule from the htaccess file?

Version 0, edited 12 years ago by ruslany (next)

#10 @nacin
12 years ago

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.

#11 @nacin
12 years ago

  • Owner set to nacin
  • Resolution set to fixed
  • Status changed from new to closed

In [19018]:

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

#12 @ruslany
12 years ago

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.

Last edited 12 years ago by SergeyBiryukov (previous) (diff)

#13 @nacin
12 years ago

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.

#14 @nacin
12 years ago

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.

#15 @nacin
12 years ago

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

Note: See TracTickets for help on using tickets.