SuperSatellite ||

After about a year, I am kicking Drupal to the curb.  I fully recognize it is a robust, capable CMS (Content Management System).  So are a lot of other systems.  But it’s just not fitting me well.  Sometimes I think CMS usage is as much about tastes as it is strict functionality (actually, I’m sure of it).  Sure, a sweater might be warm, but if it’s ugly (with a big clown on the front), you might wear something a little lighter for the sake of having something more appealing (and less clowny).  That’s where I am at.  I’m tired of clowns and sweaters.

I originally adopted Drupal to run Penpedia when I launched the site for a few reasons.  One, about that time I had started getting into Drupal just through the course of investigating different CMS’s.  I did like that user accounts could have their fields customized.  And I found a module that allowed for hand in hand single sign on authentication with the other half of the site, which ran MediaWiki.  That also made it appealing.  The longer I used it though, the more the rough edges started showing.

First, I didn’t want to start writing templates for a new system.  This is in part because I already know how to template other systems like WordPress, e107, dotCMS, and a couple others.  As a result, I start losing patience for learning others.  Not a huge deal, because theming Drupal isn’t terribly hard, it was just that I didn’t want to.  The theme I ultimately grabbed was only marginal, but I just never got motivated to write a custom one.  And frankly, I’m a little ashamed of that, because the design of the site is not indicative of my abilities.  But what did drive me nuts was the lack of any WYSIWYG editor built in.  And the module that enabled the feature was disgustingly complicated, and caused a lot of clashing with the code stripper.  The added steps of permissions and profiles for it to work right was just way beyond necessary.  Which leads me to the next thing.  The permission system didn’t please me.  It didn’t work how I’d expect, and seemed far to complicated for what it was doing.  That’s what I love about dotCMS, you can’t beat their permissioning system.  Doing complex, and sometimes even more routine, tasks in the back end of Drupal generally felt like a power struggle between me and the code, and I loathed the idea of having to go in and tweak anything.  And just to round it out, I’ve never liked the “node” concept.

But, just to remain clear, if it works for you, then great.  It just hasn’t meshed well with me, and has actually discouraged me from developing the site better.  That’s why I plan on changing things over there to Wordpress later this week.  The MediaWiki portion will remain unchanged, though there might be some tweaks to login stuff, as I am investigating what needs to happen to maintain single sign on with the two.  Plus, between here and there, I’ll only have one software package that I’ll need to worry about now, as opposed to two, which should encourage more development and activity on my part on the Penpedia site.  I think this will be a move all for the better, and it should benefit the site well.

The moral of the story?  There is a lot of value to standardizing on a CMS, and sticking with what you know.  Even if a system isn’t perfect, if you are familiar with it and know its capabilities, I think that beats out picking a robust system that just doesn’t click for you.

I felt it was time to take a closer look at a content management system I am getting very involved with. One might say I’m drowning in it. I prefer to think of it as being choked by it, heh. Really, it’s a very interesting system, and a fantastic tool for the price (free!). I have worked with a number of CMS (Content Management System)’s over the years: Coranto, e107, Joomla, Mambo, Wordpress, Drupal, and a few others that I’m sure I’ve forgotten about. It’s easy to get locked into one or two for various purposes, which had been true with me for a long time. The problem is, my short list there is only good for small to mid range sites. Now I’m webmaster for a site of better than 10,000 pages and 70+ editors. Those open source solutions don’t easily or always comfortably scale up to those needs.

That’s where enterprise grade content management comes into play. Swinging big price tags, naturally. You start learning names like RedDot, OmniUpdate, Hannon Hill Cascade Server, Serena Collage (discontinued), and Ektron cms400.net. You also learn they don’t come cheap, some breaking the $80,000 mark. $15,000 in this group is cheap. In some cases, you don’t even have to host it. But the support, features, and scalability you get from this class of tools is in a different league. Wouldn’t it be nice if you could get the best of both worlds though? Something like a Typo3 or Zope/Plone system, but with enterprise grade support and a learning curve within reach of your users? A tool that was open source to boot? Generally there just isn’t demand for this sort of software, at least not enough to make a successful project, it’s enterprise grade and enterprise cost because it’s an enterprise market. However dotMarketing has stepped up to the plate. They have developed dotCMS to augment their design and consulting business, but released it free, charging only for support.

