Override database config for WordPress multiblog

4 Views

Our team has run in to a problem working with wordpress 3 multiblog.
We usually work with a local copy of the site (localhost/testsite) but with the same database to keep all changes up to date.

This works fine in a single install because you can override the database configs from php with:

Read More
define('URL',$path);  
define('WP_HOME',$path);  
define('WP_SITEURL',$path);  
define( 'WP_CONTENT_URL', $path.'/wp-content');

But this doesn’t work on the multisite because of the extra tables (wp_blogs, wp_site) and they have the path to the blog in their settings.

Does anyone know how to override these settings? I would like the site to run on domain localhost for our developers, developerdomain.com for our test servers and then realdomain.com when the site goes live.

It feels kind of overkill if we have to setup different databases for each of them and change the domain and path manually and then copy the post, blog and userdata between the databases to do debugging and continue the development..

Post Views: 4

Related posts

Leave a Reply

3 comments

  1. Well if you want to do this right, you would have one database for development, one for staging and then the live database. It’s just that WordPress is not designed to live with such commons in software engineering.

    The component I still see publicly missing is a complete migration script that is able to convert all wordpress settings and data in the database from one domain to another as the domain names are “hardcoded” into posts and buried in multiple (often serialized) option values.

    As long as you’re concerned about the few options you listed only, you can hook into pre_option_... filters and change those based on your setup. You could write a define into your config file and change the values accordingly. This might work with multisite setups as well as you’re filtering the actual values from the database.

    Is this a direction?

  2. It’s not as elegant as I’d like, but it does work: You can change your hosts file to point http://www.realdomain.com to localhost.

    Your request to http://www.realdomain.com will then come back to your local machine, find WordPress (if everything is set up correctly), and WordPress will work normally, since it doesn’t realize that it is a local development environment in any way.

    There are drawbacks, but this is a very quick-and-dirty fix.

  3. Okay, this is another cheezy solution, but it seems to work. To replace content that links to http://www.realdomain.com, you’d have to do more.

    Put this in your wp-config.php file after your database information is defined.

        if( 'example-local' == $_SERVER['SERVER_NAME'] ) {

        mysql_connect(DB_HOST, DB_USER, DB_PASSWORD) or die(mysql_error());
        mysql_select_db(DB_NAME) or die(mysql_error());

        $queries[0] = <<<HEREDOC

        UPDATE wp_blogs
        SET domain="example-local"
        WHERE domain="www.example.org"; 

HEREDOC;

        $queries[1] = <<<HEREDOC

        UPDATE wp_options 
        SET option_value = replace( option_value, "www.example.org", "example-local" ); 

HEREDOC;

        for ($i = 4; $i < 9; $i++) {

            $queries[] = 'UPDATE wp_' . $i . '_options 
        SET option_value = replace( option_value, "www.example.org", "example-local" );';

        }   

        foreach( $queries as $query ) { 

            $result = mysql_query( $query );

            if (!$result) {
                die('Invalid query: ' . mysql_error());
            }

        }

    }