Content Management Software - Build or Buy?

WallyHartshorn asks: "I'm the web coordinator for an agency (1,200 employees) with a web site consisting of roughly 2,500 static HTML pages, plus a few hundred Acrobat files, a dozen CGI scripts, etc. Currently, updates are done manually by a staff of 2 full-time web developers (including me) and 5 non-IT employees who have web page development as about 25% of their job responsibilities. We have been considering purchasing some web content management software, probably something on the lines of RedDot, eMPower, or Microsoft Content Management Server. We've also been considering using Zope or building something ourselves from the ground up. We only have two Perl programmers and nobody knows Python. Given the current budget limitations, we might have more luck getting permission to spend a few months writing our own software than we would getting approval to spend thousands of dollars on a pre-built package. On the other hand, I could also see a "build from the ground up" project turning into a maintenance nightmare. What experiences have people who run web sites of a comparable size had with building their own web content management software versus purchasing one? (Please keep in mind that we are not running a blog, a news site, or a community site, so something like Slash would not work.) Our content consists primarily of reference material and services.)"

Comments

It only takes one issue to kill you...

[tenman]

I love the idea of a roll your own solutions, but you are right about the cost involved. If you have no experience with a commercial tool, then you shouldn't even try to roll your own. I trusted my code to be in working order, QA tested the product for more than a month before it went production. Soon after they approved it, we lost 7 months worth of historical documentation. The only copy of our web content, was what was sitting on the web server the day my rolled CMS died. I have rewritten the code, but I'll never get a chance to test it. we now use a tool called CCC/Harvest. It's a great tool, but it's also more expencive then free beer.

Commercial content management systems

[fuzzbrain]

The main determinant in your choice shouldn't be cost but finding a system that meets your requirements. In addition to their price, alot of the big commercial content management systems are aimed at big commercial sites. For smaller sites, you're better off writing your own system or using an open source system.

Open Source Content Managment Conference

[fuzzbrain]

I was just doing a quick search and found that there was recently a conference devoted to open source content management systems. A look at the conference agenda points to a number of interesting projects. Wyona and Bitflux sound especially interesting.

Zope

[Big Sean O]

I know, I know. "Nobody knows python". Zope is fairly mature, so you can run it and do a lot without getting under the hood and mucking with the source.

Also, Zope allows you to write scripts in Perl or Python, so you can implement site logic you need in a language you already know. You can also use it to connect to existing databases.

Plus, it wouldn't hurt to learn a little python.

Zope will take out a lot of the busy work of rolling your own and you can concentrate on customizing it.

The Zope Book is on-line and the software is free, so the initial investment is just you time twiddling with it to see if it meets your needs. I looked at it this spring, but it was overkill for the project I was working on.

Re:Zope

[babbage]

I'll second this -- Zope is great stuff. I read a copy of The Zope Book from my friendly neighborhood library (remember those? they're grand... :-) and it's a decent primer on the system for two of the three audience types that'll be using the CMS: those doing presentation (web design, templates, etc), those doing content (source material that gets poured into the templates), and those doing logic (programming and sysadmin stuff). Unfortunately, the original commenter sounds like a programmer, and his is the audience that comes up a bit short in this book. Still, it does a good job of explaining why these jobs should be broken apart and how Zope helps you to bring them back together, and it fleshes out how this is done from several different standpoints.

Still, any shortcomings of the Zope Book detract nothing from the goodness of Zope itself. By default it gives you a nice, featureful web-based management system. "Web-based" can often be a hindrance (complex UI's over the web don't always work very well) but in this case you can get pretty far without having to screw around under the hood, so to speak. One thing to get to terms with is that Zope, written as it is in OO Python, gets to take advantage of a lot of useful, but sometimes confusing, object inheritance trickery. Like for example you can create a user account at a certain level of your site, and inheritance will allow that user's priviliges to cascade down into lower levels of the site but not higher ones. Kind of an obvious feature to want, but the details of how such things get fleshed out are subtle and worth trying to get your head around.

Like the commenter above notes, "it wouldn't hurt to learn a little Python". In many case you can just use Perl, but you may find in the long run that Python feels like a better fit for Zope anyway (seeing as the source code is largely Python in the first place). In any event, the semantic similarities between Python and Perl are much stronger than the semantic *and* syntactic differences you're going to see between Perl and the scripting language offered by most other CMS offerings. And you're actually considering Microsoft CMS? Please.... :-)

