Home arrow Compare CMS - 3a
Compare CMS - Part 3a - Business CMS Reviews

Compare CMS - Part 3a - Business CMS Reviews

Business CMS Reviews

Because of the capable nature of the applications on this page, it is a business CMS review of open-source and semi-commercial applications. Each of these website CMS will suit some enterprises, depending on their requirements. These programs are not commercial CMS, in that they are free; but extensions are often commercial, and of course full commercial support is available. Nevertheless, there are many community resources available here, including support forums and documentation, so these applications represent something of a bargain. This is not bargain-basement territory, though, as these website CM systems are mature and sophisticated, with very large resources behind them, and compare in quality with anything available in the commercial world. There are undoubted advantages in going this route, and plenty of household-name enterprises have done so, even though they must have the budget for a full-commercial solution.

Need to ask a more detailed question? Try the new CMS Forum.

[please be sure to read the disclaimer at the end]


                                 Business CMS Reviews


One of the two best fully open-source PHP - MySQL CMS available - and the best for business use.

Complex, not too flexible, not many templates, not easy to work with; but the best ACL in fully open-source PHP CMS - meaning that if you have different groups of people working on different sections, needing different Access Control Levels (user group rights), then this is the one for you.

It's true that eZpublish has the best ACL in PHP CMS, but it isn't fully OSS: extensions are often commercial (at least, all the big important ones). Plone probably has the best ACL apart from that, but requires a specialist server and a sysadmin experienced with Plone, due to its complexity.
Drupal, though, being a PHP-SQL CMS, will run on virtually any server, and is fully open-source - though of course there will always be some extensions that are commercial (ie paid for).

Therefore it may be the best choice for a multi-group team or community CMS, for intra-office data perhaps; or a website CMS that has different contributors who each 'own' specific pages. It's big, stable, and solid. In the past there were insufficient plugins to enable full functionality, but this has changed and there are over 1,000 now. Together with the user access roles, other useful features make this the first choice for a complex in-office CMS, or online multi-user business CMS, that needs a standard server. It would suit enterprise use for a public / private profile website: some sections for staff, some open to the public. A CMS application needs to be secure for this, and Drupal fits the bill.

Many say Drupal, which originated in Belgium, is the new Plone and should be considered in preference if you need something big and stable; this would certainly be true if you need a multi-user LAMP server PHP-SQL CMS, since Plone has restrictive server requirements and is expensive both for hosting and support. It isn't the sort of thing to use if you don't know it and it needs to be up and running tomorrow. In a week, maybe, for a very basic site. It has a steep learning curve for the sysadmin (though not as bad as Plone), and is far less flexible than Joomla for instance - but probably more stable with high page numbers. It needs to be stated here that Drupal is highly extensible - for developers of course - but not by users, as the plugin volume isn't really there yet. All the complex sites we work with have plugin issues: insufficient plugins for functions that are needed by large commercial sites. This is partly due to inter-version plugin compatibility issues, since you will often find that the previous Drupal version has the plugin you need. Of course, for enterprise use, a developer can easily create the functionality you need.

It's just a personal opinion, but we reckon that a CMS needs to have 2,000 plugins available before it can be really be called extensible. Just a matter of opinion, of course - but you should remember that a cynical appraisal of the value of plugins is that less than 25% are actually of any practical use. This is a complex subject, and perhaps more than a little controversial - but the existence of 1,000 plugins does not unfortunately mean that you can do 1,000 jobs; and even 250 functional choices would be something of an optimistic view. Many CMS plugins perform minor tasks or are related in some way to other plugins.