I need to be fair though. dotMarketing really stood on the shoulders of the work done at the Liferay Portal project, that’s where it started. Liferay is the underlying framework that drives dotCMS, written in Java, and running on top of Apache Tomcat. But they forked the project and went a long way towards customizing everything you see and interact with. It isn’t just a fancy admin theme dropped over someone else’s work. It is also tied together intimately with Apache Velocity, which is very slick for writing dynamic templates. Needless to say, this isn’t a simple one-off , self contained type of application. It’s build on several different technologies, all open source, to try and provide the best of each tool to the end user. When you download it, everything is packaged up that you need though, you don’t have to hunt anything down separately.

This does make it more complex than other open source CMS options. Systems like Wordpress or Drupal can be installed to any server that runs PHP and a flavor of database server. On the other hand, dotCMS requires you to have root access to the server to install things like the Apache Tomcat server. This requirement has hurt dotCMS’s market penetration, as many web site owners do not have that kind of server access, opting instead for cheaper hosting solutions. That is a shame, because dotCMS is easily one of the most powerful open source options available, with a much shallower learning curve than equally flexible solutions (I’m looking at you Typo3). It’s also pretty resource intensive, so you won’t be dropping this onto a lightweight web server you built five years ago on an old AMD K6-2 system you had lying around. Plan on needed a couple gigs of RAM and a modern processor to heft it. You can run it in a dev environment in a PC okay, but not with less than a gig of RAM (I know, I tried, I failed). It might be open source, but it is truly enterprise grade, and is built for an environment that reflects such.

Part of what makes dotCMS so good is the way they approach content. As an administrator, you can create structures. These structures result in a form-like input system, that allows you to pull out some or all data for a type (say, a news posting, or product review). Any structure can easily be attached to an RSS feed. Each structure is unique, but can be dynamically related to one or other other types of content in other structures. For instance, you have a structure for “blog posts” and one for “comments,” and the comments can be related to blog posts. But you could also relate certain comments to articles, or news postings as well. This is a basic CMS feature used in most systems, but with dotCMS you see exactly how it works, and can modify or expand it. Better yet, create your own. Players related to teams related to sports. The flexibility allows you to develop to your heart’s content. And you don’t have to be a programmer to do it. Admittedly, relationships aren’t super easy to understand out of the gates, but an example or two gets you going. They really got things right with regards to how content should be created and used, and did a good job taking the cork out of the bottle for the end user to go nuts with it.

Speaking of examples, they do have a complete demo site running that allows you to both test things, and also see how certain things are accomplished. This can be very useful if you want to duplicate some kind of functionality, but need an example. They also outline plenty of macros that allow you to easily accomplish common tasks, like creating slideshows, navigation, MP3 players, RSS feeds, and more. One thing their demo site doesn’t showcase is that it can even run multiple domains through one back end, so you could be running demo.site.com, and blogs.site.com, and www.site2.com all through that one instance of dotCMS.

If you would have asked me before, I probably would have said that Drupal or Typo3 had the best permissioning systems available in open source. That’s no longer even remotely true. dotCMS has a fantastic permissioning system that allows granular access to both content and admin areas. Groups are used to define what a user has access to at the back end, while roles determine what they can use, see, and access with respect to content. This combines with a workflow system that can be used to make sure content is properly reviewed and approved before it hits the page. It’s simple, and it works. Well. On the user side, you can easily tie into an LDAP or Active Directory environment, though it requires manual set up. Users can be tracked through the system to provide some basic analytical data, and attached to CRM functionality to label, organize, and communicate with them. This goes far beyond any other competitive product in open source.

Where it’s lacking: documentation. Right now, it’s pretty scattered and different documents can be out of sync with others. I understand this is changing, and that they are moving to a system a la Apache’s documentation method. It is definitely needed. Luckily, their mailing list is pretty active, and they tend to be responsive on bug reports. I think it would be nice to see a little more stuff built in by default. For instance, dotCMS can be a blog, or host them, but you have to build the structures and relationships yourself. Tools like that are common enough that it wouldn’t hurt to just have it already set up. There is also no file structure, in the normal web sense, so no FTP (File Transfer Protocol) type functionality, you have to upload through the system or via WebDav, if your server supports it.

