Home arrow Compare CMS - 2b
Compare CMS - Part 2b - CMS Features



Compare CMS - Part 2b - CMS Features

Page 2b:
CMS ACL
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



On this page we look at some of the major features to be found in content management systems. In fact these are best referred to as functions - a function is a major core ability or requirement, and a feature is an add-on task-handler.

CMS ACL

Access control levels (or lists) in content management systems refers to user privileges and group roles. This means the ability of any one person, or any group of persons, to see or edit a resource such as a page.

In practice this usually means that a group of users are given access to a certain section or pages on a site. Another group may also have the right to edit those pages.

A group of people may in some cases be taken from members who belong to levels, or other groups, of differing rights. Therefore the ACL area of site management may be quite complex. It requires the ability to allocate different privileges to different people.

Granular ACL
All CMS vary widely in their ACL abilities. Some have the simplest and most basic arrangements, with a few levels of user, and nothing more. At the other end of the scale, there are WCMS that allow the creation of unlimited groups and the selection of any user to place in them. Such capability is called fully-granular ACL - that is, it allows control at the most detailed level.

ACL issues
The addition of ACL into the mix always makes a CMS more complex. Add in several usergroups, with an assortment of rights (aka privileges), and things tend to get complicated. This is the biggest drawback to granular ACL.

All capable CMS have some sort of core ACL functionality since otherwise they could not be described as 'capable' - though this can often be of a simplified type, with few options. Examples:
  • Wordpress (a micro-CMS), has one ACL group - the admins. It is therefore suitable for basic publishing tasks.
  • Joomla (both 1.0 and 1.5 series) has two ACL groups (members and admins); plus 8 additional user levels. It can therefore be used for extended publishing tasks. However the ACL can be expanded. In the 1.6 series this changes to a more capable form of ACL, with additional usergroup roles.
  • eZ Publish has unlimited ACL groups and is therefore suitable for large enterprise tasks.
A 'group role' is a description of the additional privileges that a group may have, when that group is composed of users taken from other groups or levels.

Some CMS are attractive options especially because of their fully-capable ACL, and possibly despite other drawbacks - although all CMS, of course, have drawbacks. An example is Drupal, a PHP-normal CMS with excellent ACL that is often compared with Joomla, and competes for similar user profiles. Drupal has good, granular ACL that is far superior to Joomla 1.5 for example. However, it has poor templating, admin usability, and all-round functionality in comparison. Of course, due to its other plus points - such as rock-solid stability and high page number capability - it is an excellent choice for many projects, with the extended ACL functionality.

The big problem with ACL is that it always makes CMS management much harder. This is for many reasons, such as:
  • In the first place, a CMS with granular ACL functionality cannot be of the simple, micro-CMS type like WordPress - it's going to be a bigger and more complex proposition
  • Some CMS with good ACL are notoriously hard to work with for newcomers - an example being Plone
  • Adding users to groups may be easy, or not so easy
  • Once various usergroups with differing privileges are in operation, then things can get interesting
  • The fact that some people can't see some pages or menus can have unwanted effects on the CMS operation as a whole
  • Strange anomalies may crop up such as a menu not showing up when it should, because of a conflict in a user's privileges
  • Sometimes there are issues, for example a user being able to see or do something that in theory they are barred from - and trying to resolve such issues is an extended process
  • On some CMS it is hard to get a master list of usergroups and rights
  • Trying to work out who can do what on a CMS can be difficult, if no records were kept

ACL plugins
By 2010 it will be impossible to call a CMS 'capable' unless it has good core ACL - the ability to select random users from random userlevels and allocate them to other groups with different privileges, as a core function of the unextended application. After all, it is a basic requirement for about 50% of CMS today to be able to pick users for other roles - to allow them into private areas for example. Currently,  many CM systems allow that by plugin functionality - but this always has negatives of some kind.

One way that these plugin ACL solutions fail is by being unable to fully control the ACL environment, and allowing bypassing in some form. For example you can test this by:
  • Do not login, or login as a low-level user. Then go directly to the URL of a known restricted page. If you can access it, the ACL is simply protecting menus, and is of very low functional capability - it can easily be bypassed.
  • As before, don't login as a high-level user. Then, in the site search, search for text that is only on a 'private' page. If the text or page can be seen, the search facility has bypassed the ACL, and it isn't working 100%.
