Open Source Content Management Discussion?

Media Girl asks: "As someone considering the vast array of GNU/open source CMS systems out there (and right here), what have been the experiences, insights and opinions of developers on the various programs out there, such as Slash, Scoop, Drupal, PHPslash and the various Nukes? CMS Matrix has a nice comparison grid of features, but there seems to be a lot left between the lines, and the Perl powerhouses are left out of the matrix. How do the typical components (blogs, articles, comments, karma) compare? What about modality, security and speed under heavy loads? What about the quality of ongoing development and activity of the app's community? What's leading edge and not bleeding edge? And what about the Perl/PHP debate? Can we take a snapshot of this realm of open source web development applications and hash it around a bit?"

Comments

Community V. Content

[idiotfromia]

There's way too many content management systems out there that focus too much on the content aspect. I found it hard to locate quality open source CMS that wasn't trying to be Slashdot-like. Many people just want some for easily organizing lots of pages in a quick and easy manner. They don't all want to have forums, user profiles, galleries, news, or blogs built into the system.

Keep it simple, stupid.

Re:Community V. Content

[Black Perl]

Exactly. Too many things are being called CMS these days. In reality, some of these so-called CMS systems are closer to portals and blogs than true CMS systems.

You talk about the KISS principle... the problem is that there are two extremes:

simple<------------------>flexible

and the easiest to write and implement are the slash and *nuke-like blogging systems. When a blog is all you want, these may also be the easiest to install and configure.

However, you can easily outgrow these as you may want to have complete control over the page content. That is, more choices than just "2 columns or 3?" or "which theme do you want?". If there are "themes", then it's a hint that it's not very flexible under the hood, as a full templating system doesn't require themes.

It's hard to separate the true, flexible CMS products from the rest. They all seem to say they can do everything, have workflow, etc. What it comes down to is determining your requirements. What do _you_ need out of a CMS? Pick a product that does it and does not try to do more.

I'm a CMS consultant, and I come in to companies to help them manage content. More often than not these days, they've already tried a CMS and the project failed. It seems to be one of two reasons: they've tried an cheap/OSS CMS and found out it wasn't flexible enough for their needs, or got a CMS from a big vendor and it was TOO flexible, i.e. the flexibility comes in the form of professional services because the product is too bloated and complex to easily configure.

What does work? Well, what works for one company may not work for you. Again, it boils down to requirements. And the requirements don't work if they are just feature checklists. You need to start with scenarios ("use cases") explaining how you update your pages. And answer questions like, do we want a product that's an out-of-the-box application, or do we have and in-house development staff for configuration? Do we have the skills we need? (i.e. an XML-centric version will probably require some XSLT skills).

