Content Managers for generic websites?

I’ve sort of fallen into a task where I need to set up a website for a small group of people. The site will be used for general marketing, schedule information, and as a resource the group will use to pick up materials and information to share between themselves.

As someone who has been pretty active in the Content Management arena, I’m finding myself stymied at how difficult it is to find a simple web-based content management solution that will allow other users in the group (a limited number – onlye 1-2 other technical folks) to maintain the site.

We already know we’ll use a Wiki for the ‘internal community’ aspects – we’re doing this now – it’s allowing uploading, downloading, content editing, etc. But using a wiki to drive the main site seems… out of sorts. Wikis are not made for general-consumption-by-the-public websites.

So I’m looking around. I haven’t found what I’m looking for yet, but I’d like to hear from other folks what they’d recommend.

What I’ve looked at so far, and my feelings on each, follows…

Movable Type
SixApart
The obvious first guess. I use it to run my blog, several other blogs (1, 2, and 3), as well as running the commercial site for my business. It’s worked well, but I feel it’s best suited for, well, blogs. And the new site, while it will most likely have a newsticker, won’t really be for dynamic and changing content and commentary. The pages will be primarily contact information, static content, and some schedule information.

PMWiki
pmwiki.org
PMWiki is one of the best wiki programs out there. Very simple to install, quite powerful, very active development and a busy user community. The baseline code is solid and strong, and many folks have contributed ‘Cookbook’ entries – either pieces of code to add functionality, or little snippets of information on how to tune PMWiki to do a specific set of tasks. The problem is that PMwiki is, primarily, a wiki. It’s a collaborative editing tool. It can be massaged into making some beautiful sites – ones that folks would be hard pressed to identify as a wiki (see the SuccessStories page for some prime examples), but my experience has been it involves forcing a tool to behave in a way it wasn’t designed to behave. I may come back to this, but I want to look at more ‘traditional’ systems first.

Mambo
Miro International
We recently converted a long-term standalone site to Mambo, after several recommendations from the community. All in all I’d call the end result a success. We have administrators making changes and updating the site all via webforms and other tools, but I must admit, the Mambo design concepts have an incredible steep learning curve. The administrator interface, while powerful and clean, does little to help an inexperienced administrator through the deployment and design process as they build a website. Even now, 6 months after launch, I rarely work with the site because since the design is so non-intuitive, it’s difficult to say “Oh, lets add this menu and these pages” – there’s no simple way of approaching that situation. The designs are also HIGHLY constrained to what Mambo decides the site should look like. Making significant changes to the layout and structure of a site beyond what Mambo thinks it should look like is a major undertaking.

Plone
The Plone Foundation
Plone is an opensource content management and portal / community system built upon the incredibly powerful Zope management system. It is an object-oriented dynamic application platform that I’ve always considered one of the best designed and thought out systems ever. So why am I not using it? Zope requires a huge learning curve and long detailed operation simply to get a website up, let alone installing Plone on top of Zope. I spent 2 days downloading and installing components into my local Zope installation and I had yet to figure out how to properly attach it to my Apache-served page structure. (It turns out the best way is using a reverse proxy in Apache to connect to an internal Zope HTTP instance to serve the pages – How simple! NOT). Zope continues to be the most powerful, most poorly documented system around. The ‘Documentation’ that is constnatly referred to is nigh on impossible to read because it’s been spammed so heavily with random edits and commentary. When asked “is the documentation being maintained?” on the Freenode IRC server, I was told “sure it is.” “Then why all the comments – some 8 months old – with no relevance to the article?” “Just turn off all the comments.” – which nullifies also the helpful commentary, of which there’s a LOT of it, because the baseline information is so sketchy.

I keep trying to like Zope. I’ve deployed 2 sites on it, and while I was reasonably happy with the end result, the total lack of organization in the development, planning, documentation, and structure of the project tends to drive me barking mad. A system 5+ years old should be mature, stable, and documented. Zope is mature, it’s somewhat stable (MANY major code revisions have happened, and plugins from 2 years ago may simply no longer work. Not that that’s written down anywhere), and the documentation, as noted, is painfully lacking. Alas, I have to pass on Plone and Zope – I cannot spend a week simply configuring the code to show a ‘hello world’ page.

So where does that leave me? I’m looking for other suggestions, systems that’ll let me post pages, edit them, make consistent design decisions, and add functionality either via plugins or via simple coding. Folks can pretty much not bother mentioning PHP-Nuke or the like. I’ve heard nothing but horror stories regarding the security (or lack thereof) and code quality of that system.

About

A wandering geek. Toys, shiny things, pursuits and distractions.

View all posts by

3 thoughts on “Content Managers for generic websites?

  1. My Other Job uses PostNuke and it’s…okay, kinda. Needs a lot of third-party modules and hacks to make really functional. Not sure I’d use it again.
    For my dayjob, we looked over Bricolage, and it seemed really impressive and full-featured. We mostly decided not to use it ’cause it’s in perl and we’re a 100% php shop (and already had about 60% of our own custom CMS written).

Leave a Reply

Your email address will not be published. Required fields are marked *


The reCAPTCHA verification period has expired. Please reload the page.