Title: Migrating changes through environments Last modified: August 20, 2016 --- # Migrating changes through environments * [mpcee123](https://wordpress.org/support/users/michaelpcook/) * (@michaelpcook) * [14 years, 9 months ago](https://wordpress.org/support/topic/migrating-changes-through-environments/) * WordPress Community, * I’m a relatively new WordPress user, and I haven’t coded much of anything in quite some time. However, I’ve been doing my best to pour over all the documentation that’s out there regarding WordPress in an effort to understand some best practices for getting a new site up and going. I am currently working on one site, but I hope to launch many more over the coming months–thus, my search for best practices. * I started dabbling with my new site, but I soon realized that I’d need a testing environment. Therefore, after a ton of online reading, I was able to successfully establish [http://dev.mysite.com](http://dev.mysite.com), which is now basically just a mirror of [http://www.mysite.com](http://www.mysite.com). I used the “ Moving WordPress” tutorial in the Codex–and several other great resources, for that matter–to successfully make the necessary database updates, file moves, configurations, etc. My URLs seemed to work, and I was happy. * Currently, I’m in the process of establishing a local installation of WordPress using XAMPP by using the “Test Driving WordPress” tutorial in the Codex, not to mention a few other tutorials for good measure. There’s enough information out there where I feel relatively confident in my ability to get that piece up and running. However, the more I learn and think about things, the more questions I have. Enter the issues described below: * Moving files seems to be relatively straightforward, as there are many comparison tools out there–and for the more ambitious, content versioning systems. However, with WordPress storing so much information in the database, I can’t seem to wrap my head around how one can successfully migrate/merge database information through multiple environments. * For example, say I do some design work locally–maybe even install a plugin or two (i.e. some database changes are made). I then deploy the changes to my [http://dev.mysite.com](http://dev.mysite.com) website to share the proposed changes with a client (making all the ugly database URL updates and such that are required–ugh.) Say I get the “go ahead” for production. Now what? The production database will have posts, comments, and other data present that I’ll need, but it won’t have the proper structure, plugins, design changes, etc. that I just made. How do I reconcile this issue? Do I only merge certain tables from the development environment? If so, where do I look to learn how to do this? Again, my mySQL and PHP skills aren’t anything to write home about at the moment, but I’m getting better…. * Last, how do I make a move to production without having any down time? I’m not talking about moving an entire site between servers; I’m talking about just moving incremental file and database changes. My development site and production site are on the same server, as I mentioned earlier, with the development site existing as a subdomain. I suppose I intend to use the development site somewhat like a dev/staging combo, and my local installation as a pure development environment. * All I ever heard from people before this project was how easy WordPress was to get up and working. While that might be true if you have no desire for any process or customization behind your work, I’m finding WordPress to be far from straightforward at the moment. * Any help, pointers, references, etc. would be much appreciated. I poured over anything I could get my hands on all yesterday afternoon and evening, and I still feel like I’m coming up short…. * Thanks in advance for your replies! As of right now, I feel like I’m just going to have to write down all my successful changes in my development environment and then re-do them all by hand in production at 3:00 AM or something…. * Mike Viewing 15 replies - 1 through 15 (of 18 total) 1 [2](https://wordpress.org/support/topic/migrating-changes-through-environments/page/2/?output_format=md) [→](https://wordpress.org/support/topic/migrating-changes-through-environments/page/2/?output_format=md) * [jon](https://wordpress.org/support/users/adiant/) * (@adiant) * [14 years, 9 months ago](https://wordpress.org/support/topic/migrating-changes-through-environments/#post-2255393) * I’m not going to answer all your questions in this one post. For one reason, I don’t know all the answers myself. But I do have a Corporate I.T. background that goes back to 1973, so I do know where you are coming from. * (1) No downtime changes to a new version of your web site design: I accomplish this by using the WordPress capability of running in a folder, but appearing to be in the root. Old version in one folder, and new version in another. To change versions, it is just a single edit of index.php in the root. Reference: [http://codex.wordpress.org/Giving_WordPress_Its_Own_Directory](http://codex.wordpress.org/Giving_WordPress_Its_Own_Directory) * (2) I am able to freeze changes (no new posts, pages, comments, etc.) during application changes, so I have never had to deal with my new version of my web site not having the most recent posts/pages/comments. But, if I did, I would be exploring Import and Export (Admin panel functionality in WordPress). Copying database tables from one WordPress to another (different one) is a recipe for disaster. * (3) Test environments are best made by cloning your Production WordPress. Always using $_SERVER[‘SERVER_NAME’] in wp-config.php as part of the definition of WordPress Address and Blog Address (rather than specifying them in the Admin panel, which stores them in the database), is one step to make cloning easier and less error- prone. Reference – [http://codex.wordpress.org/Editing_wp-config.php](http://codex.wordpress.org/Editing_wp-config.php) The second step is to Save Permalinks as part of the Clone process so that .htaccess is rewritten and many URLs used on the web site are corrected to the location of the Clone. And the third step is to use the Search and Replace or similar plugin to change any hardcoded URLs in the WordPress database. * (4) Another, to my mind much better, alternative to testing on your local computer is to use Reseller or VPS type accounts on a web host. They provide isolation between your WordPress installations (except the Pre-Production environment described in point (1)) by preventing your cloned test system from accidentally accessing your Production database, because each subaccount (Production and Test in different subaccounts) has a separate user ID that must precede the database name. And because each subaccount has a separate FileSpace, preventing writing over Production files from your Test environment. * [jon](https://wordpress.org/support/users/adiant/) * (@adiant) * [14 years, 9 months ago](https://wordpress.org/support/topic/migrating-changes-through-environments/#post-2255398) * One thing you didn’t mention is how to handle new versions of WordPress itself. It is extremely important to stay up to date. And I mean within 1-2 weeks of release. Truth be told, it is the most minor releases that are the most important. We are now at 3.2.1. If 3.2.2 comes out next, it will be a security fix and is very important. If Version 4 came out tomorrow, you could afford to wait a bit. But a better idea is to watch the Release Candidates and maybe even the Beta releases so you are ready to go Day 1 of a new release of WordPress. More important, RC and Beta releases give you a chance to get bugs fixed BEFORE formal release. * You need a migration plan for new versions of WordPress. As scary as it sounds, I do the upgrade live on the Production web site. But only after: 1. Testing it thoroughly on an exact clone of my Production web site; 2. Backing up both my entire Production web site’s files and the WordPress database( and any other databases that your WordPress web site might be accessing). 3. Have a detailed written plan of the upgrade process, including possible recovery from backup 4. Do the upgrade at 3 a.m., just in case I have to spend the time doing the recovery * Thread Starter [mpcee123](https://wordpress.org/support/users/michaelpcook/) * (@michaelpcook) * [14 years, 9 months ago](https://wordpress.org/support/topic/migrating-changes-through-environments/#post-2255402) * [@adiant](https://wordpress.org/support/users/adiant/), * Wow, you’re quick on the reply! Cheers! * My responses to your responses: * 1.) Excellent idea for no down-time. I will definitely be looking into this option. Love it. * 2.) The “freezing” of production idea is a good idea if it’s feasible. However, I still don’t think it answers everything. What if you download your production data a week ago to your development environment and you needed an entire week to make your changes, many of which impacted the database used in the development environment. You’re not going to “freeze” production for the entire week that you worked, are you? And after having made so many changes to the development environment, you can’t just download a copy of the production database again. You have to merge things somehow. Is that what the XML export feature is intended to accomplish? Situations like this? * 3.) I here ya on the wp-config.php and permalinks stuff. In creating my [http://dev.mysite.com](http://dev.mysite.com) test site yesterday, I got a crash course in all that stuff. AND I had a chance to experience the “Search and Replace” plugin. Although, I would say that the script listed here is more complete: [http://interconnectit.com/124/search-and-replace-for-wordpress-databases/](http://interconnectit.com/124/search-and-replace-for-wordpress-databases/). * 4.) I know, I know: I could be safer with the test environments. Right now, my focus is more on just understanding how to USE test environments effectively with WordPress. * 5. (second post) Cheers on the “updating WordPress” info. I’m aware of WordPress’s release naming structure and how the security updates come a bit later. Great points on upgrading though. * While I wouldn’t have understood much of anything early yesterday, things are making a lot more sense today. #2 is still our issue though, I believe. * Cheers again, adiant. Feel free to reply again! * Mike * P.S. I was reading this when your reply came through: [http://wordpress.stackexchange.com/questions/2100/database-synchronization-between-dev-staging-and-production](http://wordpress.stackexchange.com/questions/2100/database-synchronization-between-dev-staging-and-production) * I’m not the only one with these problems… (Comfort in numbers? Maybe…) * [jon](https://wordpress.org/support/users/adiant/) * (@adiant) * [14 years, 9 months ago](https://wordpress.org/support/topic/migrating-changes-through-environments/#post-2255403) * Three years ago, when I first met WordPress, doing a site move for someone, I actually installed a fresh WordPress many versions newer than the old site’s and simply exported and imported. * Even back then, Export did capture almost everything. There were a few minor changes to settings required after the Import, but it really was “good to go”. * As I say, I have no current experience to go by, but I still wouldn’t underrate the capabilities of Export/Import to address point (2). * Thread Starter [mpcee123](https://wordpress.org/support/users/michaelpcook/) * (@michaelpcook) * [14 years, 9 months ago](https://wordpress.org/support/topic/migrating-changes-through-environments/#post-2255409) * So then ideally, the process would go something like this: * 1.) Copy down all files (if not already present) and database contents to development environment from production, which is running in a subfolder of the root public directory. (All configuration changes, scripts, etc. necessary to make the production install work in the development environment will need to be run.) * 2.) Make all necessary changes in the development environment. * 3.) Freeze production. * 4.) Export “All Content” from production.* * 5.) Import “All Content” in development.* * 6.) Upload everything from development to a second folder under the root public directory on production, making sure to make all necessary URL changes and such( as always). * 7.) Change index.php in production to point to the newly uploaded content. * * My issue: Exporting “All Content” seems to be the only way to get everything all-at-once from production. However, if you changed the navigation, terms, etc. in the development environment, you would have a problem here. I think a mandatory manual edit of the XML file might have to be done. * I think we’re close here, but there has to be an “it” way to do this. WordPress has been around way too long to have the only solutions be custom scripts spread here-to-there around the world… * Mike * [jon](https://wordpress.org/support/users/adiant/) * (@adiant) * [14 years, 9 months ago](https://wordpress.org/support/topic/migrating-changes-through-environments/#post-2255415) * I’ve explained what I know and don’t know. But, given that background, those 7 steps make sense to me. * At the risk of stating the obvious (i.e. – I’m sure you’ve thought of this), but Steps 2.5, 6.5, and 7.5 really need to be added. They all say the same thing“ Test Like Crazy”. * Thread Starter [mpcee123](https://wordpress.org/support/users/michaelpcook/) * (@michaelpcook) * [14 years, 9 months ago](https://wordpress.org/support/topic/migrating-changes-through-environments/#post-2255418) * [@adiant](https://wordpress.org/support/users/adiant/), * Right on–“test like crazy” should be the air we all breathe. 🙂 * I appreciate all your insight–more than you know. It’s just nice to at least bank some ideas off of some other folks as I’m still new to the process. * I hope some others find this thread, as I know many have lingering questions on this issue that haven’t been resolved. Piecemealing together random, dated internet tutorials spanning the last 3 years can drive a man crazy after a while. * Cheers again for you help! * Mike * P.S. Anyone else with thoughts on all of this? PLEASE, don’t hesitate to jump in here! * [jon](https://wordpress.org/support/users/adiant/) * (@adiant) * [14 years, 9 months ago](https://wordpress.org/support/topic/migrating-changes-through-environments/#post-2255553) * Although I haven’t looked elsewhere on the subject, I did just realize a couple of ways to capture post/page/comment changes before “cloning time” and “production time”: 1. Export “all” at Clone time and again at Production time, and compare; 2. Backup the WordPress database at Clone time and again at Production time, and compare (after unzipping, if you use GZip format for the backup) * For a small number of changes, something as simple as NotePad++ and its Compare facility will do the trick. * Thread Starter [mpcee123](https://wordpress.org/support/users/michaelpcook/) * (@michaelpcook) * [14 years, 9 months ago](https://wordpress.org/support/topic/migrating-changes-through-environments/#post-2255581) * [@adiant](https://wordpress.org/support/users/adiant/), * Not a bad idea–and certainly a way to spot changes. But visually comparing changes in text files is a bit tedious, no? Not to mention dangerous if I start doing“ cut and pastes” by hand? * Mike * [jon](https://wordpress.org/support/users/adiant/) * (@adiant) * [14 years, 9 months ago](https://wordpress.org/support/topic/migrating-changes-through-environments/#post-2255583) * In my similar experience (phpBB), I found that it was always “new” not “updated” posts that I was finding. Using WordPress Export/Import, it should really just get down to isolating a few lines, each representing a new post/post/comment, and importing just those few lines of XML. * The Change facility in NotePad++ makes it pretty straight forward to identify and copy/paste those “new” XML lines. I have not used other Compare tools in recent years. * Thread Starter [mpcee123](https://wordpress.org/support/users/michaelpcook/) * (@michaelpcook) * [14 years, 9 months ago](https://wordpress.org/support/topic/migrating-changes-through-environments/#post-2255585) * [@adiant](https://wordpress.org/support/users/adiant/), * So then create a third XML file containing only the identified changes, and import only those changes back into Development. Then, perform the full database and file deploy to Production. Yes? * Mike * [jon](https://wordpress.org/support/users/adiant/) * (@adiant) * [14 years, 9 months ago](https://wordpress.org/support/topic/migrating-changes-through-environments/#post-2255586) * Precisely. Because, unlike the database compare approach, WordPress takes care of pointers or counters or last post time stamp or any of that other stuff when you do an Import. * Thread Starter [mpcee123](https://wordpress.org/support/users/michaelpcook/) * (@michaelpcook) * [14 years, 9 months ago](https://wordpress.org/support/topic/migrating-changes-through-environments/#post-2255587) * [@adiant](https://wordpress.org/support/users/adiant/), * Alright, perhaps this will be my process … for now. (Things always change!) * FYI: An interesting new development … IF I was planning on running a WordPress MU setup. [http://markmaunder.com/2011/08/19/deploymint-a-staging-and-deployment-system-for-wordpress/](http://markmaunder.com/2011/08/19/deploymint-a-staging-and-deployment-system-for-wordpress/) * Thanks again for the help! * Mike * [jon](https://wordpress.org/support/users/adiant/) * (@adiant) * [14 years, 9 months ago](https://wordpress.org/support/topic/migrating-changes-through-environments/#post-2255593) * A quick look at that project you linked to leaves me confused. WordPress MU is dead and buried. Because you can do the same thing with the multisite option built into WordPress itself. See here for details: [http://codex.wordpress.org/Create_A_Network](http://codex.wordpress.org/Create_A_Network) * Unfortunately, you can’t use multisite and my Point (1) no down time approach in my first post. * All that said, assuming the developer meant Multisite and said MU by a mistake, you may want to investigate multisite now, and see if you can figure out an alternative to Point (1) of mine. * Also, be aware that some web hosts appear to have a delay built into the definition of a subdomain and its ability to be used. cPanel will show it as there and working, but your web browser will tell you differently. Oddly enough, on my web hosting account, there was only a delay in the ability to use a subdomain defined for the master domain name. Subdomain definitions for Add-on Domains were instant. * P.S. – I just posted a question on the project’s page about MU v.s. multisite. * [jon](https://wordpress.org/support/users/adiant/) * (@adiant) * [14 years, 9 months ago](https://wordpress.org/support/topic/migrating-changes-through-environments/#post-2255602) * Just got a response: by MU, the author means multisite. Viewing 15 replies - 1 through 15 (of 18 total) 1 [2](https://wordpress.org/support/topic/migrating-changes-through-environments/page/2/?output_format=md) [→](https://wordpress.org/support/topic/migrating-changes-through-environments/page/2/?output_format=md) The topic ‘Migrating changes through environments’ is closed to new replies. ## Tags * [database](https://wordpress.org/support/topic-tag/database/) * [environments](https://wordpress.org/support/topic-tag/environments/) * [staging](https://wordpress.org/support/topic-tag/staging/) * [testing](https://wordpress.org/support/topic-tag/testing/) * In: [Fixing WordPress](https://wordpress.org/support/forum/how-to-and-troubleshooting/) * 18 replies * 3 participants * Last reply from: [fishnyc22](https://wordpress.org/support/users/fishnyc22/) * Last activity: [14 years, 1 month ago](https://wordpress.org/support/topic/migrating-changes-through-environments/page/2/#post-2255788) * Status: not resolved ## Topics ### Topics with no replies ### Non-support topics ### Resolved topics ### Unresolved topics ### All topics