Make WordPress Core

Opened 9 years ago

Last modified 8 weeks ago

#14913 reopened defect (bug)

MS Requires Client Information to Load Files

Reported by: filosofo Owned by: filosofo
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.1
Component: Bootstrap/Load Keywords: has-patch, needs-refresh, bulk-reopened
Focuses: multisite Cc:


When installed as multi-site, WP in ms-settings.php tries to parse the Host header request to determine which domain is requested. If none, it prints a redirecting Location header and exits.

This is problematic if you are loading WP but not using a client that sends headers to the server; for example, if you have another app on the same server that tries to include wp-load.php directly.



include '/path/to/wp/wp-load.php';

// let's do some stuff with WP programatically...

The above aborts in MS as it tries to redirect the nonexistent requesting client to the main blog's front page.

The problems I see with this:

  • wp-load.php is supposed to provide a means of circumventing the template printing, so it shouldn't assume a typical browser client is making the request
  • wp-load.php can be used this way on non-MS setups
  • In general, it's a bad jumble of MVC.

Currently I'm not sure what the best route is to fix this, but I will try to come back later with a solution.

Attachments (2)

console-multisite.diff (3.3 KB) - added by wonderboymusic 7 years ago.
14913.diff (3.2 KB) - added by jeremyfelt 6 years ago.

Download all attachments as: .zip

Change History (19)

#1 @nacin
9 years ago

To add to this, as it's somewhat related... It's impossible to execute wp-cron on multisite for ! is_main_site().

#2 @nacin
8 years ago

The offending line is probably the header redirect here: http://core.trac.wordpress.org/browser/trunk/wp-includes/ms-settings.php#L98

Ran into this yesterday trying to execute via wp-load.php from the command line. HTTP_HOST wasn't set, though in this case, it might be set but is different from the main site, and therefore is causing a redirect.

#3 @SergeyBiryukov
8 years ago

Perhaps we can cancel the redirect if WP_USE_THEMES is false? And set $current_blog to the main one, regardless of the domain.

#4 @wonderboymusic
7 years ago

  • Keywords has-patch added; needs-patch removed

Patched - passes all multisite unit tests. Run this before / after patch:

 php -r 'require( "wp-load.php" );'

#5 @wonderboymusic
6 years ago

  • Milestone changed from Future Release to 3.6

This works and still applies cleanly to trunk, passes Unit Tests

#6 @ryan
6 years ago

  • Milestone changed from 3.6 to Future Release

6 years ago

#7 @jeremyfelt
6 years ago

Patch from @wonderboymusic still applied fine to trunk and tests still pass, but had a property change attached as well. Refreshed patch to be only wp-includes/ms-settings.php in 14913.diff

#8 @DavidAnderson
6 years ago

I'd love to see this in 3.7 - I recommend people use "require('wp-load'); do_action('whatever');" to run their backups via the shell/cron (and escape timeout issues) if they can - but this bug means that that advice is broken on multisite.


#9 @DavidAnderson
6 years ago

I've reviewed the patch, and it looks good to me - it only affects the broken situation, and won't impact already-working situations. I've deployed it successfully and so has a client who needed this facility.

#10 @jeremyfelt
5 years ago

  • Component changed from Multisite to Bootstrap/Load
  • Focuses multisite added

#11 @DavidAnderson
5 years ago

  • Focuses multisite removed

I'd love to see this in the next release... for one thing, this issue prevents command-line actions (e.g. command-line backups, thus escaping webserver timeouts) on multisite installs via a method like

<?php require('wp-load.php'); do_action('my_action'); ?>

#12 @nacin
5 years ago

  • Focuses multisite added

Restoring the "multisite" focus accidentally removed.

#13 @chriscct7
4 years ago

  • Keywords needs-refresh added

#14 @johnbillion
4 years ago

How does WP-CLI get around this? I'm guessing it doesn't just load wp-load.php.

#15 @mmihelic
3 years ago

We tried using the posted patch on WP 4.2.4, unfortunately it breaks the site. Understandable, it is 2 years old.
I have also been asking myself how does wp-cli work without the patch?

Regards, Mitja

#16 @iseulde
4 months ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

This ticket has not seen any activity in over *two* years, so I'm closing it as "wontfix".

The ticket may lack decisiveness, may have become irrelevant, or may not have gathered enough interest.

If you think this ticket does deserve some attention again, feel free to reopen.

For bugs, it would be great if you could provide updated steps to reproduce against the latest version of WordPress (5.0.2 at the time of writing). Remember images or a video can be superior to explain a problem. At the very least, quickly test again to make sure the bug still exists.

If it’s an enhancement or feature, some extra motivation may help.

Thank you for your contributions to WordPress! <3

#17 @JeffPaul
8 weeks ago

  • Keywords bulk-reopened added
  • Milestone set to Awaiting Review
  • Resolution wontfix deleted
  • Status changed from closed to reopened

A decision was made to reopen tickets that were closed in the bulk edit that this ticket was affected by. This ticket is being placed back into the Awaiting Review milestone so it can be individually evaluated and verified to determine if it is still relevant/valid or reproducible.

Note: See TracTickets for help on using tickets.