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.

Not really a help...

[name773]

but you win for the best summary ever, good job... seriously, it's well written.
my site is small enough, with few enough participants that i can get by writing my own; it just provides a web frontend for editing the text files directly. this directory has the source code... if anyone is interested

Typo3 rules them all

[smeat]

In my not so humble opinion, if you want a full featured and supported open source CMS get typo3.

They have freaking instructional videos for $DEITIES sake.

Marketing page:
http://www.typo3.com/

Community pages.
http://www.typo3.org/

smeat!

Re:Typo3 rules them all

[magefile]

If you need a video to learn to use a CMS, then either you shouldn't be using a CMS or you should pick a different one.

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.

Try em yourself

[insensitive claude]

Open Source CMS

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.

Re:Zope and Plone

[ctr2sprt]

Zope/Plone are indeed awesome. The downside, and it's a big one, is that far fewer people know Python than PHP and Perl. Make sure you consider the possibility that five years down the road someone else - someone who doesn't know Python - may be running the site. While you can do customization without having to know Python at all, sometimes adding feature will require actual coding.

This is really only a concern if the website's for your employer or a customer or something. If it's just for you, then I'd definitely say to go with Zope/Plone. If you really want some feature you can't find elsewhere you can always (learn Python and) write it yourself.

Re:Zope and Plone

[quamaretto]

I note (from reading the Zope 3 book) that Zope itself is way more general than a content management system. Here is the quote:

Zope is an application and backend server framework that allows developers to quickly implement protocols, build applications (usually Web-based) and function as glue among other net-enabled services.

Of course, I've only just started poking through the documentation and so forth, but so far, Zope as a technology reminds me ASP.net, only more abstract and general.

In response to c2rtwhatever: Python is probably the easiest language I have looked at so far; a programmer who has already used other high level scripting or programming languages will find it easy to learn, even if they hate the forced indentation. This is not to say everyone should have to learn Python, but it's doable. :)

Re:Zope and Plone

[Bwanazulia]

As someone who has been building sites based on Zope for the last 3-4 years, my personal experience is that it is extrememly powerful.

Zope Pros:
- Built in everything: Webserver, ftp, webdav, gzip, caching.
- Great products: Plone, CMF, discussions, content types.
- Everything is an object. This sounds strange, but actually lends itself to the web very very well.
- Huge, active community. Tons of examples. Tons of sites.

Zope Cons:
- Documentation, while getting better, is not at the level of other solutions.
- Python while the right choice (and better) is not as well known or supported
- Splintering of efforts in the community now. Zope X3, Zope 3, Zope 2.8, CMF 1.5, Plone. They will all come together in the next year or so, but if you are a newbie, it would be a hard choice of where to jump in (probably Zope 2.7.3, Plone 2, CMF 1.5 (included in Plone).

BZ

My experience: pMachine, Wordpress, MovableType

[prostoalex]

Mainly dealt with the blogging engines here, since most of the sites are content-driven without the need for many additional modules.

MovableType - fast to setup, easy to deploy, live community with hacks and what not around it, but since the move to the paid distro in 3.0 the activity died off a little bit. Never upgraded to the paid version, couldn't justify the license money with WordPress having so many similar features. It's a Perl+MySQL or Perl+flat file set up, so theoretically nothing more than cgi-bin is required.

Which brings us to WordPress - extensible, lively community, very easy to install and setup. The engine itself is a bit immature at this point for some advanced stuff, but if you know PHP, you'll find your way around it. Has a link manager and mass edit for comments (very useful for spam treatment), extensible as far as design, not too modular though.

pMachine - easy to set up, easy to use, but not too flexible. Coded in PHP and uses MySQL, many tweaks available, but limited functionality for the free version. The authors have since moved on to a different project, Expression Engine, and the community is a bit abandoned.

The above links are going to my sites which run the said engines, not the engines themselves, a simple google search would take you to download pages for the engines.

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.

Quick Summary

[natmsincome.com]

Hi,

Here's a quick summary.

First of all you can check out a live version of almost all of the CMS at opensourcecms. This is a very good place to start.

First of all what do you want?
The main types are:
* Portals - Think slashdot + forum + gallery etc. * Wiki - Think wikipedia
* Blogs - Need I say more.
* Groupware - Think Sourceforge.
For wikis the main one I like are:
* PmWiki for an easy to install persoanl wiki.
* Media Wiki for a large company wiki.

I don't do blogs so ... no idea.
I've tried a couple but none of them have really worked yet in my projects.

Portals ... We'll again what do you want? If you want a community portal Drupal and PostNuke are popular. If it's a small content based portal then I'd have to same mambo is the best. But if you're going for a larger installation then I'd recommend Type3 or Phone. All of the above execpt Phone can be checked out at opensourcecms. As for php vs perl. We'll php is so much easier to install because most of the perl ones require CPAN packages which users don't have the right to install on most hosting servers. On the other hand some servers on support perl so it's really up to you. If your not planning on changing it the lanuage is very important.

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. :)

Re:Slashcode considered harmful

[cloudmaster]

I wonder why it returns 403 when loaded into the w3 validator? :)

