Wordpress presents some challenges since it tends to keep too much in the database, making it hard to move from server to server.
What are some other issues to look out for?
What was your workflow like?
A WordPress staging site is a clone/replica of the live WordPress site with restricted access. You can test themes/plugins and any other code-level changes on the staging site. Once you are done, you can then push/pull changes to your live WordPress site.
WordPress staging allows you to test changes made without affecting the live website. For instance, you can safely modify themes and test plugins on the staging environment. If something goes wrong, your website will not be affected.
I have a single WordPress install set up to power multiple domains on my development server. Plugin and theme files are also shared, so upgrading is a one-click process for all blogs.
I use Apache VirtualHosts to map multiple domains to the same document root, and sprinkle a little magic in the main wp-config.php
to dynamically set DB_NAME
, based on the current host (I can post code if you like).
For working locally, I just have a MySQL user with root privileges, and use it for all my databases (not recommended on a production server!).
My local domains are named appropriate to the real domains, but with a fake TLD. So working with example.com
, I set up a VirtualHost example.dev
.
When I'm ready to go live, I use HeidiSQL to make a copy of the development database, then replace all occurrences of example.dev
with example.com
.
The copied database is now ready for the production install. Mirror your local WordPress install on the production server (copying over plugins, uploads and themes), and use either HeidiSQL (recommended) or phpMyAdmin to import the prepared database.
UPDATE
Naturally, if you make changes to one, and then copy everything to the other, then you will lose any changes you had made on the other. This goes not just for WordPress, but for almost anything else in life itself!
If I ever need to make major changes once the site is live (and by major, I mean changes that should not be carried out on a production server), I do the reverse process of the above (copy everything from production to dev), make the changes, then do the reverse again.
This is the same answer I added at WordPress Answers.
It's best to import into dev then move the database over to production because when you import it will download all the new media files from production.
In the meantime production has changed(new posts, new comments, etc.)
This would solve your problem of bringing in any changed content.
Before using MySql make a backup of both databases and move the gz database to the production server and upload the dump (change the name of dev if it's the same as production.
INSERT IGNORE INTO `_wp_production_db`.`wp_cool_plugin_options`
SELECT *
FROM `_wp_dev_db`.`wp_cool_plugin_options`
I'm not comfortable with MySql commands so I would go with option 1.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With