I will be at the dotCMS Open Minds Conference next week in Miami. After that (and maybe even during), I’ll be following up with some more detailed information regarding their CMS. I’ll get a bit more into how certain things actually work, and what we’re doing to make it work to our advantage. In the mean time, their portfolio can give you an idea of what the system is capable of.

Update (08.04.21): If you are looking for additional support, be sure to either check out the dotCMS mailing list, or visit our newly established forum community. Also, expect new and improved documentation and support tools from the dotCMS development team around the 3Q of 2008.

What follows is a slightly re-edited (for clarity) version of my thoughts on using Adobe Contribute to run a site. It was originally posted to the uwebd mailing list during a discussion of different CMS (Content Management System) options that are out there. This was in response to a question directed to me regarding what I considered a “modern website” with respect to Adobe Contribute.

Why isn’t Contribute equipped to handle large scale (~10,000+ pages) sites? Contribute doesn’t really have the tools to do anything with regards to content reuse across a site. So as a result, there’s no way to develop interactivity (well, really, you can’t develop anything with it, it’s not a developer tool). You can also forget about getting fancy by integrating things like RSS feeds, or dynamic content in any useful ways (consider, Department X wants a list of their courses for the semester, if they are copy/pasting, there’s no way to control that content once they have plugged it in, which hurts when they totally forget about it the next semester). Contribute is best at static content, on static pages. One page at a time. The newest version (CS3) has done marginally better, in that you can at least paste HTML source code now, but the actual audience that Contribute is aimed at won’t really find that useful. If they knew and understood HTML well, they’d be using Dreamweaver, or at least NVU or something. The crazy part is how good it looks on paper, that idea of simple content management. The reality isn’t that good, especially for developers who must then deal with all the deadwood Contribute leaves behind as things get updated, removed, etc (which is substantial). And don’t forget any template changes you have to make, which would have to be filtered into every file, which is very time consuming (we use SSI (Server Side Include) templates to help stave that issue off, but then that has also caused certain bugs preventing people from creating things like bulleted lists. Craziest thing I’ve ever seen).

I am of the mindset that Contribute has lost its market. It was a good tool five years ago. The game has changed a lot in that time though. A good CMS does everything that Contribute can do with no more of an end-user learning curve, but with the added bonus of being flexible for use with the better power users you serve. Contribute doesn’t have any room to scale up that way. Power users get frustrated in it, and basic users just get lost. The key is that a basic user is a basic user. Period. No matter how simple the software seems on paper, you still have to train them before they can use it, so you might as well give them a tool that not only does things easily, but does them right. For instance, workflow is a joke with Contribute, and as a result page management becomes nearly impossible (and in turn confusing for basic users). There is no review mechanism at all, so content can quickly become outdated and never addressed down the road. We have departments that have copied information from other parts of the site that is out of date by years. This is because they haven’t had the tools to do it correctly in the past.

Like I said, Contribute is designed to do one thing very well, edit static content on static pages. If that is all you want, go nuts, but try anything beyond that and it’s just a bad tool for the job. And in today’s web, a “modern site” is one that generally does not rely on static content this way.  Moreover, a “modern site” is one that also provides current, accurate, fresh data. If you have no ability to keep up on your content in some way, you are setting yourself up for failure. Anyone managing a large site knows that you can’t rely on the editors to simply take it upon themselves to review content (assuming that’s not their primary job).  People rely on web sites now, it’s one of their first stops when they want information on something. If they lose faith in the site as a tool to retrieve accurate information on the subject they want, then you lose a customer. The crazy, lock-me-up-I’m-going-cuckoo goal of a “modern website” is therefore to be omniscient in regards to their audience. You must have a current and correct answer to every question your visitors can and will ask. Totally impossible, I know, but it’s what the audience expects, and there are a lot of ways we can certainly fake it with current web technologies. I don’t feel Contribute is up to that kind of job (not by a long shot).

(Caveat: this is all based on my personal experience in our environment with ~70 Contribute users. We do not run the Contribute Publishing Server.  No doubt others might have more positive opinions.)