Slashcode is pretty poorly represented.

[Anonymous Coward]

This site looks pretty impressive until you look at the individual cms description pages. For instance, Slashcode according to the site, doesn't have content scheduling, rss feeds, blogging, a plug-in architecture or online administration. In fact, slashcode appears to do nothing at all. So I gotta wonder how solid the information for the other cms' are.

Anyone out there have more expertise on the other CMS's want to double check this sites work?

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:Not a surprise, but why not a wiki?

[Paul Bain]

Blogs were the first[,] and are the most deployed[,] apps to use CMS.

A blog is definitely not a CMS. A true CMS has certain features, such as content "versioning" and support for workflow.

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.

To the contrary, many CMS's are evolving in precisely this direction. Increasingly, they are improving their user interfaces (UI) so that the CMS UI becomes, in effect, a WYSIWYG word processor. As an example, I cite the excellent UI in OpenCMS, which somewhat resembles MS Word. Adding content to OpenCMS can be just like editing in MS Word except that the OpenCMS UI still does not have quite as many features or the same ease-of-use -- yet. See also Bitflux and Xopus, which are WYSIWYG editors meant to be used with any CMS, not a particular CMS.

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

Wikis can be be easy to install, administer, and use. But they lack a great deal.

Security -- many are poor at best

[Spoing]

To give you a basic idea, some are quite painful to install with SSL enabled if you don't have root access. Others just discourage it.

Additionally, quite a few have a default data from the development site; you're getting a carbon copy of a site not an application. Wikis tend to be the biggest offenders. Twiki, for example, is a royal pain to configure from scratch if you want to start with a blank slate. Use the Twiki site data itself, and most of it seems to work...till you start to customize things...and it breaks again. Very annoying.

I'd treat them with a great deal of caution.

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:The problem with current CMS systems

[afd8856]

You should have tried Plone than. Of course, it's not PHP or Perl, but if you know these Python is at a difference of just one day of learning. It has everything you ask for:

• tree structure: the content is stored in a file-system like tree, with folders and files you can navigate. Of course, this system is virtual, as all the files are stored in a database. It also has a navigation system that has a tree-like appearance.
• easy templates: to modify the appearance you just have to edit one .css file. Of course, how different the result will be depends on your css hacking skills. Also, Plone has a sistem of "skin layers", that make it easy to add a new skin based on the default one. Every relevant template is customizable through this system: you just add the template (for example, how the document type is rendered, or how the news type is rendered) to the "custom" skin layer or to your own skin layer and it will override the defaults.
• easily configurable: well... it depends on what you wish to do with it. Once you understand what happens it's easy to do everything. But there are a lot of howtos and a couple free plone books available that can teach you what you need to know. Also, the community is very helpful. This is a project entirely created by the community, it's not a comercial project suported by the community. Of course, if you need comercial support, there are quite a few businesses that can help you.

I have to mention something: Plone runs on zope, which is an application server that includes database system, web server, templating system, scripting, real database connectors, etc. To do realy advanced stuff in zope & plone you would need to learn python. But python is a fun and easy to learn language, so I wouldn't put this as a negative point :)

Plone is at this moment at version 2.x, so you'll get an already refined system.

And another thing, Plone was declared the best CMS for 2003 (I forgot at which event, but it was an important one), surpasing even comercial offerings.

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.

Don't install phpNuke

[baldass_newbie]

It's a freaking security nightmare.
Once you get on the defacement lists, expect to get hit with every new 'sploit as soon as they're out. Francisco Burzi may be a nice guy, but he doesn't know shit about coding secure PHP. If you're going to run it, you'll at least need one of the secure releases or better yet...

Use drupal. Very solid, safe, secure and easily configurable. The toughest bit is figuring out taxonomy or categories that the various entries (blogs, forum topics, stories, etc.) adhere to. These things are all 'nodes', btw. But once you have your categories down, you're done.

You can even search for a script to do the conversion from phpNuke to drupal, and no drupal doesn't require any special directories. Give it a whirl.

And if folks are whoring sites, then I'll whore mine.
Brew-Masters
I have the throttle hooked up, so hopefully it won't get slashdotted, but then it doesn't look like this thread is getting a lot of comments.

Re:The problem with current CMS systems

[baldass_newbie]

First off, you say three and name four. You must be a project manager. ;-)

Secondly, if you can ignore WYSIWYG (please, what is 'preview' mode for?) then check out drupal. Small, tight, easy to configure, treelike structure. You'll spend more time trying to figure out your categories than you will doing other crap to get it rocking.
Themes are light and largely CSS based.

Try eZ publish CMS

[funnybug]

I tried so many cms with interesting features. and I spent so many hours trying to find tutorials and docs... I stopped searching since I discovered ez publish. PROS: You can build any kind of site with it (from a home site to a corporate portal with ecommerce b2b/b2c features). It's full object oriented like plone, and is build under php. You can use mysql or postgresql as database backend. It's relatively well documented (everything is in their web site, and there is a book "Learning eZ publish" available to buy from the site). In my opinion, it's the best open source php cms available (it has also commercial licence). CONS: It takes 160 hours to master the product (including the scripting language). Visit the site: http://ez.no/

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.