As these issues - and others - are common to ACL plugins, it can be seen that plugin ACL functionality is not the answer. ACL must be a core CMS function for the webapp to be considered capable or fully-functional.

What is a CMS with ACL?
To be described as 'a CMS with ACL', the application should have 9 or more ACL groups, who can be drawn from any registered user level, and who can be assigned any role. Note that user levels are not related to ACL - users of different levels have incremented rights, but users in different ACL groups have privileges unrelated to those in the user levels. These might include the ability to see, or to edit, random pages, or those within page groups; or editing or moderating privileges of various types. Such privileges are assigned as a group role. A 'role' is any privilege or group of privileges that does not exist for standard users of any level.

CMS databases

All CMS use a database (DB) of some kind. This is because a CMS does not function in the same way as a standard website, or as it is termed, a 'flat HTML' site. Or, indeed, like a semi-dynamic site - one using HTML plus PHP or ASP. See the relevant page here for a full description of how a CMS works.

  • A normal CMS uses an SQL database, which is server software
  • A flat-file CMS uses a text file as the on-server database
  • A client-side CMS uses a database on the local PC, typically an Access DB or similar

There are no pages on the server with a content management system. Apart from a very few that use a flat file DB, an SQL database of some kind is used, to hold the page text and publishing instructions. A flat file is basically a text file, and functions better than might be expected - the maximum page number is actually around 20,000 with this system, though a safer max number is about 1,000 or less. If a larger site than this is needed, an SQL DB is the way to go.

SQL databases are provided in various formats such as MySQL and PostgreSQL. The most popular of these is the former, which has a large number of support resources. For the vast majority of users, MySQL is by far the best choice, due to the volume of support resources. However, it is true to say that PostgreSQL has a slightly better reputation, and it does not suffer from some of the bugs that MySQL has. It is a more solid choice but with far fewer resources.

A Microsoft server has the choice of using the MS SQL Server database, or an OSS SQL DB such as MySQL if that has been installed. Not all MS server hosts know how to do this.

It is worth pointing out that the Microsoft PC database, Access, from the Office suite of programs, should never be used on a server under any circumstances. It is not designed for this in any way and invites trouble, as it cannot be hardened fully. Some of the most famous exploits of all, with severe implications for many of the people affected, involved an exploit of an Access DB used on a server.

A MySQL DB-run site has the potential for many hundreds of thousands of pages, perhaps over a million. Large sites of this size, though, frequently run on multiple databases. For safe operation, a DB is often restricted to 50,000 pages or files, as this is a good limit for stability. More DBs can be used, as needed.

An important point is to make sure to use a website host with an enlightened attitude to databases - some hosts are still back in the late 90's and think a database is an expensive and rare luxury. There are site hosts that provide 5 MySQL DB's and 5 PostgreSQL DB's on a £30 a year hosting package, for instance; don't accept a 'no' or a 'yes but it costs a lot more' answer - find another host ASAP. You can get 20 DBs on a £50 ($100) per year hosting deal - just look for it. A recent trend is for hosts to supply an unlimited number of databases on a shared hosting account, and of course on a dedicated server there is no limit.

Client-side CMS

All the applications listed on this site are server-side apps, though one or two also have the ability to run client-side. Server-side meaning that, as you would expect, the CMS resides on a server; client-side means it runs on your PC.

An example is OpenCMS, which is an open source Java-based CMS. Its web pages, especially in the past but less so now, were heavily based on javascripting, and have the .jsp (java server pages) fileformat. This is a tremendous negative for accessibility and organic search results, not to mention legal compliance in some circumstances, and therefore they introduced an alternative page generation method. A client-side mode was introduced, so that flat HTML pages could be generated on the local PC and uploaded to the site, to bypass the negatives with the heavily scripted pages. This allowed the use of a capable CMS that unfortunately output pages of a less-acceptable nature; but as stated, there have been improvements here.

One or two ecommerce apps are also client-side apps. You generate the site on the local PC, then FTP it up to the server. This is acceptable with 500 or 1,000 pages, but 30,000 would be a problem. It is used because it makes for simplified server management, and security is better for novice webmasters.

