1

First off, the reason I am posting here is I think its due to how I have things setup possibly for my local environment which is why I posted here instead of wordpress.stackexchange.com.

Secondly, the actual problem:

I am trying to setup a multi-site subdirectory install for Wordpress. The htaccess file I have is the one on their codex website:

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]

Everything works so far with the current website. All admin pages work. All front end pages work with pretty urls. So .htaccess is doing its thing.

Now when I add a new site, I visit its admin dashboard area and this is where things go wrong. Any url that is of this pattern http://website.com/[site-name]/wp-admin/[page].php returns a 404 error usually with the message "file not found".

This is strange because Wordpress usually knows what to do at this point based off of the htaccess file.

So this rule would only run if the file exists:

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]

So if the file does not exist then the rule after is checked and ran if it matches

RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]

So for example: this url http://website.com/my-site/wp-admin/settings.php Should rewrite to this http://website.com/wp-admin/settings.php where the file does exist. But, it appears that this is not happening despite the rewrite rules working for everything else Wordpress related. It just appears to fail and not really give a damn about anything else.

Question

Why is this failing? Where else can I test to debug this issue?

Some system/environment info:

OS: MacOS - Sierra
Apache: Apache/2.4.27 (Unix)
PHP: Served through fcgi proxy

One thing to note is I did update to Sierra somewhat recently but I can't confirm this setup working before the update.

Update

I added Rewrite logs to the error logs. When I visit a url that is a folder like so: http://website.com/does/not/exist I get a log history of all the patterns mod_rewrite tests and that shows there was a rewrite to the index.php file where Wordpress serves the 404 error. So this is working as expected.

When I again go to this url http://website.com/new-site/wp-admin/settings.php I get the 404 error with 'file not found' on the page BUT.....its not logged. So I assume that Apache is returning the 404 error before it reaches the htaccess with all the mod_rewrite stuff.

Important Note I want to reiterate that htaccess is working. The only scenario where apache serves the 404 error before it reaches the htaccess file is when I use a url that has a file extension. So I feel like apache is using something else first to handle that 404 well in advance before the htaccess gets a chance to rewrite anything. Hence why the logs work in any other scenario but not for urls like http://website.com/my-site/wp-admin/settings.php.

I have checked the http.conf file but nothing seems obvious as to what could be handling the file not found stuff.

UPDATE 2018-02-11

Ok so I think I am on to something. This probably has something to do with the ProxyPassMatch condition I have setup in my virtual host config. Here is what the contents of that file look like:

<VirtualHost *:*>
    ServerName wp-test.test
    DocumentRoot "/Users/joemoe-mac/Sites/wp-test.test/public"
    ErrorLog "/Users/joemoe-mac/Sites/wp-test.test/logs/errors.log"

    LogLevel debug

    ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://127.0.0.1:9056/Users/joemoe-mac/Sites/wp-test.test/public/$
</VirtualHost>

Now I have been using the curl command to make a request to keep the log output simple. I would test the load-scripts.php file from the main website at http://wp-test.test/wp-admin/load-scripts.php which works as expected and then I would test the failed one at http://wp-test.test/testing/wp-admin/load-scripts.php.

testing in this example is the name of the subsite. Now here is the logs of each:

http://wp-test.test/wp-admin/load-scripts.php

