[wp-trac] [WordPress Trac] #27999: Problem with embedding WordPress Multisite in other PHP applications caused by path difference in ms-settings

[WordPress Trac]

#27999: Problem with embedding WordPress Multisite in other PHP applications caused
by path difference in ms-settings
-------------------------------------+------------------------------
 Reporter:  ivanbajalovic            |       Owner:
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Networks and Sites       |     Version:  3.9
 Severity:  normal                   |  Resolution:
 Keywords:  reporter-feedback close  |     Focuses:  multisite
-------------------------------------+------------------------------
Changes (by jeremyfelt):

 * keywords:   => reporter-feedback close


Comment:

 I think I can reproduce this now.

 1. Install WordPress 3.8.3 in a subfolder `/var/www/wordpress/wp38/`
 2. Configure multisite. Because WP is in a subfolder, only subdirectories
 can be chosen.
 3. Setup a script in `/var/www/default/index.php` to include
 `../../wordpress/wp38/wp-load.php` and do something provided by multisite:
 {{{
 include '../../wordpress-default/wp38/wp-load.php';
 echo get_user_count();
 }}}
 4. Load that page and see the output.
 5. Upgrade to WordPress 3.9
 6. Load that page and get a database error.

 I cannot reproduce this unless WordPress is installed in a subfolder.

 Because we now determine the global `$path` solely on
 `$_SERVER['REQUEST_URI']`, it ends up being completely different than the
 network path of the multisite installation. This is technically different
 behavior from WordPress 3.8.3, but it is worth noting that the path
 process there can result in some very unpredictable paths as well due to
 the logic around `$blogname` that is used to build the final result.

 As an example, my request for `http://foo.bar/custom/index.php` that
 includes `wp-load.php` resulted in a final `$blogname` of `om` because WP
 3.8.3 strips path from blogname before looking up site details.

 I think that this should be a wontfix. That it's worked thus far seems
 much more accidental than anything.

 The multisite bootstrap is different than the standard WordPress bootstrap
 in that the request needs to be parsed to find a site and network. If it
 is being loaded inside another application, the effort should be done
 there to ensure that `$current_site` and `$current_blog` are set properly
 in `sunrise.php` or the custom application itself. As long as these are
 set, there is no trouble loading `wp-load.php` with multisite enabled.

 It is also worth noting that faking the request with
 `$_SERVER['REQUEST_URI'] = '/wp38/';` will also work as a shorter term
 solution.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/27999#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform