WP has dropped support of the path field in the site table

[brianlayman]

I've had inquiries about sites that used to work in WordPress Mu that no longer work in WordPress 3.1.

The idea is to have a path based network for each state/province and sites for each city under that, all networks hosted under the same domain.

Like so

Network 1:
Network domain: example.com Network path: /ohio/
    site domain: example.com path: /ohio/akron
    site domain: example.com path: /ohio/canton
    site domain: example.com path: /ohio/uniontown

Network 2:
Network domain: example.com Network path: /pa/
    site domain: example.com path: /pa/pittsburgh
    site domain: example.com path: /pa/greensburg
    site domain: example.com path: /pa/erie

Network 3:
Network domain: example.com Network path: /indiana/
    site domain: example.com path: /indiana/indianapolis

There are two things that are preventing this. First, in new_site, instead of including the path from the sites table for the current network, it uses the global $base variable which is always / in this scenario. Using $current_site->path resolves that.

The second issue is that the .htaccess code is too restrictive. It will the paths on two levels. /network/site/wp-admin/ doesn't work but /site/wp-admin/ does.

Adjusting lines similar to

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

over to

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

resolves that.

The attached patch addresses both of these requirements.

[nacin]

These kinds of rules make things more error prone. The checks were pretty specifically done this way for 3.0, otherwise we start catching any URL with "files" in it and other strange behaviors. I don't recall the MU .htaccess rules from allowing /, either.

I'm not sure about the appropriateness of the change in site-new -- it looks okay to me, I'd think, but then I'd think that more uses of $base should instead be $current_site->path. The other checks can simply be added to an .htaccess file manually.

[brianlayman]

I can agree with that. The .htaccess worried me much more than the site-new.php change. Most of the checks are fine because they look for "wp-" and/or specify what must be at the end of the url. The files redirect is the most problematic. Plus, I think it would be entirely reasonable to require people to customize .htaccess if they were going to try to implement this structure.

The important thing is the site-new.php change so that you don't have to do a core hack to get this performance back. In 99.9999% of the cases $current_site->path is going to be '/'. I didn't do a thorough search for uses of $base as this one file change resolved the issue I was facing.

I/any other willing volunteer, should do a thorough search to see that there are no other instances. I just want to be careful not to break the situation where WordPress is installed in /blog/ or /wordpress/ or whatever.

[brianlayman]

Someone was just asking me about subdirectories in WordPress multisite again.

I still think there is a need for this especially since it broke functionality. This is still out there and working well on my client's sites...

[nacin]

If you install WP in a subdirectory, as in /foo/, then RewriteBase will be /foo/, .htaccess will be inside /foo/, $current_site->path will be /foo/.

These changes are only really for a multi-network situation. Which makes it tricky, the existing rewrite rules work just fine for the first network. Setting up a second network requires direct API calls and in some cases, yes, some .htaccess modifications. So I'm not too concerned about not yet supporting this in core.

Removing $base in favor of $current_site->path all together (proposed for 3.5 elsewhere) and removing ms-files.php all together (ditto) should make this a bit easier in general. Then it's just a few rewrite rules.

[SergeyBiryukov]

Related: #19796

[wpmuguru]

The configuration described in the ticket did not work in WordPress MU without either sunrise.php or a core hack and a modified .htaccess.

[jeremyfelt]

Generating rules for various rewrite scenarios is tough. If we get more traction on a specific scenario, it could make sense. With a configuration like this, I would put the onus on the network admin to ensure configuration is correct.