Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Monday June 09, 2008
01:35 AM

Content Management Systems

[ #36628 ]

With content management systems (CMSs), there are basically two paradigms that I call "client-side" and "server-side" (not entirely accurate, but bear with me). The vast majority are server-side. The code constantly runs, keeping everything going where it should be. This is great because it's conceptually simple and easy to integrate with existing code/databases.

The downsides are legion.

Another dependency
If your Web server goes down, your hosed either way. If your CMS goes down, the client-side CMS doesn't break your Web site (though there are server-side CMS systems which can build static pages).
What? Your ISP doesn't support the language your CMS uses? Too bad. Or maybe they quite reasonably don't trust that dodgy PHP thingy you found on Joe Hacker's Web site.
Security holes
Speaking of PHP, if you have a security hole on your server-side CMS (I'm sure you can name a few), you probably need to take down your site while you patch it -- and I'm sure that plenty of us have worked for businesses which will neither let you take down the site nor patch the CMS.
Anyone here ever run into scability issues with their server-side CMS because it has to constantly serve the pages? Yeah, I thought so.
URL Control
Many server-side CMS systems give you no control over your URLs. Why on earth would a professional organization tolerate that? URLs are important.

For client-side CMS systems like Bricolage and Krang[1], you have a server -- could be running on your laptop if you want -- which runs your CMS app. When you're done editing your pages, you publish them to your site. They are sent via sftp, ftp, or whatever other transport mechanism is set up. In other words, you work locally, publish remotely. The downside is that it can be tricky to integrate with existing sites or databases, but once that's done, you generally don't have the disadvantages above. In fact, you could make your entire site static and have virtually no performance overhead aside from what your Web server can handle.

Now that you've read this far, what client-side CMS systems would you recommend for individuals? The easier to use, the better. Bricolage and Krang are great, but they're designed for people with serious needs.

1. Krang borrowed so much from Bricolage that many would be hard-pressed to see the difference between a Krang screenshot and a Bricolage screenshot. I never did understand why they wrote their own rather than work with Bricolage, but they did put together a great product.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • for individuals, definitely movable type.

    * it runs on a different server and publishes static content (it's trivial to embed, say, mason on your pages if you want something dynamic in user time).
    * everything is broken down nicely into templates.
    * extremely flexible
    * it's written in perl and the code is easy to work with (seriously, i know this is like beating a dead horse, but have you looked at the innards of wordpress?)
    bgp is for those who can't keep it static long enough
  • Don't people use the term "Staging/publishing" CMS anymore?
  • If you find a CMS you like that doesn't support publishing to static pages, it's not hard to do that bit independently. A simple wget will get you most of the way then run each page through a Perl script to apply whatever customisations or rewrites you require (wget will fix the links) and rsync to push it up to your server.

    As to which one I'd recommend, as I said in a recent journal entry, I have yet to find a CMS I like but so far Drupal is the one I dislike the least. Before working with it I knew al

  • I think the main disadvantage of a static publishing CMS is adding comments, forums, etc. Sure, you can have a mixed static/dynamic setup (MT for example) but then you invalidate most of the advantage of using a static system in the first place.
  • Latemp [] is an offline content-management system I created based Website Meta Language [], GNU make and a lot of custom Perl code. It was originally intended to extract the various common copy-and-pasted functionality from my WML sites.

    Latemp requires a bit of learning before one can start, and has quite a few dependencies. However, one can simply enter HTML markup into the template files and it will work.

    Also look at ttree [] which is based on Template Toolkit.