Best Practices: Site Development Methodology and Migration Strategy

I’ve been moving my site from test environment to live site by simply downloading the whole database as an sql file and doing a find and replace on the domain names. Then import this edited file into your live database.

The only other thing you have to do is then to ensure that the wp-content folder is in sync.

Note that sometimes, the domain name is stored with “http://”, sometimes it isn’t, and there’s at least 1 instance where the subfolder (if any) is a separate parameter, but it doesn’t take long to figure out which combinations of domain name to search for.

Example
I had to move a site from https://subdomain.testdomain.com/test to http://livedomain.com

Export the database from phpmyadmin and search for “https://subdomain.testdomain.com”, “subdomain.testdomain.com”, and “‘/test/'”
Replace “https://subdomain.testdomain.com” with “http://livedomain.com”, “subdomain.testdomain.com” with “livedomain.com” and “‘/test/'” with “‘/'”. Note that the double quote marks should not be part of your search string.

This is actually explained in the codex article under the section “Moving WordPress Multisite”, so it does cover more than the simplest installations.

You are right that it’s not practical to edit every config, theme and content file, but I’ve found that the only thing which has to be edited is the database file.

I have separate versions of wp-config.php for my test and live environments. These don’t have to be changed at all after initial setup. I’m not sure what site specific content files you might have, and there are no hardcoded URLs in my theme files. If you have to edit your theme files, you should consider using get_bloginfo()

You can also consider using SVN to keep roll out changes to the live version of your theme. The codex article explains it for WordPress, but you can apply the same principles for your theme files.

My concern is when my Dev environment does not have any of the production content. The only time I’m going to want to upgrade the DB is for a new WP version and/or plugin additions/modifications. Do you guys just exclude some tables from the DB for the export/import into stage and prod? If so, what are your processes/qualifiers for these?

I see there’s been nothing ‘official’ added to this post, which is most disappointing.

We’ve just started to create WordPress sites, having used a different (non-database) platform … where we were able to specify and control the processes of development and production and versioning.
As Robert says, WordPress hasn’t caught up … even though everyone and their dog proclaim it as the best CMS (which just goes to show how little they know about CMS).

Even with the serialisation knowledge, it took me 6 hours to successfully move a large client site on Friday night … complicated further as the hosting was changing to us at the same time.

There are lots of posts over several years from individuals who have shared their experience, but nothing structural from WordPress. What will it take to get this into a future WordPress version?

Unfortunately, we’re not in a position to help or contribute as we have zero experience with .php (and limited knowledge of html and css).

I’m hoping the ball’s in someone’s court … and not completely out of play.

A friend recommended this idea to fix the serialization issue to me, but I haven’t tried it yet…

He says that if you change the WordPress Address and the Site URL in the “General Settings” of WP-Admin to the production URL before doing the search and replace on the DB, it takes care of the serialization problem. However, it does kick you out of your dev environment if you haven’t changed your hosts file.

I’ve experienced a number of issues with Text and other widgets that get dropped doing the search/replace method, I’m hoping to try this out and see if that doesn’t fix that problem.