Content management system recommendations?

[FoxtrotUniform]

For a very long time, I've been annoyed with the "usual" methods of publishing web pages. (Have a look at my university page for an idea.) Even assembling HTML::Mason templates is a pain, especially the process of sshing into the web swerver, creating a new page, remembering to include the right templates, and linking to it. The result is that I don't update nearly as often as I ought to, and people give up on my site in disgust.

Well, the site got clobbered recently, and I'm assembling a new machine to host it, so I have the chance to do something less annoying. Specifically, I'm looking at content management systems (if that's the right term): groovy chunks of (Perl) code connected to a database backend, generating templated pages on the fly and allowing straightforward remote administration. (The ones I've looked at also include facilities for user accounts and suchlike; while I don't anticipate ever wanting those features, it's nice to know that they're there.)

So I've looked, briefly, at these systems:

• slash
• Bricolage
• OpenInteract
• And, of course, Everything

So, I ask:

1. Is this the right class of tool for the job? (I want to develop a site that's easy to change, able to format and display data from many DBs, and not necessarily involving users, accounts, and other such transactions.)
2. Are there any other systems that I've missed?
3. What kinds of experiences have been had with these? Which one would be the most suitable?
4. How do these rate for support and expandibility?

Thanks, all!

--
:wq

[tadman]

Everything is quite the system, but it is a bit complicated. Understanding it has taken me five separate installations, and even now, I'm only beginning to get it right.

For "content management", it may be what you want, since it is multi-user, and very extensible. It's also Perl, which is a bonus, meaning you can do almost anything with it, given enough time and initiative. The only problem is getting it to operate the way you want it to.

It will probably take 3-4 weeks to figure out how to work with Everything, and even then there will be surprises. If you have this kind of time, the end result can be quite rewarding, since Everything is really fun to play with once you know your way around. Until that point, though, it can be agonizing. Documentation is pretty sparse.

So, while Everything is very extensible, and very workable as a content management system, it is relatively slow, and tough to learn. If you like a challenge, this may be your best bet.

[jeffa]

I recommend taking a look at Zope. Not as a solution, but merely as an example of how to offer content management. Zope uses Python, and even though it can be configured to use Perl (somewhat), it was really meant to be used with Python.

Personally, i would rather use Everything or slash. But, taking a look at Zope will not hurt, just to see another way of doing it.

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
F--F--F--F--F--F--F--F--
(the triplet paradiddle)

[perrin]

People always say to look at Zope, but it is a pretty sad excuse for a CMS. The basic install just gives a way to edit HTML pages through a browser. They have started to make some progress on this, but the features I expect out of a CMS (flexible data model with object relationships, data independent of presentation, scheduling of content, etc.) are not there.

[FoxtrotUniform]

Never mind that bug reports (and, to be fair, patch reports) for some of the other CMSes (Zope and PHP Nuke) show up on BUGTRAQ fairly frequently, whereas I don't remember seeing anything about the Perl-based CMSes mentioned above.

"No root for you!"

Update:Zope is Python, not PHP. Corrected. Still shows up an awful lot on BUGTRAQ, though. Thanks eduardo!

--
:wq

[jeorgen]

Zope is great and I'm heartily recommending it. I has some idioms in it's design that you may or may not like, like a reliance on multiple inheritance (that they call "mix-in classes"). But the truth is that they have put a lot of thought into the design of Zope, and it just plain works. Zope uses plug-in applications called "products". A product is some python classes that make up an area of functionality, either a full fledged application (like a web log or publishing system) or a building component for a larger application (LDAP authentication, rating system, Internet Explorer WYSIWYG editing of HTML in forms).

A drop-down menu lets you instantiate the product, that is install it anywhere you want in your web hierarchy. You then configure each instance through the web. User management and session mangement is built in, the database methods return rows with each column value tagged by it's column name, something I'm still to find in the DBI module.

All your objects (instances of products, data, users) are stored in a hierarchical database where they can address each other in a funny kind-of-inheritance-based way called acquisition. At first it is bewildering, but it makes it so easy for objects to call each other. In perl I usually store objects in slots (Atributes) of each other. This becomes messy.

Sure, there are some design decisions done in Zope that you have to follow and that you may or may not like, but development is about 3x faster for me in Zope than in Perl, and I've done a lot more perl than zope.

One problem if you're living in e.g. Scandinavia is that there are very few Zope developers around. Here in Sweden I think there are three (myself included, though I'm more of a hobbyist). This makes it hard to recommend customers to use it, since one emigration, one change of career and a traffic accident would reduce the number of developers to zero. So, for my customers I'm still using perl.

/jeorgen

[ajt]

There are two kinds of system that most people mix up:
1. Content Managment Systems, e.g. OpenMarket, RedDot, Interwoven, eGrail.
2. Application Server (Frameworks|System), e.g. Zope, WebLogic.

Some systems, e.g. Vignette can do both, and are very expensive, complex and rare.

News systems such as Slash and Everything are quite different, and while excellent at what they do, they are not CMS or AppServers - though they may use them....

I would define a CMS as a system of storing and organising data, so that you can publish it on the web. A CMS may have an internal script language for end-user use, but it's really a system of working out who can create and edit content, work-flowing content, and finally publishing it.

There are lots of CMS:

• Red Bridge Interactive - DynaBase, engenda or entrepid
• RedDot Solutions - RedDot
• Idetix - Revize
• Also see ClueFul CMS and Camworld CMS lists

A CMS systems costs from US$20k to US$250k, and often four or five times the licence cost in installation and configuration.

There are some open source and free CMS offerings, but they have struggled, as it's a complex undertaking that's not proved very helpful to open source development, and several of the products in this sector have failed because the company backing them went under.

An AppServer, is typically a script enabled delivery engine, ideally talking to the CMS to get it's content. You write delivery rules and pages are assembled dynamically from allowed or published content.

AppServers are your typical J2EE monsters, big and expensive, and usually Java based:

• iPlanet Application Server
• IBM Application Server
• BEA WebLogic
• Zope (Python as used by ActiveState)

It sounds like what you are describing is more like a Perl (mod_perl) based AppServer, with a back end database. Content isn't managed like in a CMS system, but more in the way that a News site running Slash or Everything would.

The problem I found, was that other than Interwoven (very expensive) most of the commercial CMS space is not friedly towards Perl, and many of the open source offerings are Java based too. Most of the AppServers are Java or ASP too, so another unfrieldy space. I think that while Slash and Everything are good, they are mostly on their own as Perl offerings

Disclaimer: I use to work for a mid-sized CMS vendor, we built an XML based light-weight CMS system with integrated light weight AppServer abilities, and based on that a heavy duty CMS, that exported/linked to third party AppServers. The Products were written in c++, ran on Solaris iPlanet or NT/IIS, and had a typical selling price of US$350k. Serious CMS systems are VERY expensive.

Good luck in your search...

[ichimunki]

I have only recently come across the Wiki idea in serious use as I delve into the Ruby community, so I can't address some of your issues. But you might want to check out Twiki as well as any other of the many WikiWiki type engines. While mostly geared towards collaboration, TWiki does incorporate some very powerful and interesting RCS functionality (and you can always use authentication to limit who can actually use the edit functions).

Pros: there are a few WikiWiki systems out there written in Perl, and TWiki can use plugins of some sort (so if you need a special feature like a database connection...)-- oh and it's GPL, always a feature I look for in software. Cons: looks like getting the site skinned out and customized could take some time, plus you have to learn the system, but that's a problem with any premade system, no? See UseModWiki for a slightly simpler implementation of the same basic meme.

I think the Wiki method actually does what Everything wants to do, only better (at least as far as the E2 version goes), but doesn't depend on a database backend. I do worry about the security aspects of the systems I've seen, but I think that's mostly me being paranoid and new to the systems. I am planning to implement a TWiki clone on at least one site and probably two others. It seems like it will be easier than trying to roll my own solution.

[perrin]

Bricolage is probably the best choice for a flexible system with no programming required. OpenInteract is the best choice for a system that you intend to build to your needs, with custom code. The others make more assumptions about the data model you want to use and the way you want to present it.

[jeorgen]

My customer don't usually have access to mod_perl; web hotels seem wary of installing it. Is it possible to use e.g. Bricolage without mod_perl? Or more to the point, is it easy to do it?

I vaguely remember a how-to for doing that for HTML::Mason, but it seemed a bit complicated. I couldn't find any info on it in the Bricolage docs. Is there some kind of fool-you-I'm-mod_perl module?

Grateful for any tips
/jeorgen

[perrin]

Although theoretically you could use Mason without mod_perl, it would be very slow and probably not worth the trouble. You would be better off finding a way to either package mod_perl for them so they can install it easilly, or arrange off-site hosting.

[thraxil]

a lot of webloggers have been using movable type (free beer but not Free speech) and greymatter (also not Free and the code is a tangled mess).

i'm not really crazy about either but i guess they're worth looking into. i found that my best option was to roll my own (source code will be available under GPL once i finish cleaning it up) taking the features i liked from slash, mod_virgule, blogger, and a dozen others. it wasn't that hard and is far more satisfying in the end.

anders pearson

[dws]

After looking at your homepage, I'll second the recommendation for moveable type. It's easy to install, Perl, and uses DBM and templates. I've been playing around with it on both FreeBSD and Win32. The code looks reasonably clean.

The roll-your-own route is tempting. I've done that a few times, and have several Wiki clones running in production serving various private communities. It depends on what you want to do. Wiki is a great collaborative tool. It lets the community shape the site. The various blogging tools set the shape of the site in wet concrete. Your site looks much more like a flat weblog.

[FoxtrotUniform]

Unless you've been looking at a cached copy of infernus.net in Google, you probably haven't been looking in the "right" place. :-) For that matter, I mean to do more than just flat weblogging -- music mini-reviews and managing free virtual-domain hosting come to mind; we'll see how far that goes, though.

