WordPress.org

Make WordPress Core

Opened 17 months ago

Closed 17 months ago

Last modified 16 months ago

#22639 closed defect (bug) (fixed)

Multisite in a subdirectory suggests the wrong location for .htaccess

Reported by: nacin Owned by: nacin
Milestone: 3.5 Priority: normal
Severity: normal Version: 3.5
Component: Multisite Keywords: has-patch commit dev-reviewed
Focuses: Cc:

Description

Looks like the code suggests ABSPATH, while it should really be $wp_dir_from_root, I imagine?

It's not just the suggestion — note also the file_exists() checks, etc. Basically, any .htaccess reference in wp-admin/network.php.

Reported here: http://wordpress.org/support/topic/multisite-not-working-correctly-when-wp-installed-in-its-own-directory?replies=1

Previously mentioned here: http://core.trac.wordpress.org/ticket/19796#comment:38

Attachments (10)

22639.patch (1.5 KB) - added by evansolomon 17 months ago.
22639.2.patch (2.5 KB) - added by evansolomon 17 months ago.
Also update file_exists() checks
22639.diff (2.9 KB) - added by ryan 17 months ago.
22639.4.patch (2.8 KB) - added by evansolomon 17 months ago.
22639.2.diff (4.0 KB) - added by nacin 17 months ago.
Fairly ambitious attempt to solve this. (Probably needs slash normalisation for Windows. I spell normalisation with an 's' to bribe dd32 to look.)
22639.3.diff (3.6 KB) - added by nacin 17 months ago.
Less ambitious attempt. Unfortunately, this means we're only using get_home_path() for the displayed text, and not for the areas that count - calculating the base for rewrites.
22639.4.diff (4.0 KB) - added by dd32 17 months ago.
22639.5.diff (3.0 KB) - added by nacin 17 months ago.
Refresh of dd32's attempt.
22639.6.diff (3.0 KB) - added by nacin 17 months ago.
22639.7.diff (2.8 KB) - added by nacin 17 months ago.
A refresh of 3.diff. Fixes the messages only, as the rewrites seem correct.

Download all attachments as: .zip

Change History (22)

evansolomon17 months ago

evansolomon17 months ago

Also update file_exists() checks

comment:1 follow-up: ryan17 months ago

When not running in a subdir, $wp_dir_from_root can be '/'. Thus, the following code will remove all slashes from ABSPATH:

str_replace( $wp_dir_from_root, '', ABSPATH )

ryan17 months ago

comment:2 ryan17 months ago

Tested with single going to multisite and existing multisite with wp installed in a subdir and in root. Windows and IIS not tested.

comment:3 in reply to: ↑ 1 evansolomon17 months ago

Replying to ryan:

When not running in a subdir, $wp_dir_from_root can be '/'. Thus, the following code will remove all slashes from ABSPATH:

str_replace( $wp_dir_from_root, '', ABSPATH )

Good catch. Maybe we should be a little more defensive even. In theory, you could install WordPress in a path like /www/wordpress/public_html/wordpress/, in which case just removing /wordpress would actually break things. Maybe something like this.

preg_replace( '#' . preg_quote( $wp_dir_from_root ) . '$#', '', ABSPATH )

comment:4 dd3217 months ago

Using preg_replace() seems like the safest option to me, anything else introduces the potential for multiple paths like evan pointed out causing issues.

A note however, always remember to use the 2nd param to preg_quote, even if the delimiter has no chance of matching it..

preg_replace( '#' . preg_quote( $wp_dir_from_root, '#' ) . '$#', '', ABSPATH )

evansolomon17 months ago

comment:5 evansolomon17 months ago

.4.patch sets $home_path using preg_replace() (including Dion's improvement). I think it also fixes a bug from 22639.diff where the files (.htaccess and web.config) were part of the string being trailing slashed. Now `$home_path is trailing slashed.

Version 0, edited 17 months ago by evansolomon (next)

comment:6 nacin17 months ago

Consider this scenario:

In this situation, $wp_dir_from_root is /subdir-test/wordpress/. And then there's this:

$base = parse_url( $slashed_home, PHP_URL_PATH );

$base is then /subdir-test/. With that, we calculate $wp_siteurl_subdir, which removes $base from the start of $wp_dir_from_root, leaving you with /wordpress/.

And finally, to calculate $home_path, we shouldn't use ABSPATH minus $wp_dir_from_root, but rather ABSPATH minus $wp_siteurl_subdir. This avoids us from chopping off too much.

With .4.patch, I am told to go to /Users/nacin/Sites. The proper location is /Users/nacin/Sites/subdir-test.

Obviously, we've all been away from this code for a few good months, so I figured I would offer this refresher. For sure, some of this should end up in code comments as we set these 7 different variables at the top of network_step2().

comment:7 nacin17 months ago

And after all that, I realize get_home_path() is the function we should have been using from the start.

nacin17 months ago

Fairly ambitious attempt to solve this. (Probably needs slash normalisation for Windows. I spell normalisation with an 's' to bribe dd32 to look.)

nacin17 months ago

Less ambitious attempt. Unfortunately, this means we're only using get_home_path() for the displayed text, and not for the areas that count - calculating the base for rewrites.

dd3217 months ago

comment:8 nacin17 months ago

In 22980:

Correctly calculate the location of wp-config.php, used in the instructions for setting up a network. see #22639.

nacin17 months ago

Refresh of dd32's attempt.

nacin17 months ago

nacin17 months ago

A refresh of 3.diff. Fixes the messages only, as the rewrites seem correct.

comment:9 markjaquith17 months ago

  • Keywords commit added

.7 is the correct fix. It's written such that it's limited to the issue at hand (which is just a display issue, not a functional issue). I tested it, in multiple WP-in-subdir configurations, and it works.

comment:10 nacin17 months ago

  • Keywords has-patch dev-reviewed added

Yeah, we'll go back down the rabbit hole later on.

Also reviewed by dd32.

comment:11 nacin17 months ago

  • Owner set to nacin
  • Resolution set to fixed
  • Status changed from new to closed

In 22982:

When creating a network, use get_home_path() to calculate where .htaccess (or web.config) lives. fixes #22639.

comment:12 nacin16 months ago

Failure to pursue the rabbit hole resulted in #23073.

Note: See TracTickets for help on using tickets.