Do I Want a CMS? Arguments Pro and Con

[ergophobe]

Here's a 30-second brain dump. Please add some more reasons pro and con. Please criticize and contest the reasons given.

Some reasons for using a CMS
- multiple authors making concurrent updates
- managed workflow
- ability to work from any machine with net access
- want dynamic content on many pages
- want navigation changes to reflect content additions (such as new categories are reflected automatically in nav or "recent articles" and so forth).

Reasons not to use a CMS
- hassle: you can end up spending a lot more time on administrative tasks
- security: anything that can be updated via an HTTP connection can probably be hacked via an HTTP connection

Inadequate reasons for using a CMS
- Everyone seems to be using them these days.

[bill]

Some reasons for using a CMS
- recycle similar design elements across a family of sites
- recycle content across a family of sites (contact info, etc.)
- allow users with little or no HTML knowledge update content

[ergophobe]

More reasons in favor
- Picking up on Bill's first point: one code base running many sites. Sure, a static site has no code base at all to run, but a custom site that does use some scripting allows reuse of some classes or function libraries (I always try to generalize my classes and function libraries for reuse), but usually I end up reusing the code, not just having one single copy for all sites on a given server as I would with a true multi-site CMS.
- ideally, separation of content, logic and presentation. This is far from complete with any CMS I've used - there's always some HTML in the database and some HTML being generated by modules and such, but in general the theming system handles presentation, the core of the CMS handles the logic, and the database holds the content.

More reasons against
- greater bandwidth and CPU cycles typically required to get a page to a user
- feature creep that can bog the CMS down over time, but in order to get the security fixes, you're locked into "upgrading".

[aspdaddy]

You probably do if your requirements are simple and easily catered for, but if not the bespoke route may be cheaper and faster.

Pros:
-Quick Lowcost deployment of core CMS features without extensive testing and fixing of code.

-Simpler backup, but there is a security trade-off with DR below.

Cons:
-Less portability. You have to install and configure the system and then the content.

-DR Issues. If all your content, style, templates are in 1 mySQl and it gets corrupted.

-Learning Curve. For advanced features, the skills are not as widely available as normal php/mySQL

-Integration. May be difficult to understand the users and content schemas to integrate from other sites etc.

[ergophobe]

Sorry, don't know the term. What are "DR Issues"? Database Replication?

In any case, you remind me of another. I definitely agree on the learning curve for a developer. Oh yes, much suffering has taught me that. On the other hand

Pros
- Rapid Development of complex features with competent developer. You're definitely right that finding someone who is a whizz at your particular CMS can be a challenge, but if you find someone who really knows all the APIs, they can turn stuff out in hours that would take someone days to build from scratch.

Cons
- HTML code bloat.

Unless you have a custom CMS, it's almost guaranteed that there will be code bloat at all levels, from the PHP to the HTML to the CSS that will slow down page loads.

[aspdaddy]

Sorry, disaster recovery, or proabably business continuity is more accurate.

If your mySQL gets corrupted you accept to lose all *content* and have to recover *content* from the last mySQL backup, while you have a basic site up in the interim.

With a CMS you may also lose code, style and config settings since the last mySQL backup and may not have any working site at all until you complete full mySQL recovery and/or re-installation of the CMS

[ergophobe]

I have to say that I like the separation of logic, content and presentation as I mentioned earlier, so that your data backup is a fraction the size it would be with a static page.

For one site on a university supercomputer (and a primitive, custom CMS I built myself), some sysadmin archives the backups. You can grab the dump file and do a diff and quickly see what changes there are between the two files.

For cheap sites on a shared server, I write a simple shell script that runs as a cron job that creates a mysql DB dump, gzips it, emails it to a gmail account. For a site with 1500 pages, some long and some short, this is still pretty small (under 10MB I think, but I should check). Obviously, that doesn't back up images and such, but that's sort of the point - the parts in the DB are easier, in my opinion, to back up and restore than files on the filesystem in this case. Since it's not much space, I could actually set this up to save a backup every hour for a week on a rotating basis or something if the site was busy and I wanted to lose a minimum.