Opened 12 years ago
Closed 9 years ago
#18079 closed feature request (maybelater)
WP has dropped support of the path field in the site table
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.0 |
Component: | Rewrite Rules | Keywords: | has-patch |
Focuses: | multisite | Cc: |
Description (last modified by )
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.
Attachments (1)
Change History (10)
#2
@
12 years ago
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.
#3
@
11 years ago
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...
#4
@
11 years ago
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.
#6
@
11 years ago
- Type changed from defect (bug) to feature request
The configuration described in the ticket did not work in WordPress MU without either sunrise.php or a core hack and a modified .htaccess.
This ticket was mentioned in IRC in #wordpress-dev by nacin. View the logs.
9 years ago
#9
@
9 years ago
- Milestone Awaiting Review deleted
- Resolution set to maybelater
- Status changed from new to closed
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.
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.