There are of course other good comments in this discussion, but this is the only one I see endorsing Zope, and I want to second that notion. If the first wave of dynamic web content was CGI, and the second was mod_perl, then the next one along that track seems to be Zope, which really allows you to work at a *much* higher layer of abstraction (which is of course a good thing, and for the same reason that almost nobody writes web stuff in C or assembler). Zope offers a rich high level toolkit -- object persistance (that you might even prefer to standard DBMS storage, though it's there if you want it), templates (some tending towards "HTML with code", others towards "code with HTML"), a mechanism for distributing your content across multiple servers,security controls, etc. It would take *a lot* of work to reproduce all this functionality in-house, and even if you did it would be hard to guarantee that it was as robust as Zope (or, to be fair, many of the other CMS offerings).

Re:Zope

[platypus]

I second that.
Plus, I would think about getting paid zope consulting to get you of from the ground and continue yourself later on.
Let someone build the hard parts (business logic etc.) and do the easy parts yourself (presentation logic).

Whatever sales droids of proprietary content management system may tell you, they don't work out of the box - at least not more than zope does.
You'll always find things which don't work the way you want them to, making custumization needed, like adaption to your business' processes or whatever.
In reality, many of the important CM makers make most of their money by consulting etc.
Take a look at zopes content management framework which is an add-on more tailored to typical content management use cases - oh, and ignore the ugly side, something new is in the works.

It all comes down to:
$total_cost = $cost_of_license + $cost_of_consulting + $cost_of_own_time

With zope, $cost_of_license == 0 at least, and I guarantee that zope gives a very good start to get the others quite low.

Roll your own...sorta

[galaxy300]

I just went through the exact same decision process and we decided to go with a custom solution. We were going to pay to have one of the big packages customized anyway, so in terms of cost it was a wash. By building our own, we were able to control costs more closely and only implement the features that were most useful in the 1.0. We ended up selecting a developer who already had a library of customizable tools, so we don't pay the full development costs up front and the best thing? The source code is provided to us at the end of the project.

Content management is a bear pit....

[PinglePongle]

I was the development manager for a big site using Vignette as a content management system. What they don't tell you when you buy these products is that you will inevitably invest a huge amount of time in customizing the application for your requirements, and that - at the end - it will still not feel "quite right".

Besides the purchase price, you have to assume you will need signifant training and/or consulting support, and you will inevitably end up rebuilding your site from scratch to fit into the new framework. The standard consulting fee seems to be roughly 10 times the cost of the software (amazing how that always seems to work out...).

If your content creation processes are in any way complex, you will spend a significant amount of time and effort trying to create a tool that facilitates or at least accomodates this process; if workflow features are expected, you will have a serious amount of work to tackle.

You will also need data entry time (or at least the ability to convert all the exising content into whatever format the Content Management Server expects) for all 2500+ pages.

If what you're doing can be classified as business critical in any way, you will need at least one administrator for the Content Management System and whatever database it uses.

Because content management systems involve a lot of "dynamic" activity when serving pages, it's common for them to experience performance problems, so you may need to invest in additional hardware to serve the same number of pages. You will definitely be looking at how to cache your content - this is a whole bundle of joy in its own right.

In short - make sure you want to go down this route ! It may free you up from the tedium of cutting and pasting into a static HTML file and FTP-ing it, but instead you'll be feeding and watering this content management beast.

Unless your company makes its living from its content, the costs are unlikely to be recouped.

Of course, if you want to do it, I would suggest writing one from scratch; I'm working on a JSP/servlet based content management server right now, and it's a lot of fun.

N

Perl solutions

[m_ilya]

Since you have programmers who know Perl it makes sense to go with Perl solutions. I don't know your needs so I'll give your several choises.

• Bricolage
• Everything
• TWiki

Re:Perl solutions

[mbadolato]

You left out Mason, which could very well be a solution for the OP.

Re:Perl solutions

[m_ilya]

Well, Mason could be used to implement content managment system but it is no content managment system itself. What I have listed *are* content managment systems.

BTW Bricolage is build using Mason.

Who is your authoring audience?

[dmorin]

There are at least two major reasons to use content publishing -- either it's just a convenience for the developers who otherwise would know how to fire up emacs, hack some HTML, and then ftp it to the server...or else you have an audience of content authors who, even if they do know how to ftp files, probably shouldn't, because it'll be IT's job to fix it when the process screws up.

If your case is the former, then you likely fall under the "scratch your own itch" category and could seriously benefit from rolling your own, because you likely know exactly what you need.

However, if you fall into the latter category, then I suggest looking at what's already out there, because odds are you're not going to be able to simulate all of the tools that your users want. For example:

• have you considered workflow? In many places content needs to go from an author through an approval manager, through compliance, before getting out to production, and you'll need a workflow management system to handle that.
• How about virtual documents? In most instances you'll find that your author has changed a dozen or so items and wants to make sure that they all get rev'd and workflowed as one big unit.
• Will you be integrating with existing editors like Dreamweaver? What about ftp, will your authors be able to ftp large amounts of content into your system?
• How will your alert mechanism work? When something has been pushed through to my area of approval in the workflow, can I get an email that tells me I need to do some sort of action? Can I perform that action simply by replying to the email?
• Something bad went out to the front page - a news story that turns out to be wrong. What's your rollback procedure?
• Speaking of which, how about backups? You can't take the docbase down for hours a day to do a backup, but you always need a full backup available because you'll have authors cranking out new content faster than you could imagine. How do you plan to solve that little dilemma?
• Do you have an object model and metadata strategy in mind? Will everything be just 'file' or 'page' or 'image'? Or can your authors create an object of type 'news story', which has attributes for 'headline', 'date', and so on?
• Oh, and don't forget drag and drop.
• And security. Group X can edit files of type Y in folder Z, but group Y can edit files only of type Z in folder Q.

Get my point? I've been tech leading an ecommerce team for about 4 years now using Documentum as the content management system for over a dozen production sites. Everything I mentioned above has been a question or issue at one time or another. I highly doubt you're in a position to buy one of the commercial packages, since all of them cost an absolute fortune (Documentum, Interwoven, Vignette to name a few). If you hadn't even considered most of the issues that I just put up there, then perhaps you should at least look at some of the better existing systems, because they most likely have, and when it turns out that you do need feature X, it's already there.

Re:Who is your authoring audience?

[4of12]

Somebody mod up dmorin.

Re:Who is your authoring audience?

[Linux_ho]

He's considering "rolling his own" with Zope, not from scratch. Zope already has most of these features - workflow, security, alerts, etc. as well as a large assortment of community-contributed modules.

General notes

[texchanchan]

- Whenever possible, use an off-the-shelf product, and a mature one if available. Advantages: It has evolved, and there's a community of users out there to help you via forums, mailing lists, and so on.

- Looks like you've got a total of 3.25 virtual people maintaining about 1000 pages apiece. I worked on a project of roughly this order of magnitude by myself, and it nearly did me in.

- When content contributors do their own page production and uploading, standards can go out the door. Basically, you have to control their access severely. This has always been true. I've seen camera-ready copy that an engineer has run through his typewriter to "correct"--at NASA no less.

- Don't forget low-tech alternatives: for instance, photocopied forms which your content generator co-workers fill out and pass to you. Since your site consists largely of reference material, the pages are probably pretty standard and tabular. Whether this would work depends on factors like the number of pages/week that need updating.

- Mid-tech: set up some strictly controlled forms in Word on a server, used the same way as photocopies, only you can generate the HTML straight from Word (then use another program to clean it up, of course--Dreamweaver does this, among others). That might be a function for your Perl programmers--let the employees "Save As HTML Document," and upload. Then you run everything in the upload directory through a de-Wordjunk script periodically before it goes live. You would have to look over the results, but then no program no matter how expensive removes the need for quality control.

- I hope you're already using style sheets :)

- It all depends on how many people need to modify page content and how often.

Zope use can be simplified even more.

[Domini]

I would suggest looking at Boa constructor as a tool to manage Zope sites. It has "Sophisticated Zope object editing integration" made simple.

Give it a try! It also has superb debugging capabilities...

Screenshots of Zope editing...

[Domini]

Here and here are some screenshots of the Zope editing capabilities of an older version of Boa-constructor.

cost of software + customization + training = $$$$

[kootch]

add the title up and you're probably spending 2 to 5 times more than you initially thought. and for what? a program/system that was modified to try to accomodate your needs.

what would be much more cost effective would be to sit down with a dev house (such as mine), determine a project scope, and roll your own open source solution.

why:
1. the cost will be less than the package you buy such as RedDot (which is awful, lemme tell you
2. it'll fit your needs better since it was designed for your needs
3. the code will be available for you to tweak down the road if necessary
4. there will be less training time and installation time required
5. you will have a company to call on for assistance or thousands of programmers available that could modify the system (since it is open source)

Why not roll your own?

[texchanchan]

Because unless you personally do it yourself you'd have to be riding herd on a programmer or a team of programmers as well as 3000 web files and a company full of content producers.

You'd have to make them:

- Write something with the features YOU want and not the features they think would be a good idea.

- Stick to a deadline.

- Design an interface that your content contributors find intuitive, navigable, and non-ambiguous--unless you want to go into the training business too.

It would be worth several tens of thousands of dollars not to have to do this.

Disclaimer: I like programmers. I respect programmers. I enjoy working with programmers. But I don't have illusions about it being easy.

Get the best of both worlds

[Evan]

Hire Zope Corp. to build your CMS for you. That way, all of your money gets spent on training and development rather than licenses, and you end up with a completely Free solution that you can extend and maintain yourselves.

I'm surprised at how little attention Zope Corp. gets when people are discussing Open Source business models. They've gotten fantastic growth and exposure, to the point where they are regularly beating the likes of Vignette for contracts, by Freeing their core software. While they do sell support, that's not their primary source of revenue. They make money by building web systems and CMS applications using Zope. The fact that Zope is free (both ways) is a powerful selling point when used correctly, coupled with the fact that the engineers at Zope Corp. are naturally the most experienced Zope developers around.

(disclaimer: I worked for Zope Corp since back when they were Digital Creations. Great folks!)

Avoid Zope and especially Squishdot

[David Gerard]

We use Squishdot on Rocknerd. It is full of wonderful features and falls over in a stiff breeze. We're at the stage where we're running it single-threaded with an auto-restart thing for when it crashes. Last crash, it corrupted the entire database and we lost two days.

We're currently trying Slash. It's horrible in its own ways, but if we can make it a bit less ugly then at least it'll generally stay up.

Squishdot and Zope: JUST SAY NO.

Re:Avoid Zope and especially Squishdot

[David Gerard]

If you're unhappy with Zope/Squishdot you should try Postnuke [postnuke.com] rather than slash. It's a real CMS, offers theming, internationalization, dozens of external modules for you to expand your site.

Features? We don't care about features. We care now about stability, and ability to recover from disasters. Slash is the stuff that runs Slashdot, so it should cope just fine with our load. Other strong contender was Scoop, but that hasn't got a stable branch yet.

This is production machinery. Features are candy :-)

Re:Avoid Zope and especially Squishdot

[David Gerard]

Nope - Linux and Apache. Apparently the bad interaction with Apache is documented, but the fixes didn't work.

In a perfect world, we probably could have done something else. But in this one, Squishdot is a POS and something more robust is called for.

Re:Avoid Zope and especially Squishdot

[frankie]

Neither Squishdot nor Slash meet this guy's needs. He specifically said it's not a community/news site, it's 99% static pages of long-term informational content.

I'm really glad this topic came up, because my site needs the exact same thing. Zope CMF sounds promising, if it can output static html.

We rolled our own...

[Richard_at_work]

The company i work for had a huge problem with information being lost, and a long standing solution to this was the development of a company intranet.
Now we have a intranet that can handle almost anything you can throw at it, pdfs, word docs, excel files. The best thing is, its all due to the "bad" integration between office and IE. choose to view a word doc and it opens a word session inside IE.
The actual intranet is nothing more than a PHP/mysql website on a small piii box. Took a month or so to develop and everyone is happy with it.
As for being a maintenace nightmare? not really, its all documented, has its own api due to being OO coded, and not a lot needs changing anyway. Besides its a modular syste, cant work out howa page works, but know what it does? then replace the page.

ThreeRing Monument

[zpengo]

Monument by ThreeRing is a soon-to-be-released CMS built on the .NET framework. This gives it MS compatibility (as well as web service functionality if you need to interact with other platforms), but here's the hook: It's an open-source project. All the source code, for binaries, scripts, etc., is provided when it is purchased.

They also have a smaller application called Torpedo (also open-source .NET) which is suitable for weblogs, small business sites, etc.

Kinds of content management

[fm6]

When we're talking about content managment, let's talk about the kind of contents management. Even web content management, which is what where talking about here, is far from monolithic. Besides which, there's also publications content management, support content management, enterprise content management... Slashdot itself is a kind of content management system.

This is important for a couple of reasons. One is the obvious one: different CMS applications have different needs. But conversely, they also share needs. Which is why you shouldn't limit your research to specialized web CMS solutions. There are generalized CMS platforms that can be easily to web applications, and might be good compromise between off-the-shelf and roll-your-own solutions. Also a good choice when there is no off-the-shelf solution for a particular CMS problem, which is often the case. Documentum is the leading vendor of these, but it has many competitors.

cvs?

[zenyu]

I know this sounds really simple, maybe I'm not getting something. But I've helped set up a couple websites with just CVS and a few scripts to update the content. It works for scripted stuff and static pages just fine. It wouldn't be so good for a news site, but it sounds like just what you need. Plus it's simple for anyone with unix experience to set permissions and stuff so that people don't go updating things they shouldn't. We didn't even need perl, just plain old shell scripting.

openACS

[tapiwa]

This thread has quickly become a shameless plug for everyone and their dog who is involved with a CMS. Still, I will throw in my £0.02 worth.

Look at openACS. Its a fast evolving toolkit, with a lot of features out of the box. The current project website is not the best looking, but the toolkit has been used to develop a lot of interesting sites.

Methodology
If I were you, I would stay away from the Vignettes and other off-the-shelf CMSs. To paraphrase Phil Greenspun, these guys pricing works along the lines of ... shake the customer by his feet and see how much money falls out, then charge another $50 000k for support.

I would also not be in a rush to implement a totally custom solution. Building from scratch is usually a dumb idea(tm). No point in reinventing the wheel. Having said that there is a slight difference between a Michelin-clad Ferrari wheel and a 0BC Roman chariot's wheel...

I agree with you, do not go for the slashdot look. That virtually rules out most of the nukes (phpnuke, postnuke, drupal, slashcode etc). It is

so boring

so overused

suitable for weblogs and news sites but not for more mainstream content sites.

oss is good
The beauty of using OSS toolkits is that you get a head start. If any consultant (read salesman) tells you that their product fits your needs perfectly, then a. shoot them, b. chop them into little pieces c.feed them to the snakes d. shoot the snake ..... just for good measure.

The best that you can hope for is to have a basic and solid foundation that you can build on.

decisions
Some of the things to look for include the following:

• ability to handle workflow.
• ability to deal with permissions
• ability to deal with authentication
• ability to handle more than just plain text
• ability to version ... rollbacks ... track changes
• ability to handle templates, ... proper templates, not just color changes.
• level of developer support
• level of developer competence
• pace of changes

For each toolkit, look at sites that have implemented it. If they *all* look the same, steer clear. Its a sure sign that templating was poorly implemented, or that the toolkit is difficult to customise.

Post a couple of questions on the boards. If the tone is friendly, then you know that if you did pay these guys to do work for you, the service would be great.

If you are building a proper CMS, its going to be painful.

and you win an all expenses paid tour of some of the sites built using openACS and its cousin ACS classic.

• Grand Expeditions
• Wine Access
• photo.net
• Stirling Engines
• Online Ireland and more here
• Away
• Sherman power sports
• Net effect

Zope Community?

[crisco]

Have you tried the Zope community for help?

I've found the mailing list and #Zope on the Openprojects.net irc servers invaluable for solving problems with Zope. Remember the Zope Corporation and other have used Zope for high profile projects such as CBS New York.

As far as the article topic, Zope has the CMF project which might give a good headstart on what they are after.

Aha, I see other threads are pimping Zope and the CMF so I'll leave it at this...

CMS-list

[crisco]

The cms-list might be a great place to do some further research. The mailing list archives are online and provide a decent resource of questions, observations and general flamage regarding CMS.

Re:Documentum

[MartinB]

Documentum is the leading vendor of these, but it has many competitors.

Not sure about it being the leading vendor - for a document-centric, hard-core integrated with paper system, perhaps it can be. It's certainly there in the top right of the Gartner magic quadrant. But for a web-based system which isn't too worried about paper, it's not the first thing I'd choose, even if I were going for a tier-1 solution.

Tools costing a fortune

[MartinB]

I highly doubt you're in a position to buy one of the commercial packages, since all of them cost an absolute fortune (Documentum, Interwoven, Vignette to name a few)

You're right, those 3 do cost a lot. Each of them will cost maybe US$300k in licenses for a first time customer, plus 50-350 man-days development time for a complex system.

But it's worth noting that since Microsoft came into the market, enterprise CMS prices have been sharply dropping. Those vendors used to charge $500k+ for a first time customer...

If you want to go below the Vignette/Documentum/Interwoven troika, take a look at:

• divine (used to be OpenMarket) - costs about $200k licenses plus about 500 mandays implementation for a complex system
• Stellent - costs about $200k licenses plus about 500 mandays implementation for a complex system
• Microsoft CMS (bought from NCompass and made to work with MS stuff only) - costs about the same as divine for licenses, including all the other MS kit you need to buy to get it to do anything useful, but is about 600 man days of development. You will need an all-Microsoft environment to get the best out of it.

Re:Don't use PHPNuke or derivatives!

[cr@ckwhore]

I agree! The latest version of PostNuke is very different than the earlier versions, specifically after forking from PHPNuke.

I don't recommend PHPNuke, for the very reasons expressed in the parent post.

I've been using PostNuke for almost 1 year now. I started with the .6 series. It truly is shaping up to become a top notch open source CMS, with a strong vision of the future and a roadmap for getting there.

Honestly, PostNuke really shouldn't be considered among the *nuke derivitives any longer, because its now very different and will only further set itself apart in the future.

Documentum?

[Black Perl]

Documentum is the leading vendor of Document Managment solutions. Document Managment is NOT the same thing as Content Management. While Documentum recently branched into the CMS space, it has very few customers that have purchased the system specifically for Content Management.

I believe the leading vendor in the CMS space is Interwoven.

Content != Documents?!!!

[fm6]

I realize that many documents are content-free, but I didn't know the trend had been formalized! ;)

You throw out a distinction between "content" and "documents" as if it's perfectly obvious. I'm afraid I don't see it. And I've never seen the distinction drawn in technical or marketing literature -- of which I've been reading rather a lot lately.

Are you drawing a distinction between big thick highly-structured printed manuals and loosely-organized web sites? Documentum can be used with either. I don't know if it's the best platform for most web site apps, but it is widely used as such.

Perhaps you're thinking that Documentum just doesn't count as a Web CMS because that's not what it originally designed for. Well, a lot of CMSs didn't originally target web content -- most of them predate the web!

There is a certain tendency to emphasize web CMS over other CMS application, even for products that originally targeted traditional CMS apps. Not suprising, since that's where the big customers are. But it makes life just a little difficult if you're hoping to find an off-the-shelf CMS for a simple technical publications process.

Another vote for roll-your-own

[Black Perl]

I'm the lead architect for a federal agency's website. We have nearly 40K pages. We have pretty extensive requirements, and therefore researched a large number of commercial CMS products. We purchased one in the six figures, and we're sorry we did. I've come to the realization that most CMS systems are really toolkits and extensive consulting is needed to get them to do what you want. And the more changes you make, the more it becomes a custom system. Our consultants had to rewrite several parts of it to suit our needs, rendering some of the built-in features useless, and making future upgrades a major pain. In the end, it never worked as specified in their Statement of Work and we are pursuing our legal and financial options.

We've decided that the best thing to do is roll your own. Not to write a CMS from scratch, but rather to perform a tactical application of best-of-breed Open Source products (perhaps some inexpensive commercial ones where necessary) in a componentized fashion, using a database as the central hub for data and state information.

We're not the only ones in this predicament. Evidently this is quite common. See this recent press release from Jupiter Research, an internet industry analysis firm. Here's one interesting quote from the article:

Although just under one-third (31 percent) of companies surveyed have developed homegrown content management systems, Jupiter analysts expect the number potentially to double by 2004 as companies recover from - and react to - expensive, failed systems.

No, it's just Vignette...

[aquarian]

Content management can indeed be a bear pit, but so can anything else. The problems you've had are familiar- mostly to users of Vignette. Frankly, it's a badly designed, bloated, buggy piece of shit. The only thing it ever had going for it was marketing dollars- someone decided they could be the Peoplesoft of content management, and they just about succeeded- except for the product, which sucks. You'd have better luck with just about anything else. Sorry you got sucked in. It happened to a lot of good folks.

I'm an aD/OpenACS guy myself.

HTML::Mason

[splorf]

You said you have perl programmers so you might want to look at Mason. I don't know if it does what you need but I haven't seen anyone mention it yet, so check it out.