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