[authz_core:debug] [pid 14276] mod_authz_core.c(834): [client 127.0.0.1:50972] AH01628: authorization result: granted (no directives)
[proxy_fcgi:debug] [pid 14276] mod_proxy_fcgi.c(108): [client 127.0.0.1:50972] AH01060: set r->filename to proxy:fcgi://127.0.0.1:9056/Users/joemoe-mac/Sites/wp-test.test/public/wp-admin/load-scripts.php
[proxy:debug] [pid 14276] mod_proxy.c(1226): [client 127.0.0.1:50972] AH01143: Running scheme fcgi handler (attempt 0)
[proxy_fcgi:debug] [pid 14276] mod_proxy_fcgi.c(993): [client 127.0.0.1:50972] AH01076: url: fcgi://127.0.0.1:9056/Users/joemoe-mac/Sites/wp-test.test/public/wp-admin/load-scripts.php proxyname: (null) proxyport: 0
[proxy_fcgi:debug] [pid 14276] mod_proxy_fcgi.c(1002): [client 127.0.0.1:50972] AH01078: serving URL fcgi://127.0.0.1:9056/Users/joemoe-mac/Sites/wp-test.test/public/wp-admin/load-scripts.php
[proxy:debug] [pid 14276] proxy_util.c(2154): AH00942: FCGI: has acquired connection for (*)
[proxy:debug] [pid 14276] proxy_util.c(2208): [client 127.0.0.1:50972] AH00944: connecting fcgi://127.0.0.1:9056/Users/joemoe-mac/Sites/wp-test.test/public/wp-admin/load-scripts.php to 127.0.0.1:9056
[proxy:debug] [pid 14276] proxy_util.c(2417): [client 127.0.0.1:50972] AH00947: connected /Users/joemoe-mac/Sites/wp-test.test/public/wp-admin/load-scripts.php to 127.0.0.1:9056
[proxy:debug] [pid 14276] proxy_util.c(2883): AH02824: FCGI: connection established with 127.0.0.1:9056 (*)
[proxy:debug] [pid 14276] proxy_util.c(2169): AH00943: FCGI: has released connection for (*)

http://wp-test.test/testing/wp-admin/load-scripts.php

[authz_core:debug] [pid 14220] mod_authz_core.c(834): [client 127.0.0.1:64869] AH01628: authorization result: granted (no directives)
[proxy_fcgi:debug] [pid 14220] mod_proxy_fcgi.c(108): [client 127.0.0.1:64869] AH01060: set r->filename to proxy:fcgi://127.0.0.1:9056/Users/joemoe-mac/Sites/wp-test.test/public/testing/wp-admin/load-scripts.php
[proxy:debug] [pid 14220] mod_proxy.c(1226): [client 127.0.0.1:64869] AH01143: Running scheme fcgi handler (attempt 0)
[proxy_fcgi:debug] [pid 14220] mod_proxy_fcgi.c(993): [client 127.0.0.1:64869] AH01076: url: fcgi://127.0.0.1:9056/Users/joemoe-mac/Sites/wp-test.test/public/testing/wp-admin/load-scripts.php proxyname: (null) proxyport: 0
[proxy_fcgi:debug] [pid 14220] mod_proxy_fcgi.c(1002): [client 127.0.0.1:64869] AH01078: serving URL fcgi://127.0.0.1:9056/Users/joemoe-mac/Sites/wp-test.test/public/testing/wp-admin/load-scripts.php
[proxy:debug] [pid 14220] proxy_util.c(2154): AH00942: FCGI: has acquired connection for (*)
[proxy:debug] [pid 14220] proxy_util.c(2208): [client 127.0.0.1:64869] AH00944: connecting fcgi://127.0.0.1:9056/Users/joemoe-mac/Sites/wp-test.test/public/testing/wp-admin/load-scripts.php to 127.0.0.1:9056
[proxy:debug] [pid 14220] proxy_util.c(2417): [client 127.0.0.1:64869] AH00947: connected /Users/joemoe-mac/Sites/wp-test.test/public/testing/wp-admin/load-scripts.php to 127.0.0.1:9056
[proxy:debug] [pid 14220] proxy_util.c(2883): AH02824: FCGI: connection established with 127.0.0.1:9056 (*)
[proxy_fcgi:error] [pid 14220] [client 127.0.0.1:64869] AH01071: Got error 'Primary script unknown\n'
[proxy:debug] [pid 14220] proxy_util.c(2169): AH00943: FCGI: has released connection for (*)

For the URLs that are having problems it seems to be consistently showing this line in the logs:

[proxy_fcgi:error] [pid 14220] [client 127.0.0.1:64869] AH01071: Got error 'Primary script unknown\n'

So it appears that everytime ProxyPassMatch tries to match to a file that doesn't exist I get the 'file not found' error. Its trying to map to this location: /Users/joemoe-mac/Sites/wp-test.test/public/testing/wp-admin/load-scripts.php when the file is located here /Users/joemoe-mac/Sites/wp-test.test/public/wp-admin/load-scripts.php without the testing folder (because subsites share the same files as the main site)

