WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 3 months ago

#14913 new defect (bug)

MS Requires Client Information to Load Files

Reported by: filosofo Owned by: filosofo
Milestone: Future Release Priority: normal
Severity: normal Version: 3.1
Component: Bootstrap/Load Keywords: has-patch
Focuses: multisite Cc:

Description

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.

Example:

<?php

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 20 months ago.
14913.diff (3.2 KB) - added by jeremyfelt 9 months ago.

Download all attachments as: .zip

Change History (14)

comment:1 nacin4 years ago

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

comment:2 nacin3 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.

comment:3 SergeyBiryukov3 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.

comment:4 wonderboymusic20 months 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" );'

comment:5 wonderboymusic16 months ago

  • Milestone changed from Future Release to 3.6

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

comment:6 ryan11 months ago

  • Milestone changed from 3.6 to Future Release

jeremyfelt9 months ago

comment:7 jeremyfelt9 months 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

comment:8 DavidAnderson8 months 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.

David

comment:9 DavidAnderson7 months 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.

comment:10 jeremyfelt3 months ago

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

comment:11 DavidAnderson3 months 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'); ?>

comment:12 nacin3 months ago

  • Focuses multisite added

Restoring the "multisite" focus accidentally removed.

Note: See TracTickets for help on using tickets.