Opened 11 years ago
Last modified 7 years ago
#24963 new defect (bug)
IIS Multisite, Suspected bug in web.config code for URL Rewrite (404 wp-login)
Reported by: | ShaunLeeClarke | Owned by: | |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | 3.5 |
Component: | Rewrite Rules | Keywords: | needs-testing |
Focuses: | multisite | Cc: |
Description
Hello.
I believe I've found a bug in WordPress 3.52 and 3.6 (and possible older versions, but these are the versions I've used).
I'm running a WordPress Multisite website in a Windows IIS environment (yes, I'm a minority!).
The issue is with the web.config code which WordPress provides to configure the URL Rewrite module, specifically with rule 4:
<rule name="WordPress Rule 4" stopProcessing="true"> <match url="^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*)" ignoreCase="false" /> <action type="Rewrite" url="'''{R:1}'''" /> </rule>
I believe that the last line should say {R:2}, not {R:1}.
With the web.config file configured as documented, I am unable to access the dashboard for any sub-sites, and no styling loads for the sub-sites either (presumably it cna't find it's CSS and other associated files).
I've had this working without issues previously (last year), so I dug up an older web.config file. There were two differences. The first was that the newer file does not have a line referencing ms-files.php (I'm guessing it's been obsoleted), and the second change was that this rule used to say {R:2} (which works), while it now says {R:1}.
WordPress provides the code for the web.config file in the Settings > Network Setup Page.
Hope this helps :).
Attachments (1)
Change History (24)
#2
@
11 years ago
Ok, looking closer, [22042] changed the rule from ^[_0-9a-zA-Z-]+/(wp-(content|admin|includes).*)
to ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*)
, so the change from R:1 to R:2 seems correct here.
#3
@
11 years ago
dd32, thank you for the reply.
Hmm - interesting.
All I know is that if I keep it as {R:1}, there are severe issues.
When I originally had this issue I did extensive searching and I'm certainly not the only one to have had this issue...
#4
@
11 years ago
dd32, I started my reply comment before your seconnd comment appeared.
I'll be the first to admit that these URL rewrite URL's are over my head - with your second comment, are you confirming that the config file generated by WordPress is indeed incorrect?
#9
@
11 years ago
- Keywords needs-testing added
Confirmed
In 24963.diff change 'Rule 4' from R:1
to R:2
- Platform: x64 Windows 8.1, IIS 8.5, IIS URL Rewrite Module 2 v7.2.2
- Tested with IIS sub-directory install
- Tested with IIS sub-domain install with configuration as per #25106 Comment 14
Why this change doesn't affect IIS sub domain installs is rewriting my brain cells...
I would suggest this should be tested on IIS 7/7.5/8.0 also as I could only test using 8.5.
If this patch breaks sub domains then a patch with some conditional logic needs to be added for web.config is_subdir_install
/ is_subdomain_install
etc.
#11
@
11 years ago
Platform: Windows Azure 'Web Site'
Setup: WP Multisite (r25760) Sub Directory install using 24963.diff
Sites: <- All sites work 'as expected'
- Primary Site: http://wp24963.azurewebsites.net/
- First Site: http://wp24963.azurewebsites.net/firstsite/
- Second Site: http://wp24963.azurewebsites.net/secondsite/
/wp-admin <- All sites work 'as expected'
- http://wp24963.azurewebsites.net/wp-admin/
- http://wp24963.azurewebsites.net/wp-admin/network/
- http://wp24963.azurewebsites.net/firstsite/wp-admin/
- http://wp24963.azurewebsites.net/secondsite/wp-admin/
/login.php <- Only the primary site
- http://wp24963.azurewebsites.net/wp-login.php <- Yes, works as expected
- http://wp24963.azurewebsites.net/firstsite/wp-login.php <- HTTP 404 Not Found
- http://wp24963.azurewebsites.net/secondsite/wp-login.php <- HTTP 404 Not Found
#12
follow-up:
↓ 13
@
11 years ago
http://wp24963.azurewebsites.net/firstsite/wp-login.php <- HTTP 404 Not Found
Seems like this needs to work. Does this work *without* the patch?
#13
in reply to:
↑ 12
@
11 years ago
Replying to nacin:
http://wp24963.azurewebsites.net/firstsite/wp-login.php <- HTTP 404 Not Found
Seems like this needs to work. Does this work *without* the patch?
No, see results below:
Platform: Windows Azure 'Web Site'
Setup: WP Multisite (r25760) Sub Directory install WITHOUT 24963.diff (i.e. /trunk)
Sites: <- Only the primary site
- Primary Site: http://wp24963.azurewebsites.net/ <- Yes, works as expected
- First Site: http://wp24963.azurewebsites.net/firstsite/ <- HTTP 404 Not Found
- Second Site: http://wp24963.azurewebsites.net/secondsite/ <- HTTP 404 Not Found
/wp-admin <- Only the primary site
- http://wp24963.azurewebsites.net/wp-admin/ <- Yes, works as expected
- http://wp24963.azurewebsites.net/wp-admin/network/ <- Yes, works as expected
- http://wp24963.azurewebsites.net/firstsite/wp-admin/ <- HTTP 404 Not Found
- http://wp24963.azurewebsites.net/secondsite/wp-admin/ <- HTTP 404 Not Found
/login.php <- Only the primary site
- http://wp24963.azurewebsites.net/wp-login.php <- Yes, works as expected
- http://wp24963.azurewebsites.net/firstsite/wp-login.php <- HTTP 404 Not Found
- http://wp24963.azurewebsites.net/secondsite/wp-login.php <- HTTP 404 Not Found
#14
follow-up:
↓ 15
@
11 years ago
- Milestone changed from 3.6.2 to Future Release
These rule suggestions are all screwy. Let's take the time to get it right. I have a feeling the proposed changes will just break something else.
#15
in reply to:
↑ 14
@
11 years ago
Replying to nacin:
These rule suggestions are all screwy. Let's take the time to get it right. I have a feeling the proposed changes will just break something else.
Agreed, I will install two WP IIS multisite, one domain and one sub-directory.
I haven't played with WP's PHPUnit testing (yet) though setting up these sites with the full http://develop.svn.wordpress.org/trunk/ repo with shell access (and WP-CLI if needed) shouldn't be an issue along with a few admin accounts for testing.
#18
follow-up:
↓ 21
@
9 years ago
Any progress? It seems that our 4.2.2 (continually updated from 3.x.x - I don't remember) now with subfolder multisite and domain mapping enabled still suggesting:
<rule name="WordPress Rule 1" stopProcessing="true"> <match url="^index\.php$" ignoreCase="false" /> <action type="None" /> </rule> <rule name="WordPress Rule for Files" stopProcessing="true"> <match url="^([_0-9a-zA-Z-]+/)?files/(.+)" ignoreCase="false" /> <action type="Rewrite" url="wp-includes/ms-files.php?file={R:1}" appendQueryString="false" /> </rule> <rule name="WordPress Rule 2" stopProcessing="true"> <match url="^([_0-9a-zA-Z-]+/)?wp-admin$" ignoreCase="false" /> <action type="Redirect" url="{R:1}wp-admin/" redirectType="Permanent" /> </rule> <rule name="WordPress Rule 3" stopProcessing="true"> <match url="^" ignoreCase="false" /> <conditions logicalGrouping="MatchAny"> <add input="{REQUEST_FILENAME}" matchType="IsFile" ignoreCase="false" /> <add input="{REQUEST_FILENAME}" matchType="IsDirectory" ignoreCase="false" /> </conditions> <action type="None" /> </rule> <rule name="WordPress Rule 4" stopProcessing="true"> <match url="^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*)" ignoreCase="false" /> <action type="Rewrite" url="{R:1}" /> </rule> <rule name="WordPress Rule 5" stopProcessing="true"> <match url="^([_0-9a-zA-Z-]+/)?([_0-9a-zA-Z-]+/)?(.*\.php)$" ignoreCase="false" /> <action type="Rewrite" url="{R:2}" /> </rule> <rule name="WordPress Rule 6" stopProcessing="true"> <match url="." ignoreCase="false" /> <action type="Rewrite" url="index.php" /> </rule>
Rules 1,2,3,6 looks OK, but :
- there is still "WordPress Rule for Files" ... should it? (maybe yes as our multisite was enabled ages ago)
- 4: there should be <action type="Rewrite" url="{R:2}" /> I think
- 5: there should be <action type="Rewrite" url="{R:3}" /> I think
#19
@
9 years ago
My wife was recently setting up a WordPress Multisite instance (4.4.2) on IIS at her work (she finally managed to convince them that SharePoint should only be used for the intranet, and that external sites needed a more appropriate tool). Everything went pretty smoothly until she tried to visit the Dashboard for a sub-site. I can confirm that changing "WordPress Rule 4" to use {R:2}
instead of {R:1}
fixed that problem.
I, too, suspect that Rule 5 needs to change. If it's supposed to be similar to Rules 2 and 4, then I'm thinking it should probably be like:
<rule name="WordPress Rule 5" stopProcessing="true"> <match url="^([_0-9a-zA-Z-]+/)?(([_0-9a-zA-Z-]+/)?(.*\.php))$" ignoreCase="false" /> <action type="Rewrite" url="{R:2}" /> </rule>
With an extra level of parentheses added to capture the (optional) middle directory along with the filename.
Also, if somebody out there in the community is familiar with the details of the IIS rewrite module, and Multisite sub-domain/sub-folder differences, I think that an annotated example of the rewrite rules explaining the differences, and what each rule is supposed to be catching would be a great resource on the Codex.
#20
@
9 years ago
It would be great if @msopentech could reach out to the Azure or IIS team to see if a 'softie could help out here with these IIS rules :)
#21
in reply to:
↑ 18
@
8 years ago
I was having the 404 error trying to access the admin dashboard in a new WordPress multisite installation, and doing this two changes:
- 4: there should be <action type="Rewrite" url="{R:2}" /> I think
- 5: there should be <action type="Rewrite" url="{R:3}" /> I think
solved the error.
This with WordPress 4.7.2 (fresh install) and IIS 8 (windows 2012 R2)
#22
@
8 years ago
- Summary changed from IIS Multisite, Suspected bug in web.config code for URL Rewrite to IIS Multisite, Suspected bug in web.config code for URL Rewrite (404 wp-login)
Hi guys,
I can say "you saved my brain (and my life)".
I also had the 404 error when trying to access subdir sites dashboards and the R:1 to R:2 change in rule #4 solved it !
I suggest to include "404 wp-login" in the title of this post to help guys like me to find this solution.
Here's my web.config (IIS 7.x and wp 4.7.x):
<?xml version="1.0" encoding="UTF-8"?> <configuration> <system.webServer> <rewrite> <rules> <rule name="WordPress Rule 1" stopProcessing="true"> <match url="^index\.php$" ignoreCase="false" /> <action type="None" /> </rule> <rule name="WordPress Rule 2" stopProcessing="true"> <match url="^([_0-9a-zA-Z-]+/)?wp-admin$" ignoreCase="false" /> <action type="Redirect" url="{R:1}wp-admin/" redirectType="Permanent" /> </rule> <rule name="WordPress Rule 3" stopProcessing="true"> <match url="^" ignoreCase="false" /> <conditions logicalGrouping="MatchAny"> <add input="{REQUEST_FILENAME}" matchType="IsFile" ignoreCase="false" /> <add input="{REQUEST_FILENAME}" matchType="IsDirectory" ignoreCase="false" /> </conditions> <action type="None" /> </rule> <rule name="WordPress Rule 4" stopProcessing="true"> <match url="^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*)" ignoreCase="false" /> <action type="Rewrite" url="{R:2}" /> </rule> <rule name="WordPress Rule 5" stopProcessing="true"> <match url="^([_0-9a-zA-Z-]+/)?([_0-9a-zA-Z-]+/)?(.*\.php)$" ignoreCase="false" /> <action type="Rewrite" url="{R:2}" /> </rule> <rule name="WordPress Rule 6" stopProcessing="true"> <match url="." ignoreCase="false" /> <action type="Rewrite" url="index.php" /> </rule> </rules> </rewrite> <defaultDocument enabled="true"> <files> </files> </defaultDocument> </system.webServer> </configuration>
#23
@
7 years ago
This worked for me. Thank you for the fix, I wasted hours of my life!
Replace web.config (rule 4 and 5 only) with this:
<rule name="WordPress Rule 4" stopProcessing="true"> <match url="^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*)" ignoreCase="false" /> <action type="Rewrite" url="{R:2}" /> </rule> <rule name="WordPress Rule 5" stopProcessing="true"> <match url="^([_0-9a-zA-Z-]+/)?([_0-9a-zA-Z-]+/)?(.*\.php)$" ignoreCase="false" /> <action type="Rewrite" url="{R:3}" /> </rule>
Wordpress version 4.8.2
IIS 7.1
Windows Server 2016
This was previously changed from R:2 to R:1 in [19018] + #17708 - Note that says it was for Rule 5, which is now Rule 4 (as the ms-files rule was removed in r21823)