On 15 Feb 2011, at 22:10, Wade Preston Shearer wrote: > On 15 Feb 2011, at 21:13, Chad Sollis wrote: > >> I've seen a lot of CMS and seen roll outs of all kinds. I think a live site, >> with varying status, and a launch tool to trigger status across the >> mechanisms would be the best and least pron to error. > > How would you test the changes before you roll them out? How would you handle > things like navigation without having to duplicate the entire tree?
I think that you're recommendation is the right approach, Chad, and I think I have the answer to my questions about testing. The system could have a revision history for all content. When editing, you could save a draft or publish—both would simply save out a new version. Publishing simply marks a particular version as the one that is to be used for production. The published version may not be the latest version of the content. The staging and production servers read from the same database, but the staging server pulls the latest version while the production server pulls the version that is marked as published. This provides the ability to browse an entire copy of the site in staging, provides a revision history, drafts, and publishing. And, with a launch tool (where you could create a queue of items to be published together at a certain time), you also would have the ability to publish any revision—meaning, that after you have tested and scheduled some content, you could start making further changes because the system would publish the version you schedule, not the latest. _______________________________________________ UPHPU mailing list [email protected] http://uphpu.org/mailman/listinfo/uphpu IRC: #uphpu on irc.freenode.net
