4

I've been working away at a medium-size WordPress site. So far I've just been hosting the site on my local machine and showing it to internal consultants over our local network. Things are working well, and now it's time to show it off to the client. I've been using git all along, so pushing it to the dev server was a breeze. I duplicated the local DB and pushed it to the dev server manually, which was fairly easy except that I had to manually change a few URL entries.

Now my question is: what's the best way to keep two instances of WordPress synced? I still have more work to do locally and the DB is going to need to get pushed up again. How do other people manage this in an automated way?

One thought I had was to write a git hook to pull the MySQL data down when I push from my local machine and have a hook on the other end to import the data when the dev server pulls. However, if I do this I'll have to worry about changes to the wp_options table.

Does anyone have any strategies for making this sort of thing easy?

Thanks!

3 Answers 3

3

Assuming your wp-config.php is already in place and in order:

  • Step 1. Mysqldump your development database
  • Step 2. Replace all instances of development.domain.com to production.domain.com^^
  • Step 3. Login to MySQL, run a SOURCE command to import data e.g. source /path/to/file

^^ How to replace all instances of old domain with new: (1) Copy the script below. (2) chmod +x it. (3) Run it.

Usage: ./script.sh development-dump.sql > production-dump.sql

#!/bin/sed -f
s/'\([^\\']*\)development.domain.com\([^\\']*\)'/'\1production.domain.com\2'/g
2
  • 2
    I guess this is probably my best option, then. I was hoping to avoid doing something like this, but it's what I'm reading everywhere else as well. The only thing I would change about this is step 3, where I would use mysqlimport so that I could tie all the steps into git hook and have it happen automatically on a pull. Thank you for your help! Commented Mar 16, 2011 at 23:49
  • As mentioned in the Codex, simply performing a search-and-replace on the database dump can lead to problems with serialized data. Much better to use a script, such as the one by interconnect/it, or a plugin based on it such as "Better Search Replace".
    – Yosi Mor
    Commented Jan 15, 2015 at 19:50
4

This has been discussed a few times so I'd suggest going over these threads then asking about any gaps you still see.

What process do you use for WordPress development?

How to: Easily Move a WordPress Install from Development to Production?

Ultimately keeping the database in sync is the issue most struggle with. I simply don't really worry about it. I'll import some posts/CPT's if we have a new content type but that's about it the rest I do manually.

0

Migration between local development server and production server is an essential task in web development and database administration, usually requiring exporting data from one environment and importing it into the other while maintaining data consistency and integrity. Here is a general guide on how to migrate between these environments:

1. Plan Your Migration: Before initiating any migration project, create a detailed migration plan outlining which data needs to be transferred, the method (manual or automated), any risks or issues associated with migration as well as potential solutions.

2. Back Up Your Data: Prior to making any modifications, always back up both source and destination environments to protect against potential disaster. In case something does go awry, this step will enable you to quickly restore what may have gone astray in case something goes amiss.

3. Determine Your Migration Methods: Based on your data type and volume, choose suitable migration methods: for small datasets manually recreating records in their target environment is best. Export/Import: For simple migrations, data export tools (e.g. CSV, SQL dumps and JSON files) should be sufficient. For larger or complex migrations, scripting or migration tools may be used to automate this process.

4. Export Data From Source: If using export/import methods, the data must first be exported from its source environment - this could involve database tables, files or configuration settings being exported from one system into another.

5. Prep Data (and Perform Transform, as Necessary): If the data structure or format differs between environments, you may need to transform it in order to meet those requirements of the target environment. This process may include data cleansing, mapping and formatting activities.

6. Import Data (To Destination): Import the exported data into its destination environment. For databases, this may involve running SQL scripts or using database management tools.

7. Test Data in Development: Once your data has been imported into a development environment, ensure it works as intended by conducting rigorous tests of its consistency, relationships and functionality.

8. Modify Configuration as Needed: Adjust any configuration settings in the destination environment that differ from those in the source environment, such as file paths, database connection strings or environment-specific variables.

9. Deploy to Production (if applicable): If you are migrating data into a production environment, adhere to your deployment procedures so as to minimize downtime while testing data functionality in its new home.

10. Monitor and Validate: To ensure everything runs as intended in your target environment, consistently monitor and validate migrated data before moving it onto its new home. Address any potential issues promptly.

11. Clean Up: Once your migration was successful, once confident of its success it is time to remove any temporary files, backups, or scripts created during its completion.

12. Document: For future reference, it is wise to document any modifications made during migration process, as well as document any other necessary actions taken by administrators.

Data migration can be complex, and requires careful planning and testing in order to ensure a seamless transition from one environment to the next. Always consider your unique project requirements when choosing an approach for migration.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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