Client-side CMS advantages
This operational mode can be used for several reasons:

  • To avoid the use of heavy scripting
  • For use on a restricted server with no PHP or databases (MySQL)
  • For use on a server with no access to management functions, such as a shared IIS server
  • For security reasons, since removing the database and scripting will remove 75% of attack vectors
  • Pages load very fast, and there is very low server overhead, as this is a flat site


Client-side CMS disadvantages

  • All server scripted functionality is removed
  • Operations must be of the simplest type in every case
  • The site is of the flat HTML class, not a true CMS
  • A true CMS has visitor interaction, but this will not be possible
  • Functionality is limited as there is no database

Of course, there are all sorts of issues with running such a major application client-side; the truth is that for any decent-size site with modern functionality, it doesn't work well. When you think about it, this isn't really a CMS solution, it's a website generator - an extended flat-HTML website management solution. Generating the site locally and uploading it is going back to the old way of running a website. There are some advantages over the basic visual or HTML editor method, for instance you don't have to create each page individually as the CMS generates it for you. But in general it's a step backward, returning to the days of flat HTML - PHP - ASP sites with reduced capability in every area. 

Hard-coded sites are best in two areas: dead simple small sites with unchanging content, and big commercial projects with all-custom coding and a commensurate budget; otherwise a normal server-side CMS, or ecommerce app - and especially a combination of the two - has them all beat.

Ecommerce CMS

One of the most common requests from users is a CMS with ecommerce capability.

One of the rarest facilities for CMS coders to build in is an ecommerce facility.

Obviously, one isn't talking to the other. Any capable CMS needs to either come with a shopping cart built in, or be able to have one plugged in seamlessly. You can argue all you like about this - but in that case you are probably a short-sighted CMS dev who doesn't care what the end-user needs. Ask the users and see what they want.

Another way of looking at this is that ecommerce apps need content pages for decent search results, but not all provide the ability to add them. A CMS that does both is therefore the perfect answer.

Luckily this situation has improved a lot in the last year or so. Because the need for CMS shopping carts was so glaringly obvious, many 3rd-party developers have produced plugin solutions. In all honesty, at this stage, it would be fair to say that the majority of these plugin shopping cart solutions for CMS are 'incomplete'. There is still work to do in this department.

Best open-source ecommerce CMS
There is only one complete OSS CMS-shopping cart solution: Joomla-Virtuemart, so choice is limited. Luckily it does the job well and will suit many users; see the review in part 3 of this section. There are other alternative ecommerce plugins for Joomla.

Many other open-source CMS have shopping cart plugins but the safest way to describe them is limited. In general they suit basic displays of a few products, with limited options for templating, product variations, order variations, payment gateways, tax, shipping, delivery and so on. For example, many of these plugins have 10 or less payment gateway options; compare this with osCommerce (the popular OSS ecommerce app), which has nearly 500.

Compared to a real ecommerce application, they are therefore limited to about 25% functionality or thereabouts; the result is that some developers prefer to bridge a CMS and an ecommerce program in order to get something like full functionality. There are some problems with this method though.

Best commercial ecommerce CMS
As with all questions in the commercial area you have to start with the budget. The cheapest reliable complete solution we know is the semi-OSS (or semi-commercial if you like) eZpublish ecommerce version. The core CMS app is OSS, but the shopping cart is commercial; and support / implementation is of course commercial. An estimate for the cheapest, very basic up-and-running solution here is around £2,500 ($5,000) - though for DIY, costs are a lot less. See the review elsewhere.

CMS Documentation

Ah, now you're asking... If you know anything at all about open-source, you'll know documentation is a dirty word. It's usually either terrible or non-existent. This is probably the main reason why commercial enterprises steer well clear of it - with no docs, and little in the way of commercial support options, they can't really do much else.

You need to realise two things:

(1) open-source software is written by geeks for geeks
(2) no geek gives a sh cares a hoot about image

