Content management systems have been around for more than a decade, but still buyers keep getting caught by surprise as they find expected common and out-of-the-box functionality missing in their chosen Web CMS.
One frequently sought solution is to include everything in the Request-for-Proposal to avoid surprises like this, but as many buyers have learned, this solution rarely works in practice as vendors know their way around this process.
While the usual problems with a young and immature industry remain, here is a list of minimum essential functionality that emerged from a recent meeting in the CMS Expert Group.
Essential features for a modern CMS
- Separation of content and presentation
- Rich text editing
- Without compromising separation of content and presentation
- Multi-delivery to different platforms
- Including mobile and printer-friendly
- Multi-lingual
- At least western European charset / UTF8
- Some way to handle sites in multiple languages
- Broken links checker
- Access control lists
- E.g restricting who can view/edit certain areas
- Automatic handling of change in navigation / site structure
- Automatic content import
- Eg. RSS / XML feeds
- Short, meaningful, friendly URLs
- without file extensions (e.g. .aspx)
- and extremely short URLs
How does your CMS stack up?
Did you find the above list shorter than expected? Feel free to add your additional expectations below. Also, please share if and where your CMS came up short.
Hi Janus,
a very useful summary of the most basic features.
We haven’t got a broken link checker in onion.net though, because there are no (internal) broken links possible (due to the concept of referential integrity). External broken links can be identified by web analytics tools, . Maybe the 5. statement is a bit strict… ;)
Have a great summertime!
Cheers,
Bernd
Overall a good list; however, I’d caveat it with a note that, architecturally, some systems are designed with a minimal base system and lots of extensions. When evaluating a system by the above list, you should look at the full ecosystem, not just the base package. (And, if you’re comparing commercial offerings as well as open source, cost of those extensions.)
I’d add something related to the ability to manage the content status to distinguish what’s published, what’s not. That seems pretty fundamental.
I haven’t seen a broken links checker in Ektron, and only in Plone or WordPress with a plugin. I wouldn’t necessarily have thought of it as a basic component, although there’s obvious value.
I’ve been surprised at the weakness of the Ektron editor, which continues to have a very difficult time handling content pasted in from other sources. Perhaps that should be a subheader under the basic editor function; I think there may be a surprise when someone aquires a CMS and finds they can’t easily move their word processed content into their CMS.
One of the surprises we had with Ektron, which supports both multi-lingual and friendly URLs, is that they don’t work together. If you have a multi-lingual site, and use aliases, users clicking on a page that is in a different language from the default (or cookie’d language) will get a 404 because the system doesn’t automatically change languages. Plone’s multi-lingual support seemed to be limited to “internationalization” rather than creating matching objects in multiple languages. It’s worth digging in to find out, if these basic features are important, how exactly they’re implemented because a bullet point won’t necessarily get into the nasty details!
Another surprise we had was that, although auto-navigation is supported, we were able to implement our site in a way that broke that, requiring all navigation to be manually created. It’s one of our ongoing projects in Ektron to undo that but its a major architectural project.
Link checking should be basic by now; eZ Publish has had it for as long as I can remember.
Larry brings up two important points–architecture and add-ons.
Add-ons/extensions/plug-ins are certainly an important part of any CMS; however, one should be wary about CMS’s which require them for basic functionality, as some popular ones do. The problem comes when trying to upgrade, as one may have to wait until each of the plug-ins employed has a version compatible with the new CMS version, and each plug-in may have a different author, each working on their own timetable. A powerful CMS will have a solid base package.
Architecture is another key topic. Some CMS’s purposes are more limited, and give the developers an easier experience by keeping their work within a box. For example, pages may be broken into blocks or zones, and designers work within that mandatory construct. Other content management systems are actually content management frameworks, with far more flexibility. With these one can expect to be able to start their project from a blank html page (if desired) and build the whole system from there. For the enterprise, it should sport a flexible content model (the ability to define the types of things you’ll be editing, like articles and blog posts–giving you total control). Look for systems which have plug-in systems for datatypes, workflow events, workflow triggers, settings, template operators, etc., and which also offer a full programming API as well as a REST API for use in mobile applications.
While these things may not seem so basic, they exist at such a foundational level in a CMS that if you later fine you need them, it’s very difficult to simply add them on later. And with the great CMS products available today, there’s no reason to do without them.
The main point about your list is surely the choice not to mention publishing workflows.
Almost all our customers, even the ones with very small editor teams ask for some kind of workflow and history function.
Why didn’t you include it in the list? do you have something against it (ie.: many years ago we had customers using staging and production environments for this, but with little success) or do you simply believe it not to be so important?
p.s.: as to the plugin vs. core functionality I fully agree with asking for features in the product, having them in a plugin or via a custom development is surely a second choice in terms of support, integration, compatibility etc….
In response to this quote:
“I fully agree with asking for features in the product, having them in a plugin or via a custom development is surely a second choice in terms of support, integration, compatibility etc.”
That’s simply not true in many cases. Many systems are built as “big program with extensions”, especially proprietary systems. However, many (most?) open source systems take the opposite approach of building a strong foundational core, then encouraging innovation in the extension-space. If you looked at Drupal, Joomla, Symfony2, etc. as just the base core download and nothing else, then yes all would come off as very weak. However, the way they are architected that is by design. The real power is in the extension space, which can evolve faster than the core system, often has just a good a support network around it (commercial and free), and is compatible with an enormous number of other extensions.
If you look at, say, Windows as nothing but the bare OS and the few apps it comes with, well, it’s really a lousy system. :-) It’s the applications for it that make the platform viable. (Sometimes those applications are bundled by distributors, but they are still separate applications.) It’s the same with a CMS platform. The base system is an enabler for a larger ecosystem, and it’s the ecosystem you should be comparing, not just the bare minimum install.
I understand your point Larry, however after some years I’m now thinking to WCM as consolidated products so I don’t expect sustantial innovation in fields like RSS import, rich content editing and so.
Given that I would prefer to have a simple deployment where I pick value-added plugins and the dependency chain is a 1-level structure, so that upgrade path might be easy.
The most common issue I can imagine is multilingual support: when you write an extension (say: mind-maps via tags) you usually expect that as an infrastructure and don’t want to re-write it from scratch. If your WCM does not include multilingual support you’ll have to depend on a plugin, and if there are 3 different plugins then your can choose either:
– to support only 1 of them: that il 2/3 of the installations can’t benefit from your plugin
– to support all 3 of them: that is much more effort and complexity in developing your plugin
Please note that I do absolutely get your point: a solid infrastructure is what makes a WCM a development platform rather then a finished product and a good infrastructure will surely spawn interesting and powerful plugins. Still I think it’s time to draw a line and pick some functions to keep in the core so that innovation is made outside of it.
Sure, there are some features that only work if baked in at a low level. However, that’s not true of all features. Internationalization, you’re probably right. Link checking? As long as the data is structured properly in your data store that’s a trivial add-on. Automated content import? Honestly I’ve never done a content import process that didn’t require some custom code for a specific legacy system, so that probably should *not* have a complete implementation in the base system, just the connection points for it (which could be as simple as a robust data object API). Etc.
Also, if you don’t think there’s any room left for innovation in the web CMS field then you’re not paying attention. ;-) Many platforms are still moving quite rapidly. Even rich content editing is being turned on its head right now with the move from clunky iframe-based pseudo-WYSIWYGs (TinyMCE, CKEditor, etc.) to full page direct editing tools, which is being driven in part by massive-scale collaboration between different open source projects (Midgard, Symfony, Drupal, and TYPO3 are all looking at or already using Aloha and VIE, for instance, as are several others; that sort of collaboration would have been unheard of just 3 years ago.)
There’s still plenty happening in this field. :-)