On Sun, Mar 23, 2014 at 08:57:30AM -0500, Ted Lemon wrote: > The desire for a clean backend is a valid one, but in fact most of the > time CMSs store this stuff in tables in a database, which are easily > extracted if you want to migrate later. There isn't a way to store web > pages that doesn't require a bit of data analysis and transmogrification > when you are upgrading?even a directory tree will have a layout that's > specific to the particular deployment you have chosen. As I mentioned in my earlier comments, it's possible that a CMS is too heavyweight for this application and quite possibly not compatible with the need to have (a) sane, meaningful URLs and (b) the ability to migrate at some future date. The "software tools" approach suggests using simple tools in combination rather than monolithic ones, and I strongly recommend investigating that approach here. As I also mentioned, it's really not difficult to build a very simple, very scalable, very future-proof "CMS" out of basic Unix/Linux tools, used in combination with a little bit of shell or Perl glue to hold them together. This approach facilitates testing, incremental updates, global updates, revision control, timestamping, and backout quite readily. It also allows for easy upgrades/changes because the storage formats are simple and easily migrated to other ones. It's not fancy, it's not trendy, it's not buzzword-compliant. But it's simple and robust. So I think that an important part of this revamp process is ascertaining exactly what the content management requirements are and figuring out what the simplest possible toolset that meets them looks like, i.e., I think it's important not to commit to the idea that a full-blown CMS is required before an actual need to do so is demonstrated. ---rsk