What is a good way to set up a dev, staging and production workflow with wordpress

Question

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?

Auschwitz

Shouldn't you ask this at wordpress.stackexchange.com ? – Nathalia

didn't know it's exists :) thanks. – Nicks

Answer 1

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.

Julejulee

how do you deal with creating new pages and configuration settings stored in the db? – Auschwitz

At the moment, every site I create is just a fresh database install. I guess I could write a plugin to batch process some common settings, but each site is usually very different from any other - page structure, for instance, is never the same, and I just add and edit pages and posts as you do normally in WP. – Julejulee

I mean if you create a page on your dev server, and then you resync the dev database with the live database, you lose those pages. – Auschwitz

If you resync, why would you lose the pages? Re-syncing is merely copying over your dev install to production, using the method in my answer. – Julejulee

Because the pages are stored in the database. So if you just move the code over, the pages don't go. If you move the database over, you lose your content. Also, if you go the other way around, you'll wipe out the pages in your dev database. – Auschwitz

When I say 'copy over', I mean database, theme files and uploads - basically mirroring my dev install on the production server. The only step in-between is the search and replace of the dev URL with the production URL in the DB. You shouldn't lose anything this way!? – Julejulee

If you copy your database from dev to production, don't you lose all your content, like your posts? – Auschwitz

No! That's the point - all your content is stored in the database! – Julejulee

I'm not following you. If you have a production database, which has all your content, and a dev database which is synced to the production database every once in a while, and you then sync the other way--from dev to production, thus wiping out out your production database. Don't you lose your content? – Auschwitz

I still don't see how you solve the syncing issues. Here is a real life example. Site it up. Adding in a new page with its own theme. If I move production db to dev, make changes, and then push back, I could potentially lose data that was updated in prod in the meantime. If at any point I sync to during the development process, that will wipe out my newly created page. – Auschwitz

I think you're straying too much from your original question now - what you're really looking for is an advanced syncing script between two databases, accounting for data changes between the two. – Julejulee

This is what my original question is about. Wordpress does not separate data from code very well, and stores too much in the database. So I was asking how people get around this. – Auschwitz

@Auschwitz All content is stored in the WordPress database. The files are the templates and php. The files stay static and the database is the only thing that changes after production. – Alar

Exactly, and if you make new pages on your dev server, those are not in code anymore. How do you move them over. How do you move over plugin configurations, and menus as well? – Auschwitz

Answer 2

This Same Question was asked and answered on WordPress.stackexchange. It contains detailed information and best practices for rapid deployment from dev to production.

Edit

This is the same answer I added at WordPress Answers.

There may be a better ways that I am missing but I am going to give you 2 options:

1.Use XML Export to export your new posts and comments. Then use the WordPress Importer to import the new posts and comments back into the dev database

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.

2. Use the INSERT IGNORE INTO MySql command to add the new tables from dev. or the REPLACE command to overwrite duplicate rows in the same table.

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.

Alar

geez, I didn't even it exists(wordpress.stackexchange)... thanks! – Nicks

however that answer doesn't really cover the actual 2 way synchronization that Mr.blockhead had mentioned above. That is what I am most interested in as well. – Nicks

Answer 3

I have Development Site on my Local machine and change the local hosts file so, that calls to the live server (www.example.com) point to the localhost. That way all calls to external files (jquery, etc.) still work and I don't have to bother going through the db to change anything. Ex- and importing the content via the wordpress XML has given me the best results.

UPDATE: I have used http://www.mertyazicioglu.com/projects/wordpress-move/ and gotten good results.

JD

Hah

Answer 4

If you have phpMyAdmin installed moving wordpress sites from server to server should not be a problem at all. Simply export the database to a tar.gz and copy your custom theme (if your using one) via FTP and then, after creating a new DB and fresh wordpress dump, re upload both of them to the new server. 2 changes in the home and blog url in the database and 2 changes to the wp-config file and your done.

One thing I have had struggles with is 3rd party plugins. I end up coding a lot of galleries and javascript widgets myself because the 3rd party plugins either look like crap, are slow or dont work the way I want. Thank god for JQuery.

Unrobe

This doesn't really cover the case when content on production has changed while you were developing. – Nicks