|
Did you find this page useful? If so, please consider linking to it
- or use the bookmark facility at bottom right. Thank you.
Compare CMS - Part 3a - Business CMS Reviews
Page 3a - the second page of 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 CM systems 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 presumably had the budget for a full-commercial solution. DrupalOpenCMSeZpublishPlone
Need to ask a more detailed question? Try the new CMS Forum.
[please be sure to read the disclaimer at the end]
_______________________
The Business CMS Section
_______________________
Drupal
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. 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 far less flexible than Joomla for instance - but probably
more stable. 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 ther yet.
As a personal opinion, we reckon that a CMS needs to have 2,000 plugins available before it can be called 'highly-extensible'. It's 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. That 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 that number of jobs with them; and even 250 functional choices would be something of an optimistic view here.
Like all the popular
CMS projects, most 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) and therefore become an even better prospect
for all-round online publishing, especially considering its solid
reputation.
Only two or three drawbacks can be identified with Drupal (which
is actually a good score, comparatively): the admin backend is not very good; and they
use some weird naming conventions for their content groupings - like
book / story / page. Its strengths are the fine content item management
possibilities, stability, security, robustness and extensibility.
Multi-site capability is reported as good though we haven't tested it.
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 close, but not fully-compliant. 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 does not fully comply here, though progress is very fast on this CMS and one might expect these features to be fully supported soon. Some of these features have 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, and also 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).
Example sites:
www.mtv.co.uk
www.usmagazine.com
www.falanx.hu
www.yogaforgeeks.com
www.spreadfirefox.com
Drupal CMS - Tech Spec
cms type: basic enterprise / multi-team cms
cost: free
license: OSS (GNU - GPL)
OpenCMS
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.http://java-source.net/open-source/content-managment-systems[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.
Documentation
OpenCMS is a mature project, 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. Examples:http://www.intersport.comThis
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]
eZpublish
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.
Examples:
www.gerleinorthodontics.com
www.santillana.com
an ecommerce site -
www.alconeco.com
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, 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. 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 - 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.
eZ
should not be placed on a server with anything other than eZ products,
since it uses a different form of PHP interpretation, and mixing with
standard LAMP user apps is not a good idea.
Plone
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. A
pig to work with till you know the score - a very steep learning curve
for the sysadmin. On the other hand, it has dead easy front end 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 (x)html 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 may be the best CMS for SEO
that there is.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; but 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.Haven't
tried the new version, Plone 3, 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 here.
Plone as a LAN CMSAnother
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 documentationNot
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.Examples:NASA Maestro Mars lander project:http://mars.telascience.org/homeGovernment of Brazil:www.brasil.gov.brwww.oxfam.org/en/www.akamai.comwww.chicagohistory.orgwww.nierstichting.nlhttp://trolltech.com
PLEASE
NOTE: these critiques represent an entirely personal opinion. They are
personal reviews. 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 MUST TRY THEM AND MAKE UP YOUR OWN MIND.
|
Compare CMS - 3a 
