Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

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:

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..

share|improve this question
    
I don't know that I would suggest sharing a database between the development, staging, and live server. The team I work with has tried several different versions of this through the years and finally settled on the fact that the best solution is to have separate databases. We've created scripts to automatically export the data from one server, replace the domain names and import into another database to simplify the process of getting the latest data. –  prettyboymp Nov 10 '10 at 3:00
add comment

3 Answers

Okay, this is another cheezy solution, but it seems to work. To replace content that links to 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());
            }

        }

    }
share|improve this answer
add comment

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

Your request to 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.

share|improve this answer
add comment

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?

share|improve this answer
    
Everything would be so, so much easier if WordPress didn't hardcode the site URL into database entries. Neither Drupal nor Joomla! (IIRC) have this issue. It would be a series of simple crontabs to do daily migrations from staging to development were it not for this. As a dev who regularly works with many different CMSes, this just comes off as amateur... </rant> –  aendrew Oct 4 '12 at 11:43
1  
Yes such a script is still publicly missing. Components to do the work do exist as free software. So yes Wordpress is amateurish at that point. Less because of the site URL (I'm biased with that as well but it has good sides, too) but just with lack of official support tools. –  hakre Oct 4 '12 at 11:58
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.