Home arrow Compare CMS - 2
Compare CMS - Part 2 - Types of CMS

Compare CMS - Types of CMS

On this page, in CMS Features Part 2:

CMS features

Types of CMS

What is the most popular CMS type?
MS server CMS

Flat-file CMS
Other CMS types
Testing your proposed CMS
CMS types and features
The choice: OSS or commercial CMS
Example of a successful CMS

Page 2a follows with:

Text or compiled code
Web Standards
The first checks to make
Bad CMS faults
Servers for CMS
Alternative server applications
CMS LAN servers
Server security for CMS
CMS server round-up

Page 2b follows with:

Databases for CMS
Client-side CMS
Ecommerce on CMS
CMS Documentation
CMS templates
Template types
Other important CMS features
First steps with a new CMS

CMS Feature Checks

Now we need to look at some of the most important features you should be looking for with your prospective CMS. There are so many to consider that it is extremely confusing for a newcomer to this area; we will try to simplify it and point you in the right direction.

The unspoken factor in the following reviews is SEO for CMS, and this refers here almost entirely to quality measurements. It's because we start and finish with that, since if you run a commercial website it should be your #1 priority. That being the case, all the applications listed here are either OK on that score, through absolutely excellent - or we wouldn't list them. We can't list all the applications that are of good quality (or suitable for a particular purpose) as there are just too many - there are probably over 3,000 WCMS now.

Again, it's necessary to clearly state our standpoint as this varies for all reviewers. We believe that application quality and admin usability are the two most important factors. We measure quality in a very simple way - it's the same thing as being SEO-friendly. This is because SEO should be a quality improvement process; ideally it has little or nothing to do with irrelevant factors such as page rank or marketing hype of various kinds. Unfortunately SEO has been hijacked by spammers and unfortunately no longer seems to be about simply improving a website, ensuring it complies with legal requirements, and making it visible, which is our method.

The simple fact is that search engines like high-quality sites. If you don't believe this - or if you don't have a commercial site that needs to succeed - then most of the information on these pages has no relevance for you.

SEO / quality issues are the hardest of all for developers to comprehend. To explain this it's best to look at examples where the devs have succeeded in producing a quality product after countless thousands of hours of toil. Two good examples are Plone and Redant Colony, which have super-high standards of code quality and accessibility. All you need to do is compare other offerings to these and ask, "The developers of XXX CMS say that quality of this type is not necessary. Who should I believe?" One of those is free, one is mid-range commercial, so this level of achievement is possible, of course, in both open-source and commercial.

It's true that it may depend on what you want to do with your CMS - if you have no commercial aspirations, then perhaps these issues may not matter. Otherwise, you need to look at the direction high-quality web applications - and laws in many countries of course - are heading in. It is also absolutely true that it may not be practical to use such an application, as hosting costs or license costs may be beyond you. Everything in life is a compromise, which is why we look at many alternatives.

Up to around 2005, no developer seems to have heard of search engines, so there are some old-style CMS out there that will never compete in the modern world. This includes otherwise-competent CMS types using pagecode outputs that are in effect handicapped in the modern era - JavaScript pages of the .jsp page extension format for instance.

Types of CMS

Firstly, you will need to choose a CMS type for trialling. This choice is most likely to be budget-based; followed by the main feature requirements as described on the following pages. Depending on your budget you will be looking at large commercial CMS, small commercial CMS, semi-commercial CMS (often with an OSS core and commercial extensions), or open-source software (OSS). Many enterprises, though, choose OSS even though they can afford commercial CMS; this is because there is no quality difference between the best-known software in either class, only support options - which may be more restricted with OSS.

Open-source means free software with published code that is free of licensing restrictions. It is very strong in this market area because of the complexity of the software, and the popularity of these large and complex code projects with developers (which is the most popular term now for software authors, programmers, coders). Distributed authoring has proved eminently successful here, with highly-competent developers joining, contributing and leaving projects as time and inclination suits. This development model has produced some of the most popular, efficient and effective software on the Internet, including of course the tools that make it run in the first place - such as the Apache server program, which accounts for 60 or 70% of web servers, and also of course the Linux operating system that servers use.

It is important to bear in mind that there is no quality penalty by going for an open-source application. In fact O-S can often be of higher quality than the nearest commercial equivalent. The issue is more likely to be support options.

What is the most popular CMS type?

In the end, going by the numbers of the various CMS apps found on livesites, most people choose a popular CMS of the OSS, PHP, MySQL type; e.g. a LAMP server compatible free CMS (though of course the plugins may be commercial). OSS = open-source (free) software; PHP = the core code type; MySQL = the database type.

This configuration probably accounts for over 50% of the CMS apps out there on the Net. Nevertheless it is not the only way to go, and there are plenty of options. A Content Management System that can be installed on a LAMP server (Linux / Apache)  has many advantages, since that is the basis of the Internet. In some circumstances, though, an alternative must be sought.

The alternatives include PHP no-SQL CMS of the flat-file class, and ASP CMS for a Microsoft server, running on MS SQL Server, ie a no-MySQL CMS. CMS are (almost by definition) a server-side application, since they are webapps, and these almost always live on a server. However, this isn't cast in stone, and there are one or two client-side CMS apps. These are rare, and entail the generation of the site on the local machine and then uploading the flat (unscripted) pages to the server. Naturally, there are some restrictions to functionality with this method; which, incidentally, almost qualifies as a flat-file no-database option because of course it doesn't require a DB at all (on the server - though one may well be needed on the local machine). There are also some ecommerce apps that work in this way.

Microsoft IIS server CMS

A CMS to be used on a Microsoft server, e.g. Windows Server 2003 IIS, can be of three types:

  • On a basic and restricted MS server, it must be an ASP no-MySQL CMS, using either a flat-file database (DB) or the MS SQL Server database (if available on the server).

  • On a full-feature MS server, that is to say one on which PHP and MySQL are installed, an ASP or PHP-based CMS can be used; and it may use a MySQL database. Logically, it will be an ASP - .NET application, since otherwise a LAMP server would be a better choice. The PHP functionality however will benefit all the other normal Internet applications (aka webapps) that would otherwise be unable to be installed on a Microsoft server: website statistics, blogs, wikis etc.
  • A flat-file application that needs no DB. It can be a PHP app if that code is available on the server, but a more sensible solution would be an ASP app. 

Also needed on any server are what could be termed ancillary applications, if the main website application is a CMS or ecommerce application. Such apps would include blog and wiki software. Most if not all of the famous and best-known versions are PHP - MySQL applications, such as WordPress.

Of course, there are ASP equivalents for most of these ancillary applications that can be used. But there are very good reasons to use the original and best versions. If you want the top blogging application you'd install WordPress.

What is the ASP equivalent called? Good question...

Flat-file CMS

A CMS to be used on a server (of any type) with no database can only be:

  • a flat-file database CMS

  • a client-side CMS

This would also apply if there were no access to server management functions, as this is needed to create a database and set up the configs so an application can talk to it.

A flat-file DB is a text file data storage method that can be used on any server, as it does not require a true database. Flat file CMS apps are fairly rare, and probably comprise around 1% of CMS livesites. Their advantage is simply that they need no database; and they will also probably be compact and straightforward compared to others. Inevitably, they will be very much more restricted, and perhaps best suited to the most basic use only: they will allow online content edits; will suit small websites (certainly with less than 5,000 pages, and we would suggest a limit of a few hundred); and there are unlikely to be many plugins, which in many ways are the raison d'etre of a CMS.

A client-side, as opposed to server-side, application is one that resides on a local machine, i.e. the owner's PC. The pages are generated there and uploaded to the server. This is the least CMS-like option of all.

Other CMS types

There are many types of CMS as regards codebase and major function/s.

Coldfusion CMS
We have only researched one example of this type, which can be distinguished by the .cfm file extension in places. It was of notably poor quality in every department. The developers have never heard of web standards, which should come as no surprise as this type of CMS is about as much use in the modern world as the FrontPage web editor, RIP.

Java CMS
This codebase is popular in the major corporate CMS world. It is used because it provides a rock solid core which is almost infinitely customisable. The downside is that costs are stratospheric. However, despite the market area and the high costs, there are a range of quality levels here; and as always, quality tests should be applied as the first consideration.

Since Java CMS are one of the most expensive to change, there are many that still run on outdated old engines that pay no respect to modern standards. A new Java CMS needs to use a tableless code layout, pass accessibility testing to level A, use a page file extension of .html (preferably - though this is less important), and validate 100% for xHTML and CSS - to the Strict Doctype of course - otherwise costs at some stage in the future will be astronomical. And legal compliance needs to be a factor here since only substantial enterprises can afford Java CMS.

Testing your proposed CMS

When you have decided on two or three CMS apps to check out further, the next stage is to look at some livesite examples. See what some portfolio sites look like, how the site architecture is arranged, what the navigation menus look like and if they are CSS as against undesirable scripted menus, if they conform to web standards - how the code validates and what their accessibility score is, how the templates figure, if the URLs are sensible, and so on. You can read more about these features on the next page. There are several that you cannot check on as a visitor, such as the ACL levels, but there is still plenty that can easily be checked out.

However, in this process there are two vital factors that need confirmation before anything else. If the chosen CMS fails on these, you would need to find better examples or perhaps it would be wise not to go any further.

Step 1: Go the the validator at the W3C and validate some pages of their portfolio sites. Pages should ideally pass as green, to a Strict doctype. Five or less errors is perhaps an acceptable number, as they may have been introduced by the site owner adding content incorrectly. A small number of fail points like this can also be caused by faulty templates rather than errors in the core application.

Step 2: Page addresses (URLs) should be short, easily typed, clearly relevant to the site's business, and without any symbols in them (&,?, =, etc.).

If a site fails on these points it could be due to several factors - perhaps it's a new site that hasn't been fully sorted out yet; or perhaps the implementers were not aware of quality standards. But you will need to find at least one site of the proposed type that demonstrates a reasonable level of quality.

It is true that it can be hard to get production pages to validate 100%, so you can have an allowance of 4 or 5 minor errors, perhaps caused by the owner due to lack of training. Some code errors may not be important to correct interpretation - xml to html misreads, perhaps, or charset problems - and can be cleaned up at leisure, as neither visitor's browsers nor searchbots will be misdirected by them. A page needs few code errors otherwise it cannot qualify as acceptable. We have seen commercial dynamic apps with over 300 code errors on the page, and that's not funny. That isn't code, it's complete rubbish - and someone paid for it.

There is an issue over doctypes here, that can be confusing. In theory, best practice is to use a Strict doctype and validate to that. This is because a Loose aka Transitional doctype allows many irregularities and also puts a browser into quirks mode. But as usual, a compromise is often needed, and many otherwise good CMS validate to a Transitional doctype.

Bad URLs are another matter to be taken seriously: if you want to compete in tough markets you need flat (short) URLs. Search engine staff have made it quite clear that the shorter the URLs the better, and there are any number of proven examples for this. Do not, under any circumstances, listen to anyone who says otherwise. You can run your own tests in this area (as we have), and you will find clear evidence that short URLs (aka SEF URLs) work best in tough commercial markets. Of course, if you aren't going up against competition, then this is less relevant.

Most dynamic URLs can normally be rewritten, it just needs the right method to be found and used. This is normally done with a plugin that interacts with the htaccess file on the server. Some apps handle this internally, which seems a better system. It's handled by an application server sometimes (aka a servlet container), but these can't normally be used on shared hosting.

CMS types and features

Now we'll resume our feature list for choosing a CMS. Let's look at some popular CMS solutions and see what good or bad features they may have.

Once a budget is established, next you must choose a CMS type based on ability and fitness for purpose. In general, CMS application vendors and developers do not emphasise this, but the majority of applications tend to sit within a class of CMS; a sub-type that defines what they can be used for, what they are good at, and what they should not be used for.

In many cases a CMS will fit several of these profiles, especially where there is reasonable ACL control and a plethora of plugins that expand functionality. Here is a sample of these CMS classes or model-types:

  • micro CMS
  • online brochure
  • community / news CMS
  • teamwork CMS
  • provider - consumer CMS
  • portal CMS
  • multimedia publishing tool
  • enterprise-class CMS

The most popular, going by livesite examples, is the online brochure class, which is the standard 'shop-window' company display CMS. Virtually any CMS can operate in this class; some simpler ones are ideal for basic usage roles here, such as CMS-MadeSimple. On the other hand the more capable applications such as WebGUI or Joomla are equally suitable, especially if a very high level of presentation is needed.

The Micro CMS class is fast gaining in popularity (a term we have had to coin in order to describe this growing area). Essentially these are blog / cms crossovers that are fast and easy to install, and allow quick, simple online edits and content changes. These applications are not a CMS in the normal sense of the word; but they allow online editing, which the average person perhaps thinks of as the main determining factor as to whether a webapp can be called a CMS or not. Examples: Movable Type, WordPress, TextPattern.

This is followed by the community / news type CMS: one that allows many to contribute, while only having low user privileges for frontend contributors. The main requirements for this type of CMS are that it must have frontend content editing and upload (though not necessarily publishing), and of course a minimum ACL scheme that has multiple user rights levels. Example: PostNuke, Mambo, Joomla.

Teamwork applications, aka collaborative workspace CMS, allow different teams to work on different projects. With good security features, such teams could be distributed. For these tasks a CMS must have frontend access, and excellent ACL / group roles / user rights control; also, preferably, versioning and workflow controls. For simplified single-team use, though, only the usual frontend access would be needed. Examples: Drupal, Plone.

The provider-consumer model describes a CMS that functions in much the same way as a normal 'flat' website: content is created by one person or a small team, and presented to a larger audience. Here, we do not need frontend access, and must prioritise for fast content creation and easy publishing. Example: CMS-MS, OpenCMS.

A portal or portlet type CMS indicates one that allows teams to publish their own sections. ACL must be comprehensive, and there needs to be a fully-featured publishing editing process. Example: Plone, e107. Another interpretation of the word portal is that many different sections or types of content should be published to the front page, and visitors may go from there to different areas of the site or other sites. This simply requires a capable publishing tool with a large number of very capable templates - such as Joomla.

An enterprise class CMS must have all the functions a large organisation needs, and have access to easy sources of additional features. It must be scalable and robust. It will probably require specialist hosting and a decent budget. Examples: eZpublish, Plone, Alfresco.

ASP codebase CMS must be hosted on a Windows server. In the SME off-the-peg market area they are rare, since there are few reasons to specify one. However, they have a presence in the SME custom CMS market; and especially for larger enterprises, or for ecommerce CMS. It is probably easier to find development sources for custom CMS functionality in the ASP area than in PHP. This has to be set against the fact that, for most people, a PHP CMS will be far easier and cheaper to run as the functions and features are simply plugged in as needed.

Rich media CMS
We originated the designation 'multimedia publishing tool' for the Mambo and Joomla type of CMS. Although this is not the only role they can play, there are few others that compete with their ability to publish any and all media types, in a multitude of ways. Joomla is the king here, because of the vast range of plugins for streaming media, Flash, video, music, gfx, image galleries, ad infinitum; together with the repurposing extensions that can convert it to an online magazine, online directory, document repository and so on.

As has been stated, in many circumstances a CMS can fit more than one profile; but there are tasks for which it will not be suitable. As an example, Joomla is a very capable publishing tool, but cannot be used as a teamwork CMS for multiple distributed team projects, as the ACL is not there.

It is possible to expand the model / type list considerably, to define all sorts of roles that fewer CMS may fit; or to provide alternative or preferred terms for the classes. Another type is the LAN team class, like RadiantCMS. This must be installed on a local server, and has many supporters among the developer community as it uses Ruby on Rails.

The choice: OSS or commercial CMS

We'll start with OSS - open source software - because it means you can set up for minimum cost and see how it goes. You will then know what you are looking for if you decide to go commercial. There are also many commercial support options for OSS, and even some semi-commercial CMS solutions.

One reason to go full commercial might be that you can afford to sign a contract to get what you need, when you need it. If you have the budget, that may be the best option. There are some capable OSS solutions out there, though, so the the big question may well be support; the bigger the community, the more support options there will be.

It's a fact that SEO for CMS can be better in open-source applications. Some of the larger commercial solutions have problems in this area (even though they claim good SEO standards). As always, check the index page of a portfolio site to see if the application is web standards compliant, at the W3C online validator. That's always the starting point and if portfolio sites fail this test badly (with 40 errors plus for example), then you know exactly what standard of SEO you are likely to find. Developers and implementers who don't even know about the basics are unlikely to be able to handle more complex issues.

Example of a successful CMS

Let's give an example of a successful CMS in use. For commercial websites it's all about the results, after all, so if we can demonstrate that a given set-up will perform well, it should reinforce the point.

On September 14th 2007 we reached the Google and MSN #1 positions for our preferred search term in the SEO market area with this website (and subsequently for more  than 50 other chosen terms), which runs on the Joomla CMS system. That is two months after the site opened, the domain name also being brand new - we had just re-formed and re-branded the company. Needless to say our methods are 100% ethical. You can probably derive two things from this:

  • We know what we're about
  • Our chosen CMS does the job

A CMS of this type is basically a framework to hang your plugins on, so the choice of which ones to use is quite important. We prefer the sh404SEF URL solution as our first installed plugin, after which other tools to do other jobs are added. It follows that Joomla plus the sh404 URL / metadata solution will perform at the highest level. You can find links to both these products on our NetResources page, with a description of what they do.

Did you find this page useful?
If so, please consider linking to it. Thank you.

Page 2a follows on >>
Web Business Managers