WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 2 years ago

Last modified 2 years 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 2 years ago.
22639.2.patch (2.5 KB) - added by evansolomon 2 years ago.
Also update file_exists() checks
22639.diff (2.9 KB) - added by ryan 2 years ago.
22639.4.patch (2.8 KB) - added by evansolomon 2 years ago.
22639.2.diff (4.0 KB) - added by nacin 2 years 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 2 years 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 2 years ago.
22639.5.diff (3.0 KB) - added by nacin 2 years ago.
Refresh of dd32's attempt.
22639.6.diff (3.0 KB) - added by nacin 2 years ago.
22639.7.diff (2.8 KB) - added by nacin 2 years ago.
A refresh of 3.diff. Fixes the messages only, as the rewrites seem correct.

Download all attachments as: .zip

Change History (22)

@evansolomon2 years ago

@evansolomon2 years ago

Also update file_exists() checks

comment:1 follow-up: @ryan2 years 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 )

@ryan2 years ago

comment:2 @ryan2 years 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 @evansolomon2 years 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 @dd322 years 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 )

@evansolomon2 years ago

comment:5 @evansolomon2 years 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.

Last edited 2 years ago by evansolomon (previous) (diff)

comment:6 @nacin2 years 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 @nacin2 years ago

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

@nacin2 years ago

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

@nacin2 years 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.

@dd322 years ago

comment:8 @nacin2 years ago

In 22980:

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

@nacin2 years ago

Refresh of dd32's attempt.

@nacin2 years ago

@nacin2 years ago

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

comment:9 @markjaquith2 years 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 @nacin2 years ago

  • Keywords has-patch dev-reviewed added

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

Also reviewed by dd32.

comment:11 @nacin2 years 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 @nacin2 years ago

Failure to pursue the rabbit hole resulted in #23073.

Note: See TracTickets for help on using tickets.