I guess my next question is how do I setup a proxy properly with a Wordpress Subdirectory multisite?

JoeMoe1984
  • 77
  • 1
  • 1
  • 9
  • look in the error log the line that appears when you have this 404 error. – mmm Feb 07 '18 at 08:32
  • @mmm I just enabled logging for rewrites so I could provide more info. However, there was nothing logged when I tested certain 404 urls. I updated the original question with more details. – JoeMoe1984 Feb 07 '18 at 17:26
  • you write that Apache return 404 error before to log but there is another possibility : Apache rewrite the URL and launch WordPress but it's WordPress which send the 404 error. – mmm Feb 07 '18 at 18:31
  • Thats not whats happening. This is not a Wordpress 404 page its a basic 404 file not found. If I try an incorrect URL on the front end I get a Wordpress 404 error. Which is expected. If I try to access anything with a `.php` extension and its not found I get the Apache 404 error page. On the Admin area Wordpress rewrites `.php` extensions from a multisite url like `my-site/wp-admin/settings.php` to the normal path `wp-admin/settings.php` where the file exists but the mod_rewrite rules aren't being executed at all to even try to rewrite that url. – JoeMoe1984 Feb 07 '18 at 19:32
  • What are file permissions and the owner of that .htaccess file? – jet Feb 10 '18 at 16:56
  • @jet how would permissions be an issue if the mod_rewrite rules in the htaccess work for the other urls? I don't think permissions are the issue. Apache can read it just fine – JoeMoe1984 Feb 10 '18 at 17:11
  • if is not readable for www-data user (you don't say which distro)- good luck with that. – jet Feb 10 '18 at 21:52
  • What do you mean by distro? I said the OS is a Mac and which version. – JoeMoe1984 Feb 10 '18 at 21:54
  • This question is off-topic on ServerFault — https://serverfault.com/help/on-topic; it's also WAY too long and convoluted; there is no possible way anyone can provide an answer for it; mostly likely because the relevant parts of the config aren't even included within the question. – cnst Feb 12 '18 at 04:57
  • @cnst yeah it got longer as I was constantly debugging stuff and wanted to provide details of what I tried. Do you think this is a superuser type question? – JoeMoe1984 Feb 12 '18 at 05:04
  • It sounds like you run this on a desktop/laptop, and the complaint is that your `cpanel` or equivalent doesn't work, so, it's definitely offtopic here; not sure where it's on-topic, the best idea would be to reduce the question to a reasonable size and try to dress it as ontopic here, TBH — provide actual config that doesn't work, tell us exactly how you think it should work (and why) and how it doesn't work. Basically, just the standard stuff; noone's really interested in pages and pages of dead-ends and unrelated troubleshooting. – cnst Feb 12 '18 at 05:09
  • @cnst it's not through a cpanel setup. It's all manually setup by editing config files and installing Apache and php. Also, I did mention how it's supposed to work. If the part where I explain is not clear enough I can rewrite a bunch of stuff so it's shorter and retains just the relevant parts – JoeMoe1984 Feb 12 '18 at 05:14
  • @cnst but it is off of a desktop so not sure if that matters for it to be on server fault. I just assumed because it's server technologies being used that it was relevant here – JoeMoe1984 Feb 12 '18 at 05:16
  • @JoeMoe1984 folks here are often nice even if you try to ask questions about desktop use of server technologies, but officially, it's still offtopic, as per the FAQ. – cnst Feb 12 '18 at 06:40

2 Answers2

0

In Apache config file, you have to have: 

AllowOverride All

for that document root.

By default is probably: AllowOverride None

jet
  • 475
  • 4
  • 8
0

Yes, take a look at your Apache VirtualHost ProxyPassMatch config. Here is a config example for that.

And if serving WordPress through a reverse proxy with https you might need to additonally take care of this.

Bob
  • 422
  • 2
  • 5
  • Yeah, this was the article I found after discovering that ProxyPassMatch might be the culprit. That answer was the solution to my problem. However, since the issue was the same I would almost say that this question should be considered a duplicate. Either way someone needs to get this bounty so here ya go. – JoeMoe1984 Feb 15 '18 at 18:13