What you see is what you get, and if you can't make it work - or if you really don't appreciate how good it actually is - then they just don't care. Why should they, no one's paying them. It's written by teams of people who are the best in the world at their game. The best and the brightest minds contribute, and the last thing on anyone's agenda is the help manual. OSS is something of a status symbol among geeks; if you are a core dev on Apache, for instance, everyone knows you can cut the mustard. No manual, no advertising is needed to tell that to the people who matter. And the only people who matter are other geeks.

This presents some problems for the rest of the world. Finally, people have rallied round to try to do something about this situation, but it generally takes a very large community indeed to find anyone who can spell or communicate in anything other than Martian. The prize goes to Joomla, for the best documentation, as you can find a dozen or more ebooks and PDFs around that will get you out of trouble. They still haven't figured out how to write something for users who aren't at least semi-geeks, but no doubt that will come one day.

Usability is always the very last item on anyone's agenda. Look at the W3C: a hilarious example of how a large number of very knowledgeable people find it absolutely impossible to communicate that information to anyone else. Of course, as anyone knows, engineers can't communicate; but one would have thought that technicians working in a communication medium might have realised that.

Not sure what we mean? Well - for example, validate a webpage using the W3C online validator, and then try to find on-site resources that tell you precisely how to fix the errors located. Not an unreasonable request, one would have thought, from the people who write the standards in the first place. If they are telling you your page is faulty, they should also be able to tell you how to fix it. Yes? And I can assure you from usability testing of this exact problem that only a tiny percentage of people who need help from the W3C are helped in any way at all; and they all have complaints (date: October 2008).

CMS Templates

We ought to look at this as it is one of the very best features of a CMS - or should be. For some people, the templates are the raison d'etre of the things in the first place; for others, it's the user-edits by by browser that clinch the deal.

The template factor is part of the way that a CMS separates design from content. This is a meaningless concept, no matter how well it is described, until you experience it in practice. It refers to the fact that either the design or the content can be radically altered without affecting the other. It is a massive advantage over flat HTML sites.

Also, having templates available means you can automatically have a reasonable- looking site straight out of the box.

No designing, no graphics, no coding, no Dreamweaver, no nothing - just add your text.  The use of templates means that 90% of design worries are gone. And if, as with one or two CMS, there are thousands of templates and hundreds of template designers around, you can't go wrong; just search 'joomla templates' and you'll see. Even the templates can be altered so they are unrecognisable.

Alternatively, if you're a great designer, and can do a nice layout in layer-based (div) code and CSS (no tables or cells and all that old rubbish please), then so much the better - use your favourite visual or code editor, build your page, then input it to a CMS type that can use this for a template.

This method typifies the design-centric approach to CMS implementation. If you want to take that route, we advise the use of SiteSpinner visual editor and CMS-MadeSimple, or for a more capable CMS, then Radiant or Umbraco. SS is an excellent layer-based visual HTML editor, and CMS-MS is the simplest CMS that can make full use of that approach. If you are an HTML coder coming over to CMS, then we advise using div and CSS based layouts wherever possible, when designing from scratch as with CMS-MS and Lucid. Don't use tables, as that is simply bringing across the worst of the old-fashioned ways into a new medium. Well, OK, cells would be even worse, admittedly.

Template types

There are two main approaches to templates that you'll find: the pre-built solution, and the use-your-own type.

The pre-built template method
The best example of the pre-built template class is Joomla, as (a) it has about the best system of that type, and (b) there are more templates for it than any other CMS. They are PHP-HTML-CSS based, and can therefore be modified by anyone who can understand those. You don't have to be able to write the code, in any case, just recognise which does what and change it. You can easily get a completely different look by swapping out some gfx and changing some CSS colours - simple. Then, by publishing or un-publishing modules, your pages will look completely different from anyone else's even using the same template.

If you wish, you can get plugins for Dreamweaver that enable you to output your PHP page as a Joomla template, including the other files needed: a CSS file, the gfx, and a master XML file list.

Cloned template method
The best CMS using the pre-built system will allow you to use different templates on different pages. You could easily go too far here, though; but a good way to use this flexibility is to clone the template, then change some graphics, and use the alternative template on a couple of pages. That way it's different but keeps to the same house style.

The build your own template method
(aka DIY templates, grow-your-own templates, or roll-your-own templates)

This system is typified by Lucid or CMS-MS: you just give it your standard pre-built HTML page. Then, various proprietary tags are added for the editable regions etc. It's a little similar to the Dreamweaver editable regions system.

The best way to use this system is to design an HTML page in the first place:

  • that is based on layers and CSS (i.e. on divs)
  • that validates with the W3C online validator

Having done that, you've got the best possible foundation; and, truth be told, probably better than even Joomla, since they are still struggling with table-based layouts and will be for some time, probably until Joomla 2.0.

Other important CMS features

There are many features that might influence your decision. Among them are ACL, number of plugins available, workflow controls, and content versioning. Support options are important: will you have a webmaster, a sysadmin, and support developers? Or just perhaps fix it all yourself.

A webmaster manages the day-to-day running of the site. They create pages for those who prefer not to do so, but in the CMS world do not usually expedite content changes or edits unless these are too complex for the end-users. They keep an eye on security, basic search engine compliance, hosting and other on-site issues.

A sysadmin (sytems administrator), where employed, oversees one or more websites. They control major aspects of site management such as backend users, hosting and security contracts, etc.

Support developers build, change, or repair site functionality. They may create or install new core functions or add additional features. They fix problems.

CMS LAN development

First things first: install the CMS on your local LAN, which means on another PC nearby that is connected to yours and has a server application installed. This has two very important uses:

  • You can get the hang of it without working on a live site
  • You can pre-build your CMS locally, then FTP it up to the server

So you'll need another computer to load it on. That will of course be a PC - we don't have the space here to talk about fashion accessories (Macs). You could, in fact, set up your own single PC as a server, but this has some disadvantages so we'll gloss over that. Any old PC will do for a LAN server, and of course old PCs are easy to come by - nothing's worth less than an old PC or CRT monitor, except maybe a ten year old map. However it will need a NIC of some kind, meaning a network interface card, LAN card, wifi card, etc. Even if you don't have that, all is not lost, you can use a USB LAN cable instead. The IP numbers are a bit weird, but it will work fine.

XAMPP for CMS
You now need to turn the spare PC into a server, so you need server software. One of the easiest ways to do this, while ensuring you get the necessary scripting and database capability installed at the same time (PHP, Perl and MySQL), is to use the XAMPP server package install. This is Apache for Windows, which has all the other vital bits and pieces you'll need, and is a free download. Almost always this is a one-click install, which is one of the huge benefits of Windows (the others being the fabulous GUI, extreme ease of use, the vast range of software, and so on). If the install fails (one time in a thousand), it will be due to a phpMyAdmin and/or MySQL initiation error. We've done a howto on installing and troubleshooting XAMPP, and you can find it via the Tech FAQs page on this site.

XAMPP is the perfect LAN server but don't use it for production, it's a dev server set-up only. Production servers (livesites) need much tighter security, but on XAMPP that is left wide open to enable maximum development capability. A production server needs a properly-compiled set-up for security - Ubuntu Server might suit if you want a quick install. On a Windows box, for production (Internet-facing duties) you'll need to change over to Windows Server 2003 IIS 6.0, or Windows Server 2008 IIS 7.0. Lash-ups are insecure and asking for trouble.

Part 3 - see main menu at right


Most Useful CMS Sites  [tell us yours]

Church of the Highly Improbable 
   www.highlyimprobable.org
The answer to everything, perhaps. What fun you can have with a CMS, eh?
A Postnuke CMS site.


[Site title indecipherable but may include cheese]
   www.mynameismonkey.com
An interesting site that develops the idea of blogging with no content whatsoever (or is that every blog?), on a system that is not designed for it (a CMS), in order to look nice and hide the fact that there is nothing actually there. Quite fun I should think. Amusing for 30 seconds, anyway; I prefer his church. And Postnuke wins that contest I reckon. A fairly reasonable template - at least as far as Drupal is concerned :)
A Drupal CMS site.


TNA Wrestling
   www.tnawrestling.com
Over a million uniques a month on this one so leave off with the J don't scale, please. Maybe it's running on Lighty then. And a fabulous site in all respects, especially the hysterical ring announcer - I prefer the UFC guy, much more sensible. And what about those tough girls eh?
The most fun you can have with Joomla CMS.

 
Web Business Managers