One of the challenges I’m facing in working on v2 of the alexking.org site is the best way to “stage” the new site. Normally it’s pretty easy. Just build the new site locally and export the database when it’s time to launch the new site. However, since the live site is getting new posts, comments, etc. it isn’t as simple.
Since I’m converting content in static pages to the database, there is a fair amount of simple data entry to do. I need this data to be in my main database so that I don’t have to migrate it later1. However, I also need to see this new data in context of the new site design and functionality.
Making things more complicated is my choice to go with WordPress 2.1 for the new site while I’m running the latest 2.0.x here. In other words, I can’t just have both front-ends hit the same database.
What I’m doing at the moment:
- Create pages (content) in the current production database.
- When I need to review how the resulting pages looks in the new design, I create a version of it in the local testing database as well using an advanced development technique I call “copy paste”.
I’m sure some of you have worked around this issue before – let’s hear your tips.
- In addition, when I make the cut-over to the new site I want it to be fast – no more than 5 or so minutes of downtime. That means I need to get the data into the live database before the cut. [back]
I’ve moved two wordpress blogs and each was different. What I did when I moved one blog a while back was copy everything over to sub directories… had the new site running on a different database then the original. Then I just mv’d the contents back and forth and was up in minutes on new site, new database. A simple shell script renaming a BRB index.html file and then moving everything else into a ARCHIVE folder and then moving the new files into the root, followed by renaming index.html to index.bak took only a couple minutes.
The harder one, when changing hosts, I rsync’d them and then on change time exported database, transfered file from hosts to host, and then imported it back in. Going directly from server to server was pretty fast… the DNS change took the longest to completely finish. At work and at home it was about 10 minutes… but elsewhere… as long as 2 days.
I’ve been struggling with this myself. I wish there was some type of build in functionality (or maybe a plugin) to manage staging.
What about it there was another set of tables for staging. You would not duplicate the comments table. Appending ‘staging’ to the domain would pull data from the staging tables. When everything looks good, the click of a button would merge the data in the staging table over to the production tables.
You would probably also have to create a directory for staging the php files.
Make sense?
Patrick– It’s not a data migration issue, it’s a data merge issue.
jpepp– I’ve considered doing something like this by simply changing the table prefix for the staging site. Using different versions for staging and live make it hard though.
Got it… I’d say different table would be best… and a cron job to copy the “new entries” onto the test table. grep and pipe is your friend. Don’t forget mysql does have a command line that can be called.
What if you ran the two sites out of the same database, but with different prefixes. Then write a plugin for WP2.0 so that whenever a post or comment is added, modified, or deleted, it replicates the change in the WP2.1 tables?
Changes to the db schema will probably complicate some things, but it should be mostly doable? Don’t know if it’s the easiest way to handle it, though. But at least it would be semi-automated.
Patrick– I don’t think your suggestion takes into account the differences between the database schemas being used by the staging and production sites.
Dougal– I guess I’m not convinced that the trouble is worth it – copy-paste is only a few seconds here and there as needed.
Will WP 2.1 or future version allow to customize the template layout on each category or page like professional CMS do. It ll bring make WP much more popular than one same template for whole site!
You can do this since v. 1.5, you just have to put the logic in the templates. It’s easy enough to use the category slug as the key to dynamically choose a category template if it exists as well.
You’re right about that Alex, and that’s why I think WordPress’ logic structure allows it to be a powerful CMS system. My friend recently created a portal by interpreting categories. Perhaps you don’t have to upgrade to WordPress 2.1 after all, and just work with your existing system?
On an unrelated note, how were you able to integrate the “Type notspam” field into your comment form?
WP 2.1 has some new hooks in the internal router that I need.
When will v2.1 come out and your updates with plug-ins?
WordPress 2.1? No idea. My plugins will be released some time after I get v2 of my site done.