Setting up a wordpress network with third level domains

I’ve been looking into setting up a WordPress network install. Everything has been going pretty smoothly until I get to the point where my desired domain layout doesn’t fit well.

I would like to have a layout as follows:

Read More

blog.*.stackexchange.com

so for example, I would like to have multiple sites in a network that look like:

blog.wordpress.stackexchange.com
blog.apple.stackexchange.com
blog.$site.stackexchange.com

I think I could get this working with some creative re-write rules, and manual DNS intervention but I’d rather have a setup where I can hand off the creation of everything but the DNS to someone else (we already have a process for automatically creating all sub-domains needed in DNS)

From my playing around and reading WP really wants the sites to be the next level domain, so in my above example, it wants the main WP blog to be at stackexchange.com and the network blogs to be at wordpress.stackexchange.com.

Is there any way to achieve my desired effect or should I just go the route of doing blog.stackexchange.com/$site ?

Related posts

Leave a Reply

2 comments

  1. You could do this with a customized sunrise.php file. This is essentially how the domain mapping plugin works, however it puts a pretty front end on it. For something custom, you can write some simple PHP to do basically the same thing.

    The essence of multisite involves figuring out what site to serve. The Domain mapping plugin does this by creating a wp_domain_mapping table, and storing the information in there. Thus when it gets a request for xxx.com, it looks in that table and sees that that corresponds to blog_id 123.

    First, make a WordPress setup, and make it multisite. Doesn’t matter where it really lives, because we’re going to change all that. For simplicity, I’d put it at blog.stackexchange.com and make it a subdirectory type site (those are easier). The subdirectories created would likely be the slugs. /wordpress, /apple, /whatever.

    So yes, to start with, you are indeed making it live at blog.stackexchange.com/wordpress. Consider this your staging environment. When you create each site, you can do stuff to it here until you decide to turn on the mapping.

    To do domain mapping yourself, without the plugin, you’d do something like this:

    Step one: add define( 'SUNRISE', 'on' ); to the top of your wp-config.php file.

    Step two: create a sunrise.php file in the wp-content directory. Put <?php at the top to start with.

    Step three: In the sunrise.php file is going to be your logic for determining what site to load.

    You’re going to base this on the $_SERVER[ 'HTTP_HOST' ] variable. How you do that exactly is easy: however you want to do it. If you want to just write a regex to look for '/blog.(.*).stackexchange.com/' and then look for that bit in the database, you can do that.

    Since you’re using the same slug here as the “subdirectory”, you don’t need a separate table. You can just look in the main wp_blogs table to find the site you need. Something similar to this:

    $current_blog = $wpdb->get_var( "SELECT blog_id FROM {$wpdb->blogs} WHERE path = '/wordpress/' LIMIT 1" );

    Once you have the $current_blog, then you need the following code:

    $current_blog->domain = $_SERVER[ 'HTTP_HOST' ];
    $current_blog->path = '/';
    $blog_id = $current_blog->blog_id;
    $site_id = $current_blog->site_id;
    $current_site = $wpdb->get_row( "SELECT * from {$wpdb->site} WHERE id = '{$current_blog->site_id}' LIMIT 0,1" );
    $current_site->blog_id = $current_blog->blog_id;
    

    This pre-defines the $current_blog and $current_site global variables instead of letting WordPress’ MU functions do it.

    This would be enough to get the site up and working (after getting your DNS to point to it and getting the virtual hosting stuff sorted out), however most of the static URLs used in the HTML code would still point to blog.stackexchange.com/wordpress, since that’s where the site would really be. Also, the Canonical URL function would probably not like the URL and would redirect you too.

    To remedy these problems, you’d also likely want to pre-define several of the URLs associated with the site. Things like WP_SITEURL and WP_HOME. Also, WP_CONTENT_URL, WP_PLUGIN_URL, and WPMU_PLUGIN_URL. That should cover most cases of the URLs being adjusted.

    Finally, you’ll want to set the ‘COOKIE_DOMAIN’. Since you likely want logins to be shared across the whole of the thing, you can set it to stackexchange.com, or even higher if you don’t want them to be shared logins.

    If you want to talk about integrating the normal stackexchange login system into WordPress, I can answer questions on that too, but it would be a bit more detailed of an answer. 🙂

    Feel free to email me if you want more help with this. Glad to assist: otto at wordpress.org.