Support » Everything else WordPress » Best Practices: Site Development Methodology and Migration Strategy

  • I am re-opening this question (originally posted by NDP) because is is a critical issue in WordPress and the original question was not replied to or resolved.

    “This question has two sides to it: a theoretical one, and a technical one:

    I am trying to resolve a development lifecycle issue with my website design.

    My initial plan was to set up a staging server with an instance of apache/php/mysql and WordPress, develop my content on this staging server, then, at various checkpoints in the development process, deploy my code to a separate instance of apache on the same server (mapped to a different URL).

    My question is:
    Is this a typical website development methodology? The reason why this is not obvious to me, is that I’ve had several difficulties in transferring my content from the staging configuration to production; it doesn’t always seem to go smoothly, and I have yet to find a simple process that just works. That’s the technical side of my question. . “

    My question is almost identical to NDP’s for WordPress 3.1. We are in the middle of migrating 5 new domains on to WordPress and were using the development / staging / Production approach to domains and associated sub-domains. Our experience has only been successful in a completely manual migration mode that has made us seriously question the sustainable viability of the WordPress platform for future client development.

    The above link: does not adequately answer the question or resolve the issue. It seems that almost all the responses provide this same answer given over and over again. Unfortunately, the codex article only addresses the simplest of WordPress installations.

    The issue is practically simple… WordPress needs to define and support a best practice approach to a site design methodology and a site version migration strategy that is typically used in most commercial site deployments. In our situation, we are seeking recommendations to successfully migrate complex WordPress sites (new site functionality as opposed to the Version of WordPress) within a domain from the development environment (a sub-domain) to a “staging” (testing) environment (another sub-domain) and then to the production (live site) environment (production domain). It would appear that this is still a critical weakness in the WordPress platform as of Version 3.1. There are no documented best practices, there are no utilities or scripts published and WordPress incorporates “absolute” or hard-coded URL links in several places that make migration very, very, frustrating and prone to over-sight / error. In a typical commercial environment the site specific variables and links are actively referenced (called) via a global variable declaration file and a dynamic variable declaration file. Until this type of capability is incorporated to support advanced user needs … the developer is stuck manually editing each and every config file, theme and content file. This is not practically supportable or sustainable for sites with complex theme structures, advanced functionality and larger data volumes

    If anyone has found a best practice approach to address this site development and migration issue… Please, please reply. Other post of this nature have simply been closed without any answers and marked as “unresolved”.

    I do not believe that the WordPress or the WordPress community should ignore or overlook this issue.

    Comments welcome and encourage to resolve this issue. Thanx!

Viewing 14 replies - 1 through 14 (of 14 total)
  • 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.

    I had to move a site from to

    Export the database from phpmyadmin and search for “”, “”, and “‘/test/'”
    Replace “” with “”, “” with “” 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.

    Thanx Fonglh !! I will give your suggestions a try. We are just trying to follow “best practices” approach. It is a bit surprising (and then again… maybe not) that the WordPress community has not already addressed this and included the capability as a feature for the current or near future release.

    Still hoping……

    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?

    But fonglh, what do you do when the data in the SQL dump includes URLs embedded in serialized PHP objects? Changing the URLs changes their lengths, thus the serialization values also need changes (the right amount) or the data will fail to deserialize. A simple search/replace on the dump will ruin data.

    Moderator Ipstenu (Mika Epstein)


    🏳️‍🌈 Halfelf Rogue & Plugin Review Team Rep

    I do a search replace on wp_posts only, since that’s (normally) the only thing that needs it.

    However, you can also cheat the other way. If you’re testing it all locally on your own computer, then edit your hosts file so domain.loc is your local install. Then do a search/replace for that and it’ll keep serialization intact.

    Unfortunately I found out about those serialized objects after the search and replace thing. Haven’t run into any problems so far though.

    I’ve seen some plugins mentioned around the forum that can do the search and replace for you, they might handle the serialized data correctly.

    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.

    PS. Are there any suggestions in the ‘Ideas’ area to cover this? I couldn’t find any.

    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.

    Hi SpaceDogDeveloper

    Hope you’ll keep us updated on this. I think I’m about to land a new client where I’ll have to grapple with this problem again … so something easy would be great!

    Moderator Ipstenu (Mika Epstein)


    🏳️‍🌈 Halfelf Rogue & Plugin Review Team Rep

    I JUST ran into this script a couple weeks ago:

    That may be what you need.

    We did a migration this morning using the method I stated previously. The serialization worked EXCEPT it did drop the widgets from the “PHP code Widgets” Plugin we were using. Everything else was intact, so I’d say it was a 93% success.

    @ipstenu, that looks interesting as well. Have you used it at all?

    Moderator Ipstenu (Mika Epstein)


    🏳️‍🌈 Halfelf Rogue & Plugin Review Team Rep

    No, but someone I trust did (which is half of how I found out about it).

    Just adding my two cents. It would make a ton of sense for the WordPress community to identify and promote a best practice approach to controlling WordPress as a CMS using something resembling a standard develop, test, deploy workflow.

    I did find some good ideas in this presentation: Get Control of WordPress with Version Control

Viewing 14 replies - 1 through 14 (of 14 total)
  • The topic ‘Best Practices: Site Development Methodology and Migration Strategy’ is closed to new replies.