Make WordPress Core

Opened 13 years ago

Closed 10 years ago

#18079 closed feature request (maybelater)

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

Reported by: brianlayman's profile brianlayman Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.0
Component: Rewrite Rules Keywords: has-patch
Focuses: multisite Cc:

Description (last modified by SergeyBiryukov)

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: Network path: /ohio/
    site domain: path: /ohio/akron
    site domain: path: /ohio/canton
    site domain: path: /ohio/uniontown

Network 2:
Network domain: Network path: /pa/
    site domain: path: /pa/pittsburgh
    site domain: path: /pa/greensburg
    site domain: path: /pa/erie

Network 3:
Network domain: Network path: /indiana/
    site domain: 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)

respect_site_path.diff (5.2 KB) - added by brianlayman 13 years ago.

Download all attachments as: .zip

Change History (10)

#1 @nacin
13 years ago

  • Version changed from 3.2 to 3.0

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.

#2 @brianlayman
13 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 @brianlayman
12 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 @nacin
12 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.

#5 @SergeyBiryukov
12 years ago

  • Description modified (diff)

Related: #19796

#6 @wpmuguru
12 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.

#7 @jeremyfelt
10 years ago

  • Component changed from Multisite to Rewrite Rules
  • Focuses multisite added

This ticket was mentioned in IRC in #wordpress-dev by nacin. View the logs.

10 years ago

#9 @jeremyfelt
10 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.

Note: See TracTickets for help on using tickets.