Right now, I'm tending towards OpenInteract. It looks fairly clean, interface-wise, and does what I want. (I haven't looked much at moveable type, but I have vague issues with their source code license.)

I'd be interested to hear from any Everything hackers; how easy is it to hack the code base?

--
:wq

[dave_aiello]

If your site is news-oriented, I would definitely recommend Slash. It has a reputation for being hard to maintain and modify, but that is largely based on the experience early pioneers had with the code base (yours truly included).

I think that the Slash code base has come a long way since the release of Slash 2.0. The code is a lot cleaner, a viable plugin architecture exists, and web page form is now fairly well separated from content. I wouldn't call the Slash community a critical mass for the purpose of community technical support, but the group is fairly large and growing.

I almost forgot this, but, an O'Reilly book on Slash is coming out in a few weeks. What further endorsement of the platform does one need?

I'd like to single out Krow, aka Brian Aker, for his project leadership, although a number of other people are making significant contributions.

Dave Aiello
Chatham Township Data Corporation

[synistar]

I know this post is a bit old but I just want to note that Slash still has some web standards issues.

However Slash's codebase produces invalid HTML. Here are some threads on Slashdot about this very thing. I would be hesitant to recommend Slash until it cleans up its output. There are other CMS type systems that produce valid markup and are just as functional as Slash (tiki,plone ).