Re:PHPNuke

[Synistar]

Yes, PHPNuke and PostNuke both have had a bad reputation for security exploits. A better alternative is Xoops which is also a Nuke derivative but better managed and coded (not to say that it is perfect).

Of the non-Nuke portals I would say that Drupal seems to be one of the most well coded engines. Xaraya is also probably worth a look to but I have not used that one.

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.

What are your projects *needs*?

[mobiGeek]

You need to get a very good list of your "business needs" to start with. Starting to install and configure a particular CMS (and I use the term loosely...) is a waste if you don't know:

• who your content-providers are and their technology strengths (and tolerance levels!!)
• who your end-user community is and how "involved" they will be in the site (forums? community-driven content? story submission? ...) [don't get caught in the "needed feature" vs. "cool factor" trap!]
• who your admins are and their technical strengths/weaknesses (are these the same people who will be configuring the system? are they coders or do they only work from white-books and red-books ?, etc...)
• how much time is devoted to adminstration of the system?
• a single look-and-feel template for the whole site or different sections get their own template(s)?
• do you want to separate development, test and production?
• how much time is devoted to enhancing the system?
• what skillsets are available for enhancing the system?

Once we listed out these, we found that a number of the CMSes I see people talking about here fell off our list.

We don't want to have users "logging in" to our company website. We don't need/want forums/blogs/galleries. We need a simple-to-use content-provider interface for people with little-to-no webskills. We want separate servers for development, testing and production. We have a very skilled set of admins, but they don't want to be tweaking the system every day.

Based on our evaluation period, we believe we are going forward with Bricolage. It is not an easy system to get into, but its power and flexibility is fantastic and it has a fairly supportive community.

One downside to Wikis

[attaboy]

I've used Scoop, Drupal, and built a couple of custom lite-CMS solutions. My only experience with Wikis is installing MediaWiki. To me the biggest downside was support for inserting straight HTML.

While you can insert HTML into a Wiki entry, it isn't recommended. They want you to use the Wiki tagging language. This makes sense because the Wiki tagging is used to convey useful meta-information and separate content from presentation, but at the same time, losing the ability to use all of the functionality of HTML when entering content seems like a big trade-off.

Some of the MediaWiki developers explained that while it is easy to convert Wiki tags to HTML, it's much more difficult to convert HTML to Wiki.

I don't know that any current CMS can adequately accomplish the goals of separating content and meta-information about that content from its presentation. Storing a bunch of HTML in a database field is going to reduce the possibilities for multiple-use (e.g. non-HTML E-mail delivery, RSS and other feeds, etc.) At the same time, inserting content, including legacy content, that has already been formatted using HTML is going to be desirable by at least some users.

Drupal's ability to include not just HTML, but even PHP code within posted contents was a really powerful tool, but exacerbates this problem even more.

To me, a CMS powerful enough but easy enough to use by my company would be able to:
1- Provide a WYWYSIG editor for those who just want to add new content.
2- Allow users to cut and paste highly formatted content from (gasp!) MS-Word, Excel, PowerPoint, etc.
3- Allow insertion of HTML-formatted content. Given that one goal of serious CMS is to avoid storing HTML as is, this would then have to be parsed and split between content and presentation, and be able to deal with a variety of HTML standards, as well as non-standard HTML.

To me it seems like XML may provide the best hope for being able to accomplish all these goals, or they may be mutually exclusive.

If there's something out there that already does these things, pray tell...

Re:One downside to Wikis

[Noksagt]

To me the biggest downside was support for inserting straight HTML....losing the ability to use all of the functionality of HTML when entering content seems like a big trade-off.

These seem to be a bit incosistent, no?! Inserting straight HTML can be a security risk and/or wouldn't be used by non-savvy users. There are wikis that do and don't let you use HTML, so I don't know what the big deal is...

1- Provide a WYWYSIG editor for those who just want to add new content.

The best you can do without something like an applet or clever javascript or shock or XUL is to have a preview. I would personally prefer a simple HTML form interface that works on all browsers well than it to almost work in some browsers.

2- Allow users to cut and paste highly formatted content from (gasp!) MS-Word, Excel, PowerPoint, etc.

Not gonna happen without an even more ugly hack: Windows and windows-based browsers doesn't even try to accept pasted markup/images/etc. Should be possible to upload a word document & have openoffice/antiword/acrobat/etc. convert it into a more web-friendly format.

3- Allow insertion of HTML-formatted content.

Some wikis do allow this. It is trivial for them to do so. But it is a security risk & I think the HTML-parsers or strippers have been built for a reason.

Perl Plone alternative

[Chris Croome]

I agree with all the comments about Plone being great, if Plone existed before we started developing MKDoc then we probably wouldn't have bothered... If you like Plone but want a CMS written in Perl then check out MKDoc.

MKDoc doesn't yet have such a big community around it yet but it's only just been GPL'ed...

The PHP CMS's are great if you don't have root, if you do then the Zope, Perl and Java ones are worth checking out.

Another one that hasn't been mentioned here is Java Mir the Indymedia CMS.

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.