Like all the popular CMS projects, especially in the PHP-CMS field, Drupal is moving forward fast. In fact what is said about any of these applications one year is quite likely to be wrong the next. We expect that Drupal will accumulate more plugins (currently around 1,000 at late '07) and therefore become an even better prospect for all-round online publishing, especially considering its solid reputation.

Drupal's strengths are the fine content item management possibilities, stability, security, robustness and potential extensibility. Multi-site capability is reported as good though we haven't tested it.

This is a quality CMS that will not let demanding users down. As an example, there are even three vBulletin forum bridges available for it. The flip side of this is that you cannot expect to get maximum benefit from it without hundreds of hours of time input. As always with modern extensible CMS frameworks, a good part of the value is knowing which plugins do what, and how well they perform.

Drupal is an excellent small and medium enterprise CMS and that's where the majority of users are located. It will suit large enterprise use where the application is not expected to run the entire business in 50 countries.

Drupal bugs
All complex applications on this sort of scale have issues. Only a few drawbacks can be identified with Drupal:
  • The admin backend is not very good. It's the biggest let-down in Drupal. Text-based menus for admin - and especially poor ones like this - are a major negative. It needs a proper panel, not just for the sake of appearance, but because many issues are then cleared up due to logic rebuilding.
  • Drupal uses some weird naming conventions for content groupings - like book / story / page; together with a flexible way of organising content that is not intuitive.
  • In common with all other applications, as soon as ACL becomes capable then admin usability starts to degrade - this is a normal state and only to be expected. ACL makes any web server software harder to use.

There is a major problem with inter-version compatibility though: plugins often can't be transferred to the next version, due to incompatibility. A new plugin has to be built every time. In practical terms, this means an upgrade version is of reduced practical use value for around three months or more, till the plugins catch up.

Probably the biggest drawback to Drupal is the way it somehow makes things much more complicated than they need to be. Various things combine to make a webmaster's task harder than it should be.

Enterprise class CMS
There is a question over whether this is a true enterprise-level CMS or not; the answer probably being that it is in that class, but not yet a top performer. That is because an enterprise-class CMS must have granular ACL, full-feature versioning, capable workflows, audit trails and so forth. At the time of writing Drupal has these functions but perhaps not on a scale that would suit large enterprise use, though progress is very fast on this CMS and one might expect these features to be fully supported soon. These functions ideally need to be present in the core application, and cannot be added via plugins (such as full ACL), so the base application needs to be very capable - as Drupal undoubtedly is. Since these things can mostly be found in Drupal's core, it should be that much easier to extend them via plugins. Progress is bound to be slower with a naturally more complex application such as this.

ACL is good but not granular to the scale of eZpublish and Plone; versioning is very good though (referring to the fact you can revert to previous versions of a document, and there is a full record of who did what and when to it).

Because of the capability of this CMS, you can do some useful tasks with it that are unavailable to less powerful CM systems. You can set custom views of your data - for example, an admin page which lists all your content, with multiple attributes, such as creator, number of views, number of comments, date of last update, and so on. And the list can be sorted on demand by lowest or highest value of any column; like Excel for CMS content. A very useful feature for large sites with multiple content owners.

Example sites:

Compare Drupal v Joomla
[Joomla Drupal comparison]

A big question, this one - many people ask this because, in the end, a choice between these two fine CMS will be the final decision in a series of trials. You've eliminated the really hard to use applications - the ones with terrible SEO - the ones that will pan out too expensive - and the ones that need a Sun server running OS/2 and a servlet container as well...

And you're left with Drupal v Joomla, the kings of PHP CMS.

Each has clear advantages and disadvantages compared to the other. As ever, it will depend entirely what you intend to do with it.

The crunch question is ACL, followed by rich media support. After that comes high page numbers combined with heavy traffic levels. As far as ACL goes, Drupal wins out easily since Joomla ACL is best described as 'basic'. So, if there are to be multiple owners of content, Drupal is the better choice.

Turning to multimedia support, Joomla makes the running since there is no better CMS for this. If you want to run a video or music site - or anything vaguely similar - Joomla is the Big Daddy (there are around a hundred plugins just for streaming media, for example). For a very large site (how to define this depends entirely on your market since in one area that might be 5,000 pages, another 1 million), it is probably safer to use Drupal since it handles high page numbers better. For high page numbers plus high traffic, Drupal would be the best choice. For a smaller site with high traffic, Joomla is just as good - since pure traffic capability is a hosting question as much as anything.

Remember that these applications are both fairly compact PHP scripts, so there isn't a lot stopping them from churning out vast page numbers 24/7. Joomla will certainly handle 33k-plus uniques per day, for instance, which is the magic 1 million a month. And if one instance will do that, then double up your servers and you've got - a heck of a lot of traffic, for sure. It's a hosting issue - pick a host that knows about load-balancing. Joomla will burn through a terabyte of bandwidth a month, and so will Drupal. If you need that much, you can afford a decent host, a bunch of servers and some fancy load-balancing.

Drupal by default has a conservative appearance and it's the conservative choice. Joomla has more features than any other CMS, when you add in the vast range of plugins. But features aren't what you need to look at first - it's core capability that comes top of the list, and Drupal has the core strength. If you don't need too much in the way of ACL, Joomla will fit the bill, and it's much easier to manage; and usability for the owner has to count for something. Drupal is let down here by its clunky text-based backend admin panel, and its greater complexity doesn't help here. This can make it hard to work with at times, though experience helps. New users are not well served here, though. No CMS is 'easy' to use, but Joomla is one of the best due to the superb admin backend.

On appearance, it's Joomla I'm afraid. There are thousands of templates for it, all of which can be customised by the end user / webmaster - and this does not apply to Drupal templates, which need developer input in order to change. As regards style, it's Joomla all the way. Of course, custom Drupal templates will provide any solution required, as can be seen by the sites in the list of reference sites we have provided.

For style it's Joomla. For substance, though, it would be hard not to agree that Drupal has the core functions and the solid rep.

On the SEO for CMS question (you were waiting for that, weren't you?), there isn't much to choose between them. In theory Drupal is by far the better choice, for numerous reasons starting with the fact that it has a modern codebase layout, while Joomla's is Steam Age. However, in the end Joomla wins out by a fraction. The SEO for CMS question is based on how easy it is to fix the issues all dynamic sites have, and what the SEO score is in the end. It's Joomla by a neck.

Like many dynamic apps, both are poor out of the box, though Drupal is better. Both validate of course. Add your plugins and you can tune up the SEO to your heart's content. In the end Joomla has the advantage, but not by much. Remember that everything is done with plugins in this type of webapp, so the one with the most in this department might be the better choice - and that's clearly Joomla.

Don't forget, though, that poorly-coded templates and plugins will wreck the code and the search success for any CMS; and Joomla has the widest range of poorly-coded templates and plugins, for sure - only because of the statistics. If you have 4,000 plugins (and add 5,000-odd templates to that, for a total of approaching 10,000 add-ons for Joomla), then there are going to be a lot of duds. Choose wisely, validate as you go, check for poor code after each add-on is enabled - and you should be OK. So it's Joomla by a fraction here, though if you have good reasons to choose Drupal, there really isn't much in it.

There is a valid point that Drupal has a far superior code layout since it runs on the correct modern system of layers and CSS, whereas Joomla still uses tables in part. It's true that Drupal therefore has much more potential for those who know how to utilise the advantages; and Joomla is in desperate need of a code layout rewrite. However Joomla has some other advantages in the SEO department so it cannot be dismissed; and the number of people who would actually be able to take advantage of code layout for SEO is quite small.

There are many people who will dispute each and every point in the SEO arena, and good luck to them. I put clients at global #1 with their CMS, so I have my views on this, which can at least be proven. I'd choose Joomla in this race but there's not a lot in it. When Joomla finally gets it's long-overdue rewrite, to bring it into the 21st century, it will be very hard to beat. As cells and tables for code layouts became obsolete around 2002, this is well past the due date.

So: Joomla if you might be going the multimedia route and/or want something that looks impressive even with stock templates; Drupal if you have several content owners and need the most solid and reliable foundation.

If content management systems were professions, Drupal would be a star accountant and Joomla a rock star. You choose.

Drupal CMS - Tech Spec
cms type: multi-team /
basic enterprise cms
cost: free
license: OSS (GNU - GPL)


A CMS designed on the provider-consumer model. This refers to one person, or a small team, creating content for a large audience - like a normal website in fact. Because of the instant online editing of course, it's much easier to change content than with a normal website, like any CMS.

OpenCMS, based around the main dev in Germany, has a long and stable history. The app is written in Java, but the pages come out as .jsp or .html (there is a choice). In the past, pagecode suffered from an excess of JS but this has been cleaned up.

Probably because of the JS problem, they developed a static HTML solution - a client-side CMS in fact; you can generate an entire HTML site locally, then upload that to the server instead. Of course, you lose much of the interactivity that way.

OpenCMS will have to use a dedicated server (or one specially set up for this type of webapp), because it needs a massive Java installation on the server. Not only the J2SE at 130MB or thereabouts, but also the JSDK at hundreds of MB; AND a servlet app, Tomcat. This works out to an amazing 600MB or so - before the site is even installed.

Fine CMS; the codebase and dedibox don't make it universally appealing now. This CMS has a lot going for it, but there are obviously some drawbacks; the impact of the JavaScript has been reduced, but the server requirements are still a barrier.

There are still too many developers working with JS-based webapps as consumer tools - see this extensive list of Java-based CMS apps. Not one*, in the copious amounts of blurb displayed, mentions the file format of the pages it outputs. Search engines hate JS as it is a prime tool used in perverting the search results (and therefore for attacking them with); so if you are looking for commercial success, the level of JS has to be radically reduced.


[sic - the spelling as-is] 
The pagecode / fileformat is not only one of the most important factors - for a Java-based app it is the most vital factor of all, since if the pages by some chance major on JS, then the application does not seem to have a bright future. Java is of course not JavaScript - they are two different things - but it is a fact that Java webapps are more likely than most to feature JS strongly in the output pages. It's possible that search engines might do a major about turn, and start to like JS - but unlikely. There is a very good reason why .jsp pages are rare now.

Of course, it needs to be clearly stated that .jsp pages per se are not a problem - that would be ridiculous. It is because such pages, more than any other, are likely to have excessive JS on them; and that is a problem for search success.

*Correction: one app does mention their HTML page output prominently; but it turns out not to be a 'real' CMS (it doesn't use a database), so no doubt they needed something to shout about.

OpenCMS is a mature project, though with a smaller community than most projects of this type; but those who contribute here tend to be from the enterprise sector and are therefore a little more organised than most. As a result, documentation is good and there is at least one book on the system, which has been in print for several years and is updated frequently.

Compare CMS - Opencms v Joomla
[comparison joomla opencms]

Apart from the server requirements and some questions on the pagecode, it's a fine CMS. Also, it is a provider-consumer CMS, not a community-use CMS (qv community explanation). It would depend on what you wanted to do with it. Note that OpenCMS needs a massive Java installation on the server of the order of 600MB plus, before you can install it - so you are almost certainly talking about a dedibox. Joomla, in contrast, is the best wide-feature publishing tool there is (unless you are talking about huge page numbers), and with reasonable community-use features; also, remote install on a bog-standard server is a snap - so they are very different beasts.

There are also some questions about web standards, since it was not possible to find an OpenCMS reference site with pagecode that validated with the W3C - though this could in fact be due to incorrect implementation.
I tried hard to find a site with valid pagecode, but gave up after looking at 15 or so. This is not necessarily a fault of the core app, of course - poorly-coded templates and plugins can wreck the best CMS code. In addition, rather strangely, one or two of the portfolio sites* were of very low quality as regards pagecode, search compliance, etc..

*portfolio site = a reference site given at the central website, as an example of the finished results.


This OpenCMS site is an interesting example. Because it is so much worse than any other OpenCMS site around, we can be sure it is not a typical example. Just about everything has gone wrong here - so it is quite a good example of how not to do it. Again, this is no reflection on the core application. Take a look at the source code (and everything else) - no wonder Google doesn't like this site. It does beg the question, though: why on earth put this up as a reference site?  
http:// www.  icdsecurity. com/opencms/opencms/en/
[remove the breaks in the URL]

[please be sure to read the disclaimer at the end]


A Norway-based dev who is famous among PHP coders runs this. It's a semi-commercial CMS: the basic app is OSS but most of the plugins are commercial. It will cost about $5000 and up to get a nice site running, if you go commercial; free for DIY, if the focus is going to be narrow, so that you won't be needing much in the way of plugins.

The main coder is well-known because he has developed a new PHP handling system - an alternative to the Zend optimiser - so he obviously isn't stupid. That means, though, that you don't really want to put eZpublish on a shared box unless everyone else is going that route; an eZpublish website ideally needs to be on a dedicated server or one exclusively for eZ sites.

You can probably do anything with this CMS, since there are enough devs who work with it to sort whatever you need. Capable and stable, this could be the one if you need a large or stable CMS with full commercial backup. There are several devs employed on the core team, and many worldwide who support it. There are some very smooth commercial sites out there.

eZpublish would be a good choice if you need a powerful, stable CMS with a big commercial support community, that comes in at a fraction of the price you would pay for a big-name application like Vignette. You can find developers from South America to the Arctic. A rough guide to developer charges (which probably applies to many similar situations): London £500 - £1,000 per day; Scotland £400 per day; South America £200 per day.

high-quality CMS probably has the strongest ACL in open-source PHP CMS. It has a solid reputation and is an enterprise-class CMS. All in all, it is probably best to view this WCMS as a commercial application that just has a free site licence. For single-site implementations that require the best in ACL and will not be heavily extended, this will be a very economical solution. For large implementations with a lot of extensions and custom work, the site licence is not a major percentage of costs in any case, so the 'free' licence is not so important. In either case, eZpublish will be a more economical choice than its main commercial challengers, and superior to many of them.

There is strong ecommerce support and you will find developers who can implement very capable online stores using eZpublish. This would not of course be a low-cost option because both the ecommerce extensions and the developers are fully commercial. However, the bill would be substantially less than that from even the cheapest of the big commercial CMS vendors; and there are other advantages to this option as well. There are PHP developers everywhere, but the same cannot be said for TCL devs.


an ecommerce site -

Compare eZpublish v Joomla
[ezpublish comparison, ez cms comparison, comparison ezpublish joomla]

This comparison is a common request. eZ is semi-commercial, meaning the basic app is free but extensions usually aren't. That means if you just need basic functionality, then eZ will cost the same as Joomla, ie nothing. But this is very unlikely with a CMS, which is normally a fairly sparse framework that you add plugins to, to get the functionality you need. If you need a basic publishing tool with strong ACL, then it's eZ by a mile; but as soon as you need to add plugins, the costs will show a very big difference. eZ may be a more reliable bet for big page numbers; also, of course, if you are an enterprise with the funds to pay for a full implementation and support - and this is probably the major factor. There are support options for eZ on every continent. Joomla has all the features you need, at very low cost (or even free); but it doesn't have eZ's reputation for solid performance with big page numbers. Joomla certainly doesn't have the core functions that eZ has.

eZ should not be placed on a server with anything other than eZ products, since it uses a different form of PHP acceleration, and mixing with standard LAMP user apps is not a good idea. It's a LAMP-based application of course, but has its own special requirements.


The Big Daddy of open-source CMS. Will run a million pages; is used by household names; used by big online publishers; the code validates 100% out of the box; it validates with about 5 different bodies for code, accessibility, etc.; pretty much bullet-proof; and so on.

Essentially, Plone is a skin for Zope, which is both the core app and also an application server. However, this CMS is a hard to work with till you know the score - there is a very steep learning curve for the sysadmin; and even so, in the end, it is not user-friendly as far as backend admin is concerned. It is an odds-on favourite for the title of Most Complex CMS.

On the other hand, it has dead easy frontend editing for user / publishers - possibly the easiest and most bullet-proof of all. Will probably do anything or suit anybody, with sufficient dev work - and it would certainly take plenty of that to do anything more than the basic stuff. [but see *Plone Update - things are changing]

Doesn't do anything much out of the box - you would need a lot of Python dev work by some clever people to get anywhere with it. [Update: this is now incorrect as there are a good number of plugins] If you had the money - had 50,000 visits a day or more - had a nice strong dedibox - needed to put up 800,000 pages - then this might well do the trick. One for the big boys.

Plone outputs xHTML pages that validate absolutely no problem: out of the box they have short, basic HTML URLs (with no htaccess rewrites necessary). The URLs are the best you can get from any dynamic app, and look like a flat HTML site. Accessibility is unbeatable by any other popular CMS. It is a very fine CMS for SEO by any measurement.

Plone is basically a skin for Zope. Because it runs on this, using it as an application server, then you will need either a dedicated server or one that has other Plone / Zope sites on it. It wouldn't be a good idea to place it on a normal shared box.

Plone is
going to be on the short list for any large CMS install. Of one thing you can be absolutely certain: any large CMS you are considering actually paying for would have to measure up to this; and that's one hell of a task. Plone (and Zope) is used by major online publishers, and is a proven heavy-duty application.

It is very basic out of the box, as far as features go, but has the core structure you need for an enterprise-level CMS; and so capable that almost anything is probably possible - with time, money, and Python developers. Now the plugins are there, Plone is looking good.

*Plone Update: there have been a lot of changes in the last year or so. The core app is better, and the plugins are pouring in now - there are 700+ of them. An updated visual editor, Kupu, which looks even better than it was; a wiki; a forum or two; even a basic shopping cart now. And DC metadata if you want it, I saw on one site. Plone 3 is looking good. With the powerful feature set, Plone looks a very strong candidate for a dedicated server CMS, with full ACL, that will handle high page numbers and high loads.

We'd like to hear your experiences with Plone 3, good or bad,and would appreciate any comments - please email us. We'll put your comment here and a link (or two) of your choice. Same goes for any CMS reviewed.

Plone as a LAN CMS

Another pointer to just how slick Plone is - especially compared to some others - is the faultless one-click Windows installer. This is a snap for local dev work, or even a LANserver CMS. Installed size by this route is 250MB, to start. Not small, but about what you'd expect at this level of capability. Using this method, Zope acts as the built-in server (you don't need a server app such as XAMPP if you are simply running a LANserver). For production, though, Plone sits behind Apache, with Zope as an application server; you then get Plone - Zope - Apache. This provides both security and caching benefits.

Very slick; well-developed; fairly basic out of the box, but a strong feature set. Now the plugins are starting to roll in, Plone is looking even more impressive. Plone is not easy to work with and requires experts to set it up correctly; this applies even more to extending it, since this requires expert Python devs who are also Plone specialists.

It has been criticised in the past - like every other CMS on the planet of course - for various reasons that are either obsolete now, with Plone 3 in its new format and with so many plugins; or that don't hold water because of the developer's own lack of ability.

This last point is not to be overlooked - you absolutely cannot trust even experienced developer's opinions, as so many of them obviously haven't a clue about real-world requirements. Look at how many have never heard that JavaScript is a major tool used for attacking search results, and is therefore hated by search engines and cannot be used extensively now on-page; and how many are still trying to produce yet more JS-based CMS. Or, developers who say SEO for a given CMS is not good; but we get #1 search positions with it all the time. Or how about the 75% of developers who don't even validate the page code after working on a page / site / extension? (We have to clean up after these people every day).

The obvious and inescapable fact is that a large proportion of developers just don't know what they are talking about. You need to look at a consensus of opinion between developers who are expert on a particular CMS, and expert users.

Plone database
The application has its own DB built-in, the ZODB. It can also be plugged in to various other common-format databases with an adapter. Due to the built-in DB and built-in server, it installs faultlessly with one click on a Windows PC without a server app, perhaps for office LAN CMS use.

Plone documentation
Not bad - there are a couple of books and/or PDFs out there, so you'll have a manual to work with. Also, Zope has plenty of documentation as well, so things are reasonably well-covered. Without the manuals, I have to say you'd be pretty well stymied - even a quarter-bottle of brandy and ten aspirins wouldn't fix that headache.

NASA Maestro Mars lander project:

Government of Brazil:


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

PLEASE NOTE: these critiques represent an entirely personal opinion. They are personal opinions that may be factually incorrect.

There are some negative views expressed here that are one person's opinion and may be entirely wrong. There are positive opinions here that may be equally wrong. There are obviously many people who are entirely satisfied with webapps that have been criticised in some way, and you should ask some of them before taking this material at face value. There may also be those who are unsatisfied with CMS apps, or aspects of them, that have been praised.


You can write your own User Review of any CMS, and WE WILL PUBLISH IT as long as it is balanced. We don't do whitewash jobs here - we tell it like it is. If you think you can do better then write the review. Remember that our viewpoint is Usability and SEO for CMS - we zero in on how easy the application is to use, and how efficient it will be for earning web income. You can take another viewpoint if you wish.
Web Business Managers