WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 2 years ago

Last modified 2 years ago

#17708 closed defect (bug) (fixed)

iis web.config rule 5 not working

Reported by: eduplessis Owned by: 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 2 years ago.
Includes patch for wp-includes/rewrite.php and wp-admin/network.php

Download all attachments as: .zip

Change History (16)

comment:1 eduplessis3 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.

comment:2 eduplessis3 years ago

  • Severity changed from normal to critical

comment:3 nacin3 years ago

  • Milestone changed from Awaiting Review to 3.3

carlospaulino2 years ago

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

comment:4 carlospaulino2 years ago

  • Keywords has-patch added; needs-patch removed

comment:5 carlospaulino2 years ago

  • Cc carlospaulino added

comment:6 follow-up: dd322 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.

comment:7 in reply to: ↑ 6 carlospaulino2 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!

comment:8 nacin2 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.

comment:9 ruslany2 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 2 years ago by ruslany (next)

comment:10 nacin2 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.

comment:11 nacin2 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.

comment:12 ruslany2 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 2 years ago by SergeyBiryukov (previous) (diff)

comment:13 nacin2 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.

comment:14 nacin2 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.

comment:15 nacin2 years ago

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

Note: See TracTickets for help on using tickets.