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?
views:
327answers:
4
+3
A:
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.
TheDeadMedic
2010-06-04 10:38:42
how do you deal with creating new pages and configuration settings stored in the db?
blockhead
2010-06-04 17:13:57
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.
TheDeadMedic
2010-06-05 13:34:40
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.
blockhead
2010-06-06 02:07:38
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.
TheDeadMedic
2010-06-06 10:28:42
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.
blockhead
2010-06-06 13:33:22
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!?
TheDeadMedic
2010-06-06 13:44:06
If you copy your database from dev to production, don't you lose all your content, like your posts?
blockhead
2010-06-06 17:03:22
No! That's the point - all your content is stored in the database!
TheDeadMedic
2010-06-06 18:33:56
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?
blockhead
2010-06-06 19:21:27
Check my updated answer.
TheDeadMedic
2010-06-06 19:33:43
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.
blockhead
2010-06-06 23:32:41
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.
TheDeadMedic
2010-06-07 00:06:17
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.
blockhead
2010-06-07 01:41:04
@blockhead 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.
Chris_O
2010-09-22 21:29:23
A:
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.
Greg Guida
2010-06-08 04:20:42
This doesn't really cover the case when content on production has changed while you were developing.
Alex N.
2010-09-22 14:40:06
A:
I have Development Site on my Local machine and change hosts file to point calls to live server to 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.
JD
John Doeherty
2010-09-28 10:50:19