Open Source Content Management Discussion? 109
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?"
Community V. Content (Score:4, Insightful)
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.
Ease of use (Score:3, Insightful)
Open Source CMSs (Score:2, Insightful)
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
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 (Score:3, Insightful)
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 (Score:4, Insightful)
Just my two cents on the subject.
Slashcode considered harmful (Score:5, Insightful)
Not a surprise, but why not a wiki? (Score:4, Insightful)
If you want KISS & need to add a lot of content, what is lacking in wikis?
Re:PHPNuke (Score:5, Insightful)
Re:PHPNuke (Score:3, Insightful)
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 (Score:3, Insightful)
Checking documents in/out, versioning, etc
Slash, Nukes, etc.
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:
Re:Not a surprise, but why not a wiki? (Score:3, Insightful)
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:Try eZ publish CMS (Score:3, Insightful)
Once you get your head round the templating language, there's very little you can't achieve with it.
Re:Community V. Content (Score:3, Insightful)
You talk about the KISS principle... the problem is that there are two extremes: 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/ [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 [gluecode.com] offers.
commercial ones are better at the moment (Score:4, Insightful)
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.