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?

Improve this question
14
  • look in the error log the line that appears when you have this 404 error.
    – mmm
    Feb 7, 2018 at 8: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 7, 2018 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 7, 2018 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 7, 2018 at 19:32
  • What are file permissions and the owner of that .htaccess file?
    – jet
    Feb 10, 2018 at 16:56

2 Answers 2

Reset to default
0
+50

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.

Improve this answer
1
  • 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, 2018 at 18:13
0

In Apache config file, you have to have: 

AllowOverride All

for that document root.

By default is probably: AllowOverride None

Improve this answer
1
  • 1
    I do have that set. Thats why most of the htaccess rules are working in some scenarios.
    – JoeMoe1984
    Feb 10, 2018 at 3:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .