Here is one way you can set up and run a development (dev) WordPress site, then move the database to production (prod) without manipulating data. Here’s how the “mirrors” were created.
Considerations in Brief
We developed on separate hardware for dev and prod, but this method may work just as well on the same machine, with at least one virtual machine (VM). The requirement is that the “two” have access to distinct DNS services.
Database
It is probably best to create the production database (db) first. Dev will probably be more flexible, and prod more restrictive, especially if shared hosting is involved. Nice to have will be the same table types, as in Isam and InnoDb if using mySql. Because moving data will be via export/import it may not be critical. The two systems described here, both had InnoDb tables. The dev database was created using the same db name, db user, db password,
Web Servers
Not being a good consumer, a four year old laptop stood in as the dev server and client. It ran Win 7, PHP 5.2, mySql 5, IIS7.5, and WordPress 3.5.1. The prod site was on a shared host server running Linux, PHP 5.3, mySql 5, and apache
DNS
DNS was the “magic” that allowed using the “same” domains and database hosts. The prod database and web servers were separate machines with distinct host names and IP addresses. The dev “server” running windows simply used the drivers\etc\hosts file and pointed the site domain name and database host name at the localhost thusly:
127.0.0.1 domain.tld
127.0.0.1 database.mywebhost.domain.tld
- tld means top level domain, as in .com, .net. org, …
- switching the client between working on dev or prod server, simply involved renaming the hosts file.
Moving WordPress site from Development to Production
WordPress database was exported by the WordPress plugin wp-db-backup. On the windows dev box, mySql client performed export duties, while on the prod Linux server phpMyAdmin did the importing.
Read more WordPress Core
Happy development