However I can say that one product that stands out, and I have seen used successfully, is Bricolage (http://www.bricolage.cc/) which is on the flexible side of the above spectrum. It doesn't start out assuming how your site is to be laid out--that's up to you. It has a nice, flexible templating system where you define your pages, not the CMS. What it does do is help you capture, organize, and reuse your content. This is where most CMS products fall short, and is really the underlying need most people have.

But I wouldn't recommend Bricolage to everybody. Sometimes Zope+CMF would be a better fit. Sometimes people say they want a CMS, but really need a portal server or even a business process management tool (complex workflow routing with signoffs) instead. An example of that are some of the products that Gluecode offers.

Ease of use

[rueger]

To the discussion I'd also love to see some comparison of the ease of installation, quality of documentation, and how easy it is to design or customize a site. Not all of us are uber-geeks, and a little hand holding is nice.

Open Source CMSs

[allden]

I tried the PHP Nuke and Post Nuke CMSs for my website. Post nuke didn't run properly because the box didnt have mod_php - user community response - blame the web hosting service. PHP nuke had some irritating problems.
These days I am running xoops - no problems at all. It has the best installation among the 3.
Couldn't try others as they either wanted to install in directories like /usr (which my webhst doesn't allow) or they needed postgresql (which again my webhost doesn't provide).
I wanted to try some perl based CMSs which which provided me ease and range of functionality of XOOPs - couldn't find any.

Zope and Plone

[Earlybird]

Zope and its CMS framework, Plone. Take Plone for a spin. It's a breeze to install. The entire system is web-managed down to the core, with a flexible role-based security architecture.

Zope is written in Python, so you avoid the PHP stack and its evils. Unlike PHP, Zope is designed around object-oriented concepts such as encapsulation.

For example, to interface with a database you typically create (again, through the web) a connection object, then an SQL method describing the data (a pure SQL script with a few special HTML-like tags for specifying parameter slots) and finally a page template which calls the method.

The upshot? You just decoupled the data from the presentation in a very elegant way, and you decoupled the data operators from the data source. Abstraction is the key.

Plone, in turn, abstracts much of Zope away to provide an elegant, extensible GUI for managing user-oriented content. It has a workflow system, a component system, WYSIWYG article editor support etc.

(The workflow system allows complex flows such as "both John and Jane must review and accept the article before it can be published, and after they've reviewed it, spelling wizard Bob must look over it before it for typos; but users Jack and Jill are trusted users who don't require John or Jane's approval to post articles.)

Unlike most other CMSes, Plone/Zope have no external dependencies -- no MySQL needed, for example.

CMS mailing list

[Matt Perry]

There used to be cms-list.org before it went down in early 2004. People used that mailing list to talk about what you are asking and more. You can find archives online (search on Google). This site is supposed to be the new incarnation of the cms list so you might want to subscribe and ask there. I'd have a list of your requirements in hand before you ask questions on the list. Since the term "content management system" is so generic asking what's the best CMS isn't going to get you far until you figure out what kind of content you need to manage it and how. That will dictate which CMS products you'll consider and from there you can look at the technical aspects to see what works best.

Just my two cents on the subject.

Slashcode considered harmful

[FooAtWFU]

Slashcode produces horribly mangled non-standards-compliant HTML (and it claims to be HTML 3.2). Consider something else besides it. :)

Not a surprise, but why not a wiki?

[Noksagt]

Blogs were the first and are the most deployed apps to use CMS. HTML-savvy people wanted to provide the rest of the world an easy way to contribute content. I'm aware of very few apps meant to make a web developer's life easier by allowing online editing as if it were an online Dreamweaver or what not.

If you want KISS & need to add a lot of content, what is lacking in wikis?

Re:Not a surprise, but why not a wiki?

[photon317]

I've been in the same boat as the guy you're replying to, and my answer to this question would have been that what I really wanted was something structured and designed more like the typical CMS implementation (database-backed, web-based admin without any html coding experience needed on the users' part, "document" upload of word/pdf/etc with searches and categories and all that, etc...), but I just don't want "community" features like blogging, news, rss, etc...

The usual answer that I've taken is to use one of the full-blown CMS-like packages out there and strip out all the functionality I don't want, which can be a pain to maintain as new releases come out.

Re:PHPNuke

[a.koepke]

PHPNuke has gotta be one of the most poorly written PHP apps available. Run the code with the error level set at E_ALL and watch the amount of notices you get for undefined variables and improperly used array references.

Re:PHPNuke

[TheLink]

It's got more security problems every other week or so. And the author sure didn't handle the security bug reports well when I last checked.

Friends don't let friends use PHPNuke.

The people handling my church site wanted a PHP based solution, when I vetoed PHPNuke and its cousins for security issues, they suggested EzPublish. Their source code didn't look that icky (signs of some clue being present) - on my brief look at it. Yes I looked at PHPNuke's source code, and it was crap. I had actually looked at it before that too when my prev boss was hyped about it, and it was crap then too.

From bugtraq reports it sure looks like it's still crap.

Consistent lack of significant improvement after so many years = developer(s) does not have the ability/desire to handle the issues AND/OR the issues are architectural.

Re:Depends on the exact purpose

[Kick the Donkey]

We're dealing with the same kind of discussion at work. To us, there are three major categories of CMS's:

1. Document Management
   Checking documents in/out, versioning, etc
2. Portal Management
   Slash, Nukes, etc.
3. Web based Content Management Wikis, Blogs, etc.

I posted some of these thoughts here: http://ktd.sytes.net/index.php?p=26

What we wanted, was some ability for a portal (some blog like funcitoinality), but we wanted the best of both worlds from Wikis and Nukes. I wanted to flexable page orgaization of a Wiki (can put in as many pages I want) but have some of the forced layout of a CMS. Some systems I've tried:

• TikiWiki
• Drupal
• CMS Made Simple
• Jaws
• Wordpress
• MediaWiki

Some of those systems are very inmature, but are growing everyday. Sometimes, all you want is a system to edit web-pages throught a webbased interface. Not everyone needs a portal.

Re:Try eZ publish CMS

[bjpirt]

I couldn't agree enough. eZ Publish is the most flexible CMS out of a large number I have evaluated. Like most PHP programmers at some point in their web career, I was considering writing my own CMS (as I already had kind of partially written one anyway) but as soon as I really began planning how I would build it I realised that eZ was exactly what I was planning to build.

Once you get your head round the templating language, there's very little you can't achieve with it.

commercial ones are better at the moment

[jilles]

I work for a company (www.gx.nl) that sells its own cms. Let me just summarize that we are more worried about other CMS companies than open source alternatives right now. OSS CMSs are just not that competitive right now. The reason for this is that there's more to a cms than installing the software on a server. That is the really easy part. The difficult part is actually developing the site to the customers specification (look and feel, dynamic functionality etc.), migrating his old content and integrating with backend systems. Then you also need to make it really easy for them to edit the content & layout and on top of that you need to continue to support their installation.

This requires expertise and technical solutions. We provide both. Most of our customers do not actually care about what the software is or how it works. They just give us specifications and expect a working site that they can add content to effortlessly: that's what they pay us for. They neither have the expertise nor the desire to hand tailor some OSS system. License cost compared to development cost is negligable so most cost conscious customers will gladly cough up the license fees if they are convinced that it will cut down the total cost, especially if a nice support contract is bundled.

Often we find that a customer is actually using some tailor made system (sometimes based on OSS components). Usually the reason they are coming to us is the lack of flexibility, soaring maintenance cost of their existing software.