If only they would implement the suggestions made in these articles then Slash would truly rock as a CMS.

[lachoy]

To be honest, if by "content management" you mean pages editable from a browser that can have dynamic, database-generated content, then OpenInteract can be a very good choice. You also get with it for free a very flexible object-relational data system (SPOPS) and user/group management via the browser, to name a couple of things. Best yet, with a little forethought the templates you create in OpenInteract can also be used in slash, since both use the Template Toolkit for this task.

All of the items you've mentioned seem very flexible and expandable. You might also want to add the OpenFrame project, which, while it's at a slightly lower level than the others and doesn't do as much for you, is very nifty and might be the only one of these that can run standalone. (I have plans to do this for OpenInteract, but it's not here yet.)

Chris
M-x auto-bs-mode

[metadoktor]

If the solution that you're looking for doesn't necessarily require Open Source or Perl then you might consider looking at Blogger or Manila.

metadoktor

"The doktor is in."

[nikos]

I use a simple Perl module written by our perl team. And it's based on templates. i.e.

1.template:
===============
<html>
<body>
<p>Title</p>
<content>
The main page of my site is here.
</content>
</body>
===============

You can view your htmls even if you just editting them locally on your computer using your facourite tool for that. It won't look damaged etc. I your script you call it like:

$a=open_template("1.template");
$a->change("content", "2.html");

And text "The main page of my site is here." from 1.template will be changed to content of 2.html. Or you can use dynamically created variables instead of files. If someone is interested, I'll post it. Thanks for listening to me. Maybe it's not about systems you can use for html templates but it's a tiny system that helps to run big sites fast.

[FoxtrotUniform]

Unfortunately, this kind of low-level mucking about is what I'm trying to get away from. I hadn't really considered rolling my own system, as you and thraxil suggest; while it's definitely more satisfying to roll your own tool than to use someone else's, it takes a lot of time, and I'd rather put my hacking time into other things.

--
:wq

[theguvnor]

There are numerous content management systems that various people have written, but I seem to have the Goldilocks problem: there always seems to be something that makes me unwilling or unable to use them - some are too big, some are too small, some require special server configs etc.

So go ahead (if you like) and post - the worst that could happen is I could learn something !!!! :^)

-Guv

[nikos]

He-he. Thanks. I'll do it tomorrow 'cause I have to find it first.

[$code or die]

I lean towards OpenInteract. It has everything you need.

But having said that, I am writing my own. It's mainly an exercise and a chance to play around with with XSL and the like. My motivations are a system that:

• uses templates heavily
• lets me write the page content in a browser in whatever format I want
• uses plugins to display page content (so I can easily extend the system)
• lets me include nodelets (like the ones we have here) in the templates.
I will be releasing the source code once it's tidied up a bit and I have proper user management and permissions implimented. But even when I do release the source, I'll probably still point people to other systems. Have you looked at Axkit? I've not looked at it properly, but I think that it's also an option.


Simon Flack ($code or die)
$,=reverse'"ro_';s,$,\$,;s,$,lc ref sub{},e;$,
=~y'_"' ';eval"die";print $_,lc substr$@,0,3;

[FoxtrotUniform]

Thanks for all the replies.

I'm probably going to go with OpenInteract. Everything and Bricolage look a bit hairy on the editing side, and Slash seems to require a rather non-standard mod_perl config. I prefer Template Toolkit and PostgreSQL to some of the other options. OpenInteract's documentation looks clear and lucid. SPOPS looks useful on its own. OI seems geared to multiple sites going off the same installation, whereas the others seem to assume that there will be only one (virtual?) domain on the server. And finally, if I run into trouble, I can always /msg lachoy right here. I'll update this node (or perhaps post a new one) when I get the new site up and running, so you can all go break test it.

--
:wq

[tune]

Also checkout PHP Nuke. It is fast, efficient, rich in features, and PHP. Not related to Perl, but who said that site engines are the strongest side of Perl?

--
tune

[Hero Zzyzzx]

I cannot recommend PHP Nuke at all. The only reason it's fast is because it's built in PHP. It's efficiency is absolutely terrible! I remember seeing recursive category loops that, rather selecting the entire universe of records in one query and then crunching them in PHP, selected the major categories and then did a query for each and every category, really slamming MySQL with unnecessary traffic.

Look at the code. It's some of the ugliest stuff I've seen. It's also had a few well-known, and major, bugs, including ones that allowed non-authenticated users to upload files with any filename the user wanted. This was well-exploited, trust me (I speak from experience and learned a lesson- never trust other's code. . .).

Steer clear, unless it's changed significantly in the last six months or so.

-Any sufficiently advanced technology is
indistinguishable from doubletalk.

[FoxtrotUniform]

A rather nasty security hole in PHP Nuke was recently posted to BUGTRAQ. Unless you enjoy the "let random strangers execute arbitrary code on your web server" game, I'd stay away from PHP Nuke.

--
:wq

[pmas]

Also, there is wiki technology. Comparing with slash and Everything, users do not own separate postings, but can edit whole page (thread). Rather radical idea, but works well. This allows cleanup after misunderstanding. Also, excellent linking to other pages (each page has meaningfull name, like DeathForDotStar).

Simple wiki you can try free is www.seedwiki.com. IMHO and AFAIK most mature/advanced wiki especially for corporate/intranet use (like for university) is TWiki, http://twiki.org, with lot of advanced features, plugins etc. Is used at university at Rome (ask for link, if interested).

pmas
To make errors is human. But to make million errors per second, you need a computer.

[princepawn]

You will be swimming with the big fish if you use Bricolage...

From: David Wheeler <[e-mail]>
Date: Sat Jan 12, 2002  05:57:16 PM US/Eastern
To: Terrence Brannon <[e-mail]>
Cc: [e-mail]
Subject: Re: [Mason] ANNOUNCE: Bricolage 1.2.0

On Sat, 2002-01-12 at 14:42, Terrence Brannon wrote:
Hi, would you mind listing what corporate production-level 
projects Bricolage is being used in?

Primedia is currently in the process of creating a Bricolage
installation to function as the foundation of their Enterprise-wide CM
+S
needs. It will eventually maintain the content for their 250 magazine
properties. They have been testing it for five months, and actively
contribute to the project.

Salon.com has been using a predecessor to Bricolage -- essentially a
proof of concept -- to manage their entire content base for their onli
+ne
magazine for over a year and a half. Bricolage was developed from the
lessons learned from that project.

The World Health Organization in Geneva is currently evaluating
Bricolage and planning to make it an essential part of their Enterpris
+e
document management infrastructure. They, too, actively contribute to
the project.

For anyone else who might be interested in giving Bricolage a whirl in
their environment, feel free to contact me directly for more
information.

[keymon]

I hate to send out a "me too", but please excuse the newbie... :-)

I am looking for something similar, but along the lines of Yahoo. I'd like to maintain a site with categories, subcategories, etc. etc. where users can "add" sites (and descriptions); but the final decision on whether they get included or not is made by the Admin. Maybe whenever the Admin logs in, s/he is presented with a list of pending additions.

Is there something like this out there in Perl and MySQL ?

Thanks!

[synistar]

Here is a node describing my experiences with several varied CMS systems.

I think that it really depends on what you want from the CMS. If you simply want something to publish articles/pages then there are many to chose from. If you need strong and quick customizability then you may want to look at the Nuke-like systems (Xoops, Drupal). If you need strong workflow controls look for the more capable systems (Plone/Zope, Bricolage). If you need ease of use look for the wysiswyg systems (Mambo, Callisto).

Check out OpenSourceCMS for lots of ready to try out installations of these systems.