part of me likes to make life difficult for myself, insisting on running
old hardware until it won't run anymore, and being a grumpy unix
curmudgeon in general.  I can relate to the insect-ridden shaman
described in the unix-hater's handbook.  the brave new web 2.0 world is
browser based, and it seems to me like yet another set of buzzing flies
and stinky poo to deal with.  I've gotten used to the existing ones,
thanks.

I was asked to look into content management systems on behalf of one of
my club's members, who is interested in redoing our club's website.  his
suggestions were drupal, joomla!, and plone.

most CMS systems are built with mysql as a backend, which would be fine,
except that mysql still doesn't run correctly on the alpha architecture.
I don't know if x86-64 is any different, but I get a steady stream of
unaligned access warnings, and flat-out refusal of mysqld to run on my
NetBSD-running alpha.  by contrast, postgres just works.

I was ready to kill joomla! straight away since it has an exclamation
mark built-in to its name.  "... because open source matters".
obviously portability doesn't matter to joomla!, which only supports
mysql according to the minimum requirements posted at
http://help.joomla.org/content/view/34/279/ .

plone is built around zope.  zope so infuriated a friend of mine a while
back that he created http://zope-is-evil-666.idyll.org/ .  his
experience in this arena easily trumps mine, which is enough to give me
pause with any project utilizing zobe, but I figured that his objections
had been addressed in the last seven years.  however, after reading
further, it appears that plone has its own idea of how databases should
work, and doesn't use a SQL backend out of the box.
http://plone.org/documentation/faq/plone-relational-database
thanks, zopers, but I have better things to do than wank in python.

this left drupal.

drupal's installation was fairly painless: create the database; set up
some rewrite rules in apache; go to the magic drupal page; tell drupal
where the database is; start plugging away.  the fact that I had to
configure drupal through the web interface was a warning sign.  after
poking through web configuration, it hit me...

drupal is set up for content management entirely through a web
interface.

<insert wincing here>

can't I just edit some templates for layout out of band, post content
>from the command line, and have some separation between the input and
output stages of my CMS?  web input methods are _STILL_ the simplistic
hack they always were, and the last thing I want to do is handle content
generation WITHIN A WEB BROWSER.  I want to view it in a browser, but
not generate it there.  I'll edit XML, even.  drupal does not appear to
accomodate.

I hate it.  I hate all the CMS software I've examined so far.  I'd go
back to bashing my stones together and dealing with static content,
except that I really do want to separate content from presentation and
store content in a form which can be indexed in multiple ways.
(symlinks in a filesystem are difficult to manage.)  I'd love to tag my
rants, content, and pictures, see RSS feeds on a single page under my
domain, and be able to generate pages based on lookups from a content
store.

wordpress can bite me too.  "drop this tarball in a directory and see
what breaks" does not appear to be a good upgrade strategy.  (trojanned
distributions are also of some concern.) 

it's almost as if everybody who learns PHP goes through a "let's write a
CMS" phase where supplication at the idol of browser is a necessity.
fsck the browser.

if I actually get around to drafting a requirements list for a CMS, and
implementing said system in a compiled language, hell must be a chilly
place indeed...

-- 
  Aaron J. Grier | "Not your ordinary poofy goof." | agr...@poofygoof.com
    The United States is the one true country.  The US is just.  The US
    is fair.  The US respects its citizens.  The US loves you.  We have
    always been at war against terrorism.

Reply via email to