[Smaug] CMS strengths/weaknesses

Thomas Leavitt thomas at thomasleavitt.org
Wed Nov 9 18:08:05 PST 2005

On Wed, 2005-11-09 at 14:59 -0800, smaug-request at lists.svlug.org wrote:
> Message: 3
> Date: Wed, 9 Nov 2005 14:09:11 -0800
> From: Rick Moen <rick at linuxmafia.com>
> Subject: Re: [Smaug] Web site maintenance (was: scruz.org re-design)
> To: smaug at lists.svlug.org
> Message-ID: <20051109220911.GU21839 at linuxmafia.com>
> Content-Type: text/plain; charset=us-ascii
> Quoting cerise at armory.com (cerise at armory.com):
> > Yeah, I don't think anyone is in disagreement on Jay's offer being
> > the best.  I started to balk at the idea of a CMS or the previously
> mentioned
> > use of mediawiki, but then I started thinking larger.  One project
> I've
> > always figured I'd get around to was putting up a list of problems
> I've
> > run across and my solutions to them.
> CMSes (aside from their document-process-management features, not
> discussed here) are a decent attempt to solve two nagging problems:
> 1. "Unfriendly" Unixey tools.  (Conversely put, aiming at wider
> participation.)
> 2. How to give people sufficient access to participate in a Web site
> without
>    host security problems.
> Standard Unixey solutions involve participants using shell access,
> ssh/scp, etc.  But managing the security and other system risks from
> giving lots of Joe/Jane LUGger shell on your server is difficult.
> So, you have them authenticate solely within a CMS Web context, and
> make
> sure that all hosted content is versioned and thus revertable, if need
> be.  Depending on the site's user policy (passwords, Captcha, etc.),
> you
> then have either a greater or lesser problem with comment spam, as Jay
> found out on from spammers' clobbering of the SCLUG wiki.
> Problems of CMSes include:
> 1.  People who _like_ traditional Unixey tools get screwed.  E.g., if,
> like me, you prefer to edit everything in $EDITOR_OF_CHOICE, you get
> your pick of several unsatisfactory accomodations of the brick-wall
> framework that's always in your way.
> 2.  They passively but massively resist customisation.  Drupal in 
> particular is infamous for this.  What I mean is:  Everyone starts out
> with:  "Oh, but our Drupal site _won't_ look like a funny looking
> Slashdot, unlike every other one out there."  And yet, they always do
> --
> because although in _theory_ you can customise and theme your way out
> of
> that trap, in practice nobody ever does. 
> E.g., after years of unfulfilled promises, SSC, Inc.'s rump version
> of 
> Linux Gazette at http://www.linuxgazette.com/ _still_ looks like a
> funny-looking Slashdot (after 100% of the magazine staff decided to
> pull
> up stakes and move the magazine to http://linuxgazette.net/).
> I cannot offhand think of a Drupal site that's an exception.  I
> welcome
> counter-examples, and welcome even more so tips about how they
> achieved
> that.
> 3.  They've been somewhat oversold.  That is, if one's community has
> a problem with low participation, it's by no means certain that a CMS
> will fix it.  Let's face it:  It never took a lot of initiative to 
> check Smaug's HTML out of CVS, revise it, and send updates back, but 
> only six people ever bothered to join the project, and only three
> (Jacob Hunter, David Gatwood, and me) ever bothered to edit Smaug's
> Web
> pages.  
> My point?  Lower a supposed technical bar to participation, and you
> will often find out that the technical bar wasn't actually an issue.
> 4.  Security nightmares.  PHP-based[1] CMSs' security histories, in
> particular, have generally been a bad joke, and ones that rely on the 
> PHPXMLRPC daemon more so.  Drupal is both written in PHP _and_ relies
> on
> In point of fact, just to illustrate that point, there's currently an
> Internet worm out and about, aimed specifically at (yet another)
> PHPXMLRPC input validation bug -- thus emperiling Drupal sites, yet
> again.  You'll see a brief advisory about that, here:
> http://drupal.org/
> ...and my analysis of that problem, just yesterday, here:
> http://linuxmafia.com/pipermail/conspire/2005-November/001540.html
> 5.  Performance and software complexity.  This somewhat overlaps the
> prior points, of course.  (Groups will often say "Well, that's someone
> else's problem."  Unwise.)
> Wikis are more lightweight than CMSes; they're more malleable, which
> is
> both good and bad.  It's good that they don't have the "Gosh, it's yet
> another funny-looking Slashdot" problem, but by the same token tend
> towards chaotic lack of structure unless given firm direction.
> An example of both the strengths and the weaknesses of wikis is
> Heather
> Stern and Jim Dennis's "Sysadmoin" site,
> http://www.starshine.org/SysadMoin .
> That one uses MoinMoin, a very lightweight, non-security-catastrophic
> framework coded in Python.  (No database, no add-on SCMs, no PHP, no
> XML-RPC).  See:  http://moinmoin.wikiwikiweb.de/MoinMoinFeatures
> Compare everyone's favourite golden child, MediaWiki, whose software
> mix is almost as big an accident waiting to happen as Drupal's:
> http://www.mediawiki.org/wiki/How_does_MediaWiki_work%3F
> If I had my druthers, I'd go for MoinMoin -- and stay far, far away
> from
> Drupal.  
> > Jacob:  If memory serves, the last time domain registration came up,
> you
> > fronted the cash for it.
> Nope.  
> [1] "PHP" on http://linuxmafia.com/kb/Security/  Suffice it to say
> that,
> though PHP isn't _inherently_ defective, its dangerous defaults and
> development history have brought out the worst in many of its
> practitioners.


Rick's criticisms of CMS systems are right on, in my view. At the same
time, I can say, flat out, I'm never going to spend the time to figure
out how to deal with the current system, but I'd be happy to click on a
wiki's "edit" button.

I agree that simple is better - scruz.org doesn't need an enterprise
class CMS... we simply need an easy way to edit and update content. I
haven't used Moin, but I'm going to download and install it to play with

My wiki preference has been Dokuwiki up to this point.

On the other hand, if folks are comfortable with Drupal, then the
security/administration issues are really Jay's problem, not ours (as
long as we make good backups). :)

Thomas Leavitt

More information about the Smaug mailing list