What is the best way to load the WP environment in a subdomain of my multisite WordPress install?

2 Views

I have a subfolder install of WP multisite, let’s say at “domain.com”.

I now need to load the WP environment in subdomains of domain.com, say “sub1.domain.com”, “sub2.domain.com”, … “subN.domain.com”. Note that these subdomains do not correspond to WP blogs. But I do need to have access to the logged in user, the database, etc.

Read More

I have set up wildcard subdomains to load a php file that will display what I need for any particular subdomain, and I am including “wp-load.php” early in that file. The problem is that near line 99 in “ms-settings.php” it redirects to the main page of the site because $_SERVER[ ‘HTTP_HOST’] is the subdomain, not the main site domain.

So how can I load the WP environment correctly in a non-blog subdomain?

I have a prototype that works, but I’m worried about the side effects of what I’m doing so it would be great if someone who’s familiar with the core could weigh in.

What I am doing is pre-populating the $current_site and $current_blog globals appropriately before including “wp-load”. Then, “ms-settings” doesn’t try to create these and doesn’t hit the code path that detects the subdomain and redirects to the front page.

I can now access member information (e.g. using ‘get_userdata’) and $wpdb.

Does this seem like a reasonable approach?

Post Views: 2

Related posts

Leave a Reply

4 comments

  1. Use the defines to make it pick the site you want it to pick.

    You can define these four to setup the $current_site values properly: DOMAIN_CURRENT_SITE, PATH_CURRENT_SITE, SITE_ID_CURRENT_SITE, BLOG_ID_CURRENT_SITE.

    If you check the wpmu_current_site() function in ms-load.php, you’ll see that it uses those to create the $current_site global.

    You may or may not have to populate the $current_blog global manually. Not sure. Try it and see.

    So realistically, all you have to do is add something like this before you call wp-load.php:

    define( 'DOMAIN_CURRENT_SITE', 'example.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

    With the right values for your main example.com site, of course.

    If you don’t want to put these in the sub-domain’s php files themselves, then you can do something like this in either the wp-config.php or the sunrise.php file (if you define SUNRISE to true in the wp-config.php as well, of course).

    if ( $_SERVER['HTTP_HOST'] == 'sub1.example.com' || 
     $_SERVER['HTTP_HOST'] == 'sub2.example.com') {
    define( 'DOMAIN_CURRENT_SITE', 'example.com' );
    define( 'PATH_CURRENT_SITE', '/' );
    define( 'SITE_ID_CURRENT_SITE', 1 );
    define( 'BLOG_ID_CURRENT_SITE', 1 );
}

    That’s pretty much what the sunrise file load is there for, to allow a place where you can manually override things like this. Advantage of using sunrise.php over wp-config.php for it (which also works) is that you can easily turn sunrise on and off somewhere else, for testing and debugging and such.

  2. You could give a try to WordPress Mu Domain Mapping plugin.

    Update

    Actually, it better fits on your request to include wp-blog-header.php in the top of your php file of your subdomain, so you can load also the template functions.

        include(dirname(__FILE__) . "/../path_to_my_blog/wp-blog-header.php");

    Or you can do a wp_redirect after the include of wp-load.php

  3. I was attempting the same thing as asked in this question and could not get around the redirect until I spoofed the $_SERVER vars before I included wp-load.php:

    define('WP_USE_THEMES', false);
define( 'DOMAIN_CURRENT_SITE', $siteRow['domain'] );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', $siteRow['wp_blog_id'] );

$_SERVER = array(
    "HTTP_HOST" => $siteRow['domain'],
    "SERVER_NAME" => $siteRow['domain'],
    "REQUEST_URI" => "/",
    "REQUEST_METHOD" => "GET"
);

    The $siteRow array is my own site config, update the variables with what you need.
    No redirect, and all WP functions at your disposal! Enjoy.

  4. I currently use a switch statement to set the DOMAIN_CURRENT_SITE

    I set it up to work when deployed on the live server.
    The switch also sets DOMAIN_CURRENT_SITE for when I’m working locally on my development machine. (thus all the .dev top level domains)

    After the switch statement, I define the other things that don’t change but are MULTISITE related.

    switch ($_SERVER['SERVER_NAME']) {
    case 'sub1.mydomain.com':
    case 'sub2.mydomain.com':
    case 'community.mydomain.com':
        define('DOMAIN_CURRENT_SITE', 'community.mydomain.com');
        break;
    case 'sub1.mydomain.dev':
    case 'sub2.mydomain.dev':
    case 'community.mydomain.dev':
        define('DOMAIN_CURRENT_SITE', 'community.mydomain.dev');
        break;
    default:
        define('DOMAIN_CURRENT_SITE', 'community.mydomain.com');
        break;
}

define('WP_ALLOW_MULTISITE', true);
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true);
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

    Of course this wp-config.php file has more settings in it, but I didn’t include those because they aren’t specific to WP MULTISITE installs.

    Note: When working locally (after downloading the latest sql file. I need to do massive search-replace operations on the database, it’s slightly unrelated to your specific question, but I’m going to leave the wp-cli.org snippet below)

    wp search-replace 'community.mydomain.com' 'community.mydomain.dev' --network --dry-run
wp search-replace 'sub1.mydomain.com' 'sub1.mydomain.dev' --network --dry-run
wp search-replace 'sub2.mydomain.com' 'sub2.mydomain.dev' --network --dry-run