[Smaug] Web site maintenance (was: scruz.org re-design)

Rick Moen rick at linuxmafia.com
Wed Nov 9 14:09:11 PST 2005


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 CMS
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
PHPXMLRPC.

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.





More information about the Smaug mailing list