For a long time at my day job, one of our big web site issues has been the staging of database-driven content. Particularly if you’re editing Drupal pages that have a lot of markup in them, publishing a node can be sort of scary, as it goes live instantly with any bugs you’ve introduced. In theory, Drupal’s preview feature can be used to view your changes before you commit to them, but this too is scary, as the content isn’t rendered exactly as it will be once published. Further, using vanilla Drupal with its preview function to stage content requires that you roll out changes one by one. If you want to group changes for a mass rollout, the best you can do is wrap your changes in html comments and uncomment them one by one during deployment, hoping you don’t fat-finger anything in the process. I’ve always thought this would be a pretty difficult problem to solve, but yesterday, I came up with what feels like a satisfactory method for staging content.
The new stage module addresses both safety-netted staging of individual content and management of change sets.
It works by tapping into Drupal’s revision system, which already allows you to track changes to content over time and to revert to older content. For specified types of content, any additions or edits are published using the normal Drupal workflow, but on publish, the revision number is pinned at its last blessed point. You can edit or add any number of documents, and they all remain pinned at their pre-edit revision until you roll the whole batch of changes forward. When you roll a batch forward, all the revision numbers are brought to their most recent and pinned there until the next deployment. In the administration section, you identify staging and production servers. If you view an affected node from one of the specified staging hosts, you see the latest copy; if you view it from a production host, you see the pinned version.
This workflow is ideal for environments in which fairly frequent milestones are deployed. Because of Drupal’s handy dandy revision system, you can compare versions of the content across pushes to see what’s changed.
The module is hot off the presses this morning and so is probably still buggy and feature-poor, but it’s a start.
Two Ells 
was wondering if there is any documentation on how to use this?
I know you just hacked it together and i was wondering how it works.
Do you need separate servers to stage content on?
Is this module some kind of bridge between them?
how do production hosts and development hosts connect with each other?
is this non functional for now?
I am looking for some kind of staging system, I am also looking at the revision moderation module, but I would rather be able to push a wide array of edits at the same time.
thanks!
As yet, the only documentation is in the module itself. You don’t have to have separate servers to stage on, but if you’re staging site assets (templates, etc.), you probably already have a separate hostname and virtual host, at least. In testing, I used the same virtual host with a serveralias for my staged name, so it can be done without even using a separate virtual host. All this module does is to tap into drupal’s existing revision system and let you deploy change sets (or batches) of revisions. The dev vs. production dichotomy is for now purely a naming convention, so that the site knows whether to display staged content or production content (and so that you can be redirected to the production hostname for edits). The module is very solidly ready for testing but has not been deployed in production yet and may not be ready for such a deployment yet. I hope you’ll set it up on a test site and let me know of any issues you run into, though, as I’m trying to make this production ready.
I’m also working on a module that’ll let you stage non-node content (panels, blocks, etc.), incidentally, but it’s even less ready for prime time than this one.