Compare CMS - Part 2 - Features and Tests

Types of CMS
What is the most popular CMS type?
MS server CMS
Flat-file CMS
Testing your proposed CMS
Example of a successful CMS
CMS types and features
The choice: OSS or commercial 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 search optimising. 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. It's hard to criticise open-source apps because of the huge amount of time and devotion the developers have put in; easier if we just don't list the ones we don't like (apart from one or two interesting cases).

Commercial applications are a different matter, and at some stage we will include some and criticise where necessary. 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 populariry 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.

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 CMS app ideally needs to be able to be installed on a LAMP server (Linux/ Apache), 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 (frequently 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 two 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 or 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.
  

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.

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 it really isn't worth going any further.

Step 1: Go the the validator at the W3C and validate some pages of their portfolio sites. A web page needs less than 10 code errors to qualify even as partially correctly coded; and the fewer, the better. Five or less is an acceptable number. A small number of fail points like this can easily be caused by faulty templates rather than errors in the core app.
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 they fail miserably on both step 1 and step 2, then please just run away fast and don't look back. You'd be a fool to do otherwise.

OK, it's hard to get production pages to validate 100%, so you can have an allowance of 4 or 5 minor errors - xml to html misreads, perhaps, or charset problems. They don't really count, as neither visitor's browsers nor searchbots will be misdirected by them. Certainly, a page needs less than 25 errors on it to qualify as even third-rate code. 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.

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.

Most dynamic URLs can normally be rewritten, so if they can't be, on your proposed application, there are some serious questions to be asked there. Mainly, why are you bothering to look at this app?

It may of course simply be the case that the example you are looking at is badly managed and no one has thought to get the URLs re-written; but you should certainly check this elsewhere.

Example of a successful CMS

At this point we'll break and 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 then subsequently for several more 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 + 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 are about.

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:

• community/ news CMS
• teamwork CMS
• provider - consumer CMS
• portal CMS
• multimedia publishing tool
  

The most popular, going by livesite examples, is 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, OpenCMS6.

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.

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. More type names include the brochure type (like WebGUI), and the LAN team type (like RadiantCMS).

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.

Page 2a follows on >>