Wp smile cms-julio2011

Content
Management
open source solutions
2010 edition

By Grégory Bécue

Version 4

Further information: www.smile.fr
Tel: +33 (0)1 41 40 11 00
Email : sdc@smile.fr

CMS, open source solutions

[1] PREAMBLE

[1.1] Smile
Smile is a company comprised of engineers specialising in the implementation of
open source solutions and the integration of systems based on open source solutions.
Smile is a member of APRIL, an association focused on the promotion and protection
of free software.

With over 320 employees in France, and 390 throughout the world (June 2010),
Smile is the leading French Open Source solution company.

Since around the year 2000, Smile has been actively monitoring the technological
market, allowing us to identify, to test and assess the most promising open source
solutions. We can then present our clients with the strongest, most sustainable,
most efficient products available.

This approach has given way to a whole range of white papers covering various
different application sectors. Content management (2004); portals (2005); business
intelligence (2006); PHP frameworks (2007); virtualisation (2007); digital document
management (2008); and ERPs (2008). Among the works published in 2009, the
“Open Source VPNs”, and “Open Source flow controls and Firewalls” articles, within
the “Systems and Infrastructures” collection are also of interest.

Each of these works offers a selection of the best open source solutions in the
relevant domain, their respective qualities, and feedback on operational use.

As stable open source solutions slowly gain ground in new sectors, Smile will be
present to offer customers the benefit of these solutions risk free. Smile appears in
the French I.T. market as the integration service provider of choice, to assist major
companies in adopting the best open source solutions.

Smile has also developed a range of service offers over the last few years. A
consultancy department has assisted our clients since 2005, through preproject
phases, solution research, and project support. In 2000, Smile created a graphics
studio which in 2007 became known as The Interactive Media Agency. This agency
offers not only graphic design services, but also e-marketing, editorial, and rich
interface expertise. Smile also has an agency specializing in Third-party Application
Maintenance, application support and application processing. Smile offices can be
found in Paris, Lyon, Nantes, Bordeaux and Montpellier, with presence in Spain,
Benelux, Switzerland, the Ukraine and Morocco.

© Smile – Open Source Solutions - All unauthorised reproduction is strictly forbidden


[1.2] Some Smile references

a) Web sites

Laboratoires Boiron, Foncia, Crédit Coopératif, EMI Music, Salon de l’Agriculture,
Mazars, Areva, Société Générale, Gîtes de France, Patrice Pichet, Groupama, Eco-
Emballage, CFnews, CEA, Prisma Pub, Véolia, NRJ, JCDecaux, Larousse, 01
Informatique, Spie, PSA, Boiron, Dassault-Systèmes, Action Contre la Faim, BNP
Paribas, Air Pays de Loire, Forum des Images, IFP, BHV, ZeMedical, Gallimard,
Cheval Mag, Afssaps, CNIL…

b) Portals and Intranets

Eurosport, HEC, Bouygues Telecom, Prisma, Veolia, Arjowiggins, INA, Primagaz,
Croix Rouge, Invivo, Faceo, Château de Versailles, Ipsos, VSC Technologies, Sanef,
Explorimmo, Bureau Veritas, Région Centre, Dassault Systèmes, Fondation
d’Auteuil, Korian, PagesJaunes Annonces, Primagaz…

c) Electronic Document Management and ECM

Agefiph, Primagaz, UCFF, Apave, Géoservices, Renault F1 Team, INRIA, CIDJ,
SNCD, Ecureuil Gestion, CS informatique, Serimax, Véolia Propreté, NetasQ,
Corep, Packetis, Alstom Power Services, Mazars…

d) E-business

Furet du Nord, Camif Collectivité, La Halle, De Dietrich, Adenclassifieds, Macif,
Gîtes de France, GPdis, Longchamp, Projectif, ETS, Bain & Spa, Yves Rocher,
Bouygues Immobilier, Nestlé, Stanhome, AVF Périmédical, CCI, Pompiers de
France, Commissariat à l’Energie Atomique…

e) Business Intelligence and ERP

Lafarge, Groupe Accueil, Anevia, Projectif, Xinek, Companeo, Advans, Point P,
Mindscape, Loyalty Experts, Cecim, Espace Loggia, Nouvelles Frontières, France24,
La Poste, HomeCineSolutions, Vocatis, Skyrock, France Domicile, Polyexpert,
Cadremploi, Cmonjob, Meilleurmobile.com…

f) Infrastructure and Hosting

Kantar, Pierre Audoin Consultants, Rexel, Motor Presse, OSEO, Sport24, SETRAG,
Canal-U, Institut Mutualiste Montsouris, ETS, Ionis, Osmoz, SIDEL, Atel Hotels,
Cadremploi, Institut Français du Pétrole, Mutualité Française…



[1.3] This White Paper
This document goes beyond a simple comparative study of Open Source Content
Management Systems (CMS), to present an introduction to the fundamental
concepts of CMS and the implementation of these systems. Content Management
Systems must be selected based on the specific needs of the client, and not just on
the tool functions.

With this in mind we offer our analysis of the issues that arise in this area and the
capabilities (in relation to each fundamental concept) which differentiate one tool
from the other.

Following this analysis, we will attempt to bring to light the capabilities of each
CMS studied, in relation to different needs.

[1.4] Versions

[1.4.1] Version 2.1
The first version of this white paper dates back to 2004 and has been downloaded
over 10,000 times. Version, 2.1, is a major overhaul of our initial report.

First off, we eliminated Redhat CMS from our panel of solutions, for a
number of reasons: Redhat is now Byline under the responsibility of the ObjectWeb
consortium, but the transfer is far from finalized, and development seems to have
come to a standstill. Furthermore, ObjectWeb already has a portal and content
management solution with the recent integration of eXoplatform, a more dynamic
project. In this context it seems difficult to believe that this seldom-used solution
will last very long.

On the other hand we included, Apache Lenya and InfoGlue, two Java
environment products which meet very different needs. These are two quality
solutions which have already proven popular with clients, allowing to complete the
J2EE Open Source product range, which had been relatively limited up to this.

Finally, we redrafted our comments to take the important developments of the
various solutions into consideration. Typo3, in particular, which had greatly
evolved, with TemplaVoila extensions for content structures, and the version
management and workflow extensions that were so sorely lacking. OpenCMS also
delivered some excellent developments in relation to content structuring in its latest
version, while eZ publish delivered an impressive range of improvements in
versions 3.6, and 3.7.



[1.4.2] Version 3.0
Over 25 000 downloads later; version 3.0 brought a new major update of this white
paper. We felt it was necessary to include two more tools in the already large range
of solutions covered in our study. Joomla and Drupal are very widely-used tools
with active, productive, communities. The strengths of these solutions lie in the
simplicity of their installation, configuration and use, resulting in great success
among associations, individuals and small business.

These tools have proven their stability and maturity. While they do offer a few
advanced features, in their overall simplicity these tools provide an alternative to
more complete solutions which sometimes prove complex to implement.

We have taken both Cofax and PHPNuke out of the study, as they are no longer
actively maintained and as such their functionality is now less complete than that of
other solutions.

Other tools have also benefited from a number of improvements since the previous
version of this white paper. For example:

 eZ Publish 3.9: now supports clustering, advanced Multilanguage
management, Single Sign-On, etc.
 Typo3 4.1: work spaces, front office access control, etc.
 InfoGlue 2.5 image editor, web services, new identification modules, etc.
 Jahia 5 : Ajax Back-office, new portlets, XML Import /Export, specific multi-
level workflows, JSR168 compatibility, metadata, FCKEditor, hibernate, ESI
cache, clustering, …

[1.4.3] Version 4.0
After a further 20,000 downloads, this greatly revised edition is the most up-to-date
version of our white paper on Open Source CMS.

Before discussing products, we decided that an update on the fundamentals of
content management was required. Expectations have evolved, and a number of
elements which had been on the fringes have now become standard features of the
Open Source solutions studied herein.

The basics are now centred on 4 main themes: structuring content, manipulating
content, using content, and securing content. We also include an analysis of the
technical framework which is a less functional but equally important aspect,
especially in the creation of professional web sites which generate major traffic.



As regards products, the same names appear at the top of the list: Drupal, eZ
Publish, Infoglue, Jahia, Joomla, OpenCMS, Spip & Typo3. They have all evolved
well with an improved functional scope and strengthened technical framework.
Apache Lenya is the only solution to be removed from our study, as though it has a
good architecture and does not require databases (XML files); the user interface is
poor and only suitable for users with good technical expertise.

We have added the “loaded CMS” section which presents the content management
components (portal, ECM) included in solutions other than CMS. These may well be
tangible alternatives in the coming years.

Finally, we have integrated a “Promising solutions” section which, as the name
would indicate, lists some excellent solutions which haven’t yet reached maturity
and which won’t be long in finding their niche in the market. They often place the
emphasis on their differentiating aspects: handling, scalability, architecture, etc.

[1.5] The CMS
It is now generally accepted that one must be able to manage both Intranet and
Internet web sites in an interactive manner. That is to say that an interface must be
available which allows administrators to define new pages and new sections, to
manage updates and to reorganise information.

But beyond the specific needs of a given site, certain companies identify the need to
constitute and administrate a content repository, on which different publications will
be based, both on the web and on other media.

Naturally, lots of tools may meet this need. In the CMS product range we can
distinguish between:

 Simple, ready-to-use products focused on web site management, generally with
limited extension possibilities,
 And, more high-end products which allow to build a real content repository at
company level to define the associated management processes and reproduce
content on a variety of media.

The first area, that of integrated CMS, is completely covered by Open Source
products such as Joompla or Spip. These products are of such a high standard that
no proprietary solution can rival them.

The second area, that of high-end CMS solutions was, historically, covered by
commercial products such as Documentum, Vignette or Interwoven. Today however,
solutions such as Jahia, eZ publish, Typo3 or Infoglue, provide similar if not better
scope. These solutions have become over time real alternatives in the area of
Enterprise Content Management.



Since 2001, Smile has acquired exceptional expertise in the area of content
management and excellent knowledge of the best Open Source solutions on the
market.

It is for this reason that we initially decided to compile this White Paper, in order to
share our knowledge and experience.

We have been severe in our choice of solutions, so that only really quality products make
the cut. This allows the client to select a tool based on their individual needs, safe in the
knowledge that the tool is a reliable one.

[1.6] Open Source CMS
A Gartner Group concluded that as regards content management, “today people
don’t see why they should pay for expensive leading commercial products, and are
looking for low-cost alternatives”.

Analysts agree that the advantages of Open Source solutions are not merely
financial. Content management, by its very nature, requires an ever-increasing
number of modifications. Plugins help developers to safely create new functions such
as the definitions of new types of content, workflows, etc., something which cannot
be achieved using proprietary solutions.

All kinds of companies have now chosen to use Open Source CMS and large
companies in particular, as Smile testimonials reveal. Companies often take a look
at the alternatives, including Open Source solutions, when a project is being
completely restructured or when the support contract of a proprietary solution in use
for a number of years, is due for renewal. At this stage the benefits of Open Source
solutions, such as the financial savings, come to light.

[1.7] Viability, support
When we choose a product on which to build all or part of the information system,
the question of viability or durability is often even more important than the list of
capabilities.

Open Source solutions offer two important advantages in this respect:

 The products survival does not depend on its profitability or marketing
considerations. As long as there is community interest, the product will
continue to exist.



 The free nature of sources guarantees the durability of the product, though we
must stress the importance of the client companys’ competence to manage this
source code.

One must keep in mind that proprietary CMS solutions depend entirely on their
editors. Editors who can go out of business overnight, leaving their customers
stranded, with no choice but to rebuild their sites immediately using a different tool.
There have been numerous cases like this over the past few years, and not the name,
editor, licence nor even client list can guarantee the viability of the product.

Though the Open Source nature of a product does not guarantee that it will exist
eternally, and some solutions will slowly loose the interest of their community, one
thing is certain: an Open Source solution will never disappear overnight,
furthermore a company that builds its project around an Open Source solution has
access to the source and as such can ensure that their system lasts for a least
number of years.

The specific type of support available with Open Source solutions is now broadly
recognised. There are generally two to three different levels of support.

On the one hand we have the support of the community, the activity of which is
based around a given site where downloads and source code are available (together
with the roadmap, a directory of known bugs, and support mailing lists). This
community support is non-contractual, but very strong nonetheless.

This support can be complemented with contractual support from companies such as
Smile.

More and more editor solutions are appearing alongside real Open Source
community solutions; these solutions are from commercial profit-driven companies
who have chosen to release certain solutions under Open Source licence. The free
distribution of these solutions allows these editors to make their solutions as well-
known as possible, and their business model is often based on the support and
consulting services associated with these solutions.

These companies generally offer product support and/or product guarantees
(unlimited management of kernel bugs).



Content
[1] PREAMBLE.......................................................................................................2
[1.1]SMILE............................................................................................................................... 2

[1.2]SOME SMILE REFERENCES........................................................................................................ 3

[1.3]THIS WHITE PAPER............................................................................................................... 4

[1.4]VERSIONS........................................................................................................................... 4

[1.5]THE CMS......................................................................................................................... 6

[1.6]OPEN SOURCE CMS............................................................................................................. 7

[1.7]VIABILITY, SUPPORT................................................................................................................ 7

[2] OPEN SOURCE CONTENT MANAGEMENT SYSTEMS ......................................10
[2.1]OUR SELECTION.................................................................................................................. 10

[2.2]OTHERS........................................................................................................................... 17

[2.3]CMS COMPONENTS............................................................................................................. 19

[2.4]PROMISING SOLUTIONS .......................................................................................................... 20

[3] THE FUNDAMENTAL CONCEPTS OF CONTENT MANAGEMENT .....................21
[3.1]STRUCTURING CONTENT ........................................................................................................ 21

[3.2]MANIPULATING CONTENT........................................................................................................ 32

[3.3]USING CONTENT.................................................................................................................. 41

[3.4]PERMISSIONS AND ACCESS SECURITY ..........................................................................................56

[3.5]TECHNICAL PLATFORM........................................................................................................... 61

[4] SUMMARY......................................................................................................68



[2] OPEN SOURCE CONTENT MANAGEMENT SYSTEMS

[2.1] Our selection
In this section we introduce our selection of the best CMS currently available. We
have based our selection on our content management savoir-faire, our
implementation experience, and client feedback.

Other solutions do exist and some definitely merit a second look; please take the
time to read the paragraphs further on in this White Paper which present other
alternatives.

The solutions below meet most of the requirements established by the Smile
monitoring team – for example: ease of handling; a solid, proven technical
framework; a dynamic community; etc.

[2.1.1] Drupal
Drupal is a multifaceted CMS. Originally designed to serve as a collective blog, it is
now used in a whole range of situations: serving corporate sites to community
portals, to Intranets and even ecommerce websites.

The strength of this CMS lies in its extendibility. Numerous modules can be
added easily (forums, photo galleries, surveys, forms, newsletters, messengers,
chats, online payment solutions, shared agenda, etc.). It includes some highly-
regarded community modules. Further modules are relatively easy to develop given
that the syntax is accessible.

Administration is a specific feature of the product; a single interface provides
consultation (the front office) and site administration (the back office)
features; something that is particularly well-appreciated by those with limited
technical experience.

At content management level, Drupal falls somewhere between Spip and eZ Publish.
A complimentary module (CCK) allows to easily create types of structured
content (native in version 7).

At content organization level, Drupal is different in that it operatres using
keywords (tags - taxonomies) and not a tree-structure, like most CMS. What might
seem a little disconcerting initially actually turns out to be really useful.



Drupal integrates a very flexible PHP template system, management of user
permissions, multi-positioning of content, together with search and statistics
features.

At performance level, Drupal offers excellent results notably in stand-alone mode. It
constitutes a real alternative to “high-end” CMS, for purely editorial sites in
particular.

The version considered in this study is version 6.16

Smile has deployed Drupal on several occasions for clients such as : NRJ-Studio,
Diester, Alban Muller, BibNum (Cerimes), CDC Biodiversité, L’Equipe, GPSA,
Bastide Diffusion, Autorisé de la Concurrence, ESTP, Université d’Orléans,
Fondation EADS, INSA, etc.

[2.1.2] eZ Publish
The main aspect which differentiates eZ Publish from other Open Source
solutions is its configuration and extension capabilities: it is presented as a
ready-to-use tool but also as a development framework allowing to create business
applications.

eZ Publish is one of the most powerful Open Source tools in relation to the
fundamentals of content management: structured content, categorisation,
version management, etc.

eZ Publish allows to create online content types. “Minutes of meetings”,
“News” or even “Cataloguing” content types can be created in a just a few clicks, and
using forms. First piece of content is composed of a title, project name, date, list of
participants, a body of text, etc. The second only contains a title and small amount of
text. The third is more complex.

eZ Publish pushes the object approach to the limit, making each piece of content an
object and applying all possible methods to same object: multi-positioning,
versioning, multilingualism, relationships between content, access permissions, and
workflows. This makes eZ Publish a highly configurable CMS.

The eZ Publish CMS offers a number of options for the integration of
content: basic forms, multiple-uploads, WebDAV access, frontend editing, Open
Office document loads.

From a technical point of view, eZ Publish is written in PHP, on Apache & MySql
(PostGreSql 8 & Oracle 11g are supported), manages three different caches and
distinctly separates form and content (layout and content).



As regards search capabilities, eZ Publish interfaces with the Open Source search
engine Solr; it returns pertinent results in very rapid response times.

The version considered in this study is version 4.3.

Smile has deployed eZ publish on over 100 projects, including Foncia, CFnews, Fia-
Net, Afssaps, Evian Masters, Gallimard, BFM, Bouygues Telecom, Mazars, Yves
Rocher, Groupama, Patrice Pichet, EMI, Voyages-Sncf, Eurostar.com, INRA, OSEO,
Sport24, De Dietrich, Prisma Presse, Femme Actuelle, Elle, Gîtes de France, Hachette
Filipacchi, Suez environnement, Amnesty International, National Geographic,
Automobile Magazine, Forum des Images, Ordre des Pharmaciens, etc.

[2.1.3] InfoGlue
InfoGlue is a tool that originated in Sweden. It has a number of interesting features:

Technical advantages: InfoGlue is developed in Java, and can use any MySQL,
Oracle, Microsoft Sql Server or DB2 database. InfoGlue integrates the Pluto
Open Source portal tool, which allows it to accept extension modules. As regards
workflows, InfoGlue integrates the OpenSymphony Open Source tool, which
allows it to configure any business process in XML.

Functional advantages: InfoGlue allows to define new types of content and
categories without development, two essential high-end content management
functions.

The latest version of the CMS, version 3.0, is eagerly awaited and it’s improved,
more user-friendly, graphic interface in particular.

In the meantime, version 2.9.7.1 consolidates existing functions offering an
extensive range: text editor, multi-sites management, page publication on a given
date, page and tree-structure versioning, batch publication, personalized reports,
etc.

Though the project was launched in 2003, it remains relatively unknown in France;
it is implemented in Universities in particular.

In the Java world, InfoGlue is a solution which filled a niche in the Open
Source market. Easy to install, easy to use, configurable and extendible, InfoGlue
meets a number of web site needs, but is also an excellent solution for the
management of company content repositories.

The version considered in this study is version 2.9.7.1



Smile has integrated the Infoglue solution on several occasions: Xinek, Oncoval, K
par K, Lapeyre, Nouvelles frontières, Université de Pau, Université de Bordeaux 3 &
4, etc.

[2.1.4] Jahia
Jahia is a Franco-Swiss product, which has a special place in the world of portals
and JEE CMS, in two respects.

In terms of licence first of all. There is a real Open Source “Community” (GPL)
version, but this is not the version which is most commonly used. Annual Production
Subscription is obligatory for professional developers. This provides: the right of
annual use of company versions, correction of bugs, production support, etc.

Secondly in terms of it’s position, as Jahia is one of the rare solutions which
brings together the JEE portal and content management, perfectly
integrated in one single product.

Jahia is an excellent alternative to the portal solutions offered by leading editors,
the fact that Jahia source files can be accessed and modified ensures that the
product can meet client needs, while also ensuring the durability of the product.

As mentioned earlier, the strength of Jahia lies in its ability to bring together the
CMS and portal in one perfectly integrated, easy-to-use package. Compliance with
technical standards and the standard JSR 168 (& 286) in particular, offers real
compatibility and the capacity to integrate “portlets” (third-party or specific), giving
access to internal company applications.

Jahia is ready-to-use and implementation generally doesn’t necessitate any
development (apart from its integration). Freely available to download, Jahia is
most impressive as regards its finish and packaging: it is installed and ready-for-use
in a matter of minutes.

The Jahia content administration interface, blended into the site itself,
differentiates Jahia from other CMS. Once identified, you have access to add, modify
and delete functions, directly on the site, within pages and menus. This
management mode really simplifies processes for the administrator, who can view
the information on the site directly and instantly see where it needs to be modified.

At functional level, Jahia is one of the most complete solutions offering: multi-site
management, versioning, efficient workflows, structured data, multilingualism, very
specific management of permissions, etc. Version 6 has notably delivered an
excellent user interface via Ajax.

The version considered in this study is version 6



Smile has implemented the Jahia portal for Bouygues Immobilier, BNP Paribas,
Valorissimo, Arjowiggins, Beauté Prestige International, Veolia Eau, Eutelsat, Egide,
Académie de Rennes, Conseil Régional d’Ile de France, SANEF, Groupe COLAS,
Adoma, Fondation d’Auteuil, Académie de Créteil, IRP Auto, Pimkie-Diramode,
AFNOR, OCP, Vinci Energies, Conseil Général de la Côte d’Or, Diagnostica Stago,
Conseil Régional du Centre, Conseil Supérieur du Notariat, Macif, and La Poste,
among others.

[2.1.5] Joomla
Joomla is a CMS developed from Mambo. It was created following a falling out
between the main developers and the company coordinating development. Today,
the majority of the community developers are focused on Joomla, which decidedly
tips the scale in its favour.

The most distinguishing element of this tool is probably the conviviality of its
administration interface. The emphasis being on “giving non-techies total control
of the product”. Page creation, categorisation, search, access statistics, significant
URLs, are integrated together with a number of modules, and these do not require
any specific technical expertise for their implementation.

Nevertheless, Joule does not allow to natively manage different types of content, and
cannot be used for advanced content structuring needs (even if a plugin does exist
allowing the implementation of structured content).

This CMS is perfectly adequate for personal sites and to meet the needs of certain
professional sites; for example corporate type sites (basic publications).

The version considered in this study is version 1.5.15



[2.1.6] OpenCms
OpenCms is an Open Source CMS edited by the German company Alkacon. It a
broadscale, solid product - the result of a great deal of development work.

The latest version, 7.5, offers a number of functions: structured content, batch
publication, publication on a given date, a content editor, management of links,
WebDAV, management of permissions, etc.

OpenCms is built on a specific Java framework, with a view to extendibility. As
such, while the basic functions are ready-to-use, advanced implementations require
development by way of extensions.

One of the features of the tool is a back office with graphics that are practically a
reproduction of a Windows interface: tree-structure, contextual menus, dialogue
boxes, etc. The interface though very attractive from an aesthetic point of view, is a
bit heavy to use. The tool has allowed to edit content in the front office since version
6, (without having to go through the back office). But this use is still limited to very
straightforward edits, and not for total administration of content.

OpenCms has excellent corporate site references, the majority of which are from
German companies.

Here are some examples of the companies who have chosen to use OpenCms: Alice
DSL: www.alice-dsl.de, Bonduelle Germany: www.bonduelle.de, Fujifilm France:
www.fujifilmgraphic.fr, Intersport International: www.intersport.com, etc.

The version considered in this study is version 7.5.2

Smile has implemented OpenCms for l’UDF and Editions Francis Lefebvre.

[2.1.7] Spip
Spip includes all of the main features that one would expect with a CMS. Spip was
originally used by web-users to manage their personal site, or by associations for
their sites, but Spip continued to develop and is now used by both private and public
entities to manage their professional web sites. Spip is a French Open Source
project, with an active community, hundreds to thousands of members. Several
versions of the solution are released each year.

Spip is one of the rare CMS which can boast thousands of users throughout the
world. This success is explained by the simplicity of the product: it is easy-to-
use, but beyond that is easy to deploy and easy to adapt.



The downside to this simplicity is that Spip presents some limitations as regards the
main content management functions, which obviously limits it to the world of ‘web’
oriented content management tools, as opposed to ‘enterprise’ oriented CM tools. An
interesting Spip feature is its totally multi-lingual administration interface,
translated into over 20 languages, including Arabic, Esperanto, Russian, and even
Chinese.

The Spip-Agora project, sponsored by a French government department, was
developed concurrently with Spip. The idea of Spip-Agora was to add functions to the
Spip project in order to use Spip for administration purposes on complex projects.
Having enhanced the product, the Spip-Agora project ceased to exist and is no longer
supported (as of May 2008).

Almost 2 years after the 1.9.2 version was released, Spip brought out version 2.0,
giving the project a new lease of life. This new version offers a number of new
features: the possibility of installing PostSQL and SQLite on top of MySQL, a
simplified private interface based on Ajax, a download & plugin installation page,
troubleshooting management, API and new functions for the development of
templates.

The version considered in this study is 2.0.10

Smile has used Spip for several sites, including the Spip site generator for delegations
of the French Red Cross, the Fratel site, réseau francophone de la régulation des
télécommunications, ANCV, Evian masters experience, or more recently the Secours
Catholique.

[2.1.8] Typo3
Typo3 is the fruit of several years of work from the Danish guru Kasper Skårhøj. A
highly active community has developed around the product in Germanic countries in
particular, since its launch in 2000.

In terms of ready-to-use functions, Typo3 is one of the most comprehensive
tools that we have found to date. It offers practically everything one could wish
for, all the while providing an excellent finish. Management of contributions &
permissions, cache, layout, templates, etc., it’s all there, with very few limitations.

Among the functions Typo3 has to offer, we found the image editor to be of particular
interest, allowing to resize images, create thumbnails and dynamically generate
titles as images.

One of the greatest strengths of Typo3 lies in the extendibility of its modules.
Modules can not only add a range of functions to Typo3, but also modify existing
functions that are already integrated, without modifying Typo3 code, leaving it
compatible with future versions of Typo3.



Several thousands of companies already use the product, as indicated on
the community site. In France, Smile has already implemented Typo3 on over 100
sites, while also training and supporting numerous other integrators.

For example, Dassault Systèmes choose typo3 for their Intranet, giving Smile the
opportunity to work alongside Kasper on this ambitious and exciting project.

The version considered in this study is version 4.3

Smile implemented Typo3 for the CNIL, Dassault Systèmes, Eco-Emballages, Areva,
AMUE, Archimag, BHV, Armée de l'air, IPSOS, CCI, Polytech’Savoie, PCI, Projectif,
Spie, Faceo, Institut National de l'Audiovisuel, Cidil, RATP, Souriau, Prolea, PSA
Peugeot Citroën, Crédit Coopératif, Château de Versailles, SAS, ETS Europe, Agence
de l'Eau Seine Normandie, Glamour, Jaccede.com, IUFM Créteil, Conseil Régional
d’Ile de France, ODIT France, AFPA, Action contre la Faim, Arvalis, Comexpo,
CORA, MGEN, World Water Council, Société Générale, Immovalor, Legris
Industries, Agritel, My Coop, Gefco, Salon de l’Agriculture, INVIVO, Cidilait, and
many more.

[2.2] Others
A number of other CMS solutions also exist apart from those mentioned; Mambo,
Apache Lenya and Zope are 3 solutions that featured in our previous studies. Here is
a quick review of these products.

Mambo, Joomla’s “predecessor” is a relatively complete site management tool. As
with other tools of this type, it has a number of ready-to-use modules which are
practical for community sites: guestbook, forum, photo gallery, blog, etc. Its ease of
access allows even non-techies to create graphically pleasing sites.

The latest Mambo version, version 4.6.4, was released in July 2008. The project
seems to have come to a standstill as most of its contributors have gone over to
Joomla.

Apache Lenya is a tool which really stands out in the world of content
management. Integrated by the Apache Foundation, it comes from the Wyona CMS
product, of Swiss origin.

Lenya is a content and document management software product, developed in Java,
based on the Cocoon framework, which manipulates XML content.



One of the distinguishing features of Lenya is that all of the data that it manages is
stocked in XML files. Even structure information, such as on groups and users, is
managed in XML files. Lenya does not require a database to function. XML files are
organised into a tree-structure and are displayed in HTML – or another format –
using XSL style sheets. XML content modifications (the schemas of which are
modifiable) are carried out by rich graphic editors integrated into the web interface,
resulting from different Open Source projects.

Its distinctive architecture can be useful to specific needs (no database for example)
but its range of functions together with it’s difficulty of use, has put off more than
one contributor in favour of one of the excellent solutions offered by the competition.

Finally, we can’t talk about CMS without mentioning Zope and risking the wrath of
the products numerous fans!

Zope is a very complete server application, which goes well beyond the function of a
CMS. Everyone is in agreement that the only major fault of this tool is its
construction on a Python environment. Python development and maintenance
expertise is rare, which is the reason that we have decided not to include Zope in our
study. We have chosen solutions where the native functions can be completed and/or
modified as necessary. Furthermore, the progressive abandoning of this environment
has been confirmed by the main promotor Nuxeo’s decision to cease using Zope CPS,
despite the release of a new version.



[2.3] CMS components
Beyond “business” CMS, a great number of Web solutions exist which provide
content management “components”. CMS components are just one among a
whole range of modules.

This is the case with portals such as Liferay or ExoPlatform which, apart from their
primary functions as content aggregators, also offer content management functions.
These components are not yet as developed as the best CMS but they are
rapidly advancing and may well equal CMS and Portal type solutions, as with
Jahia, in the coming years.

On the other hand, other solutions are not designed for the implementation of
complex web sites, they did not orignally include real CMS components. This is the
case with Wordpress, one of the leaders in blog solutions. This type of tool will be
completely capable of rivalling the best CMS in the near future; especially with the
word processing strength that it is known for. In its favour, it already has content
structuring notions and experience of scalability.

Finally, surprisingly, we notice that certain EDM tools or more precisely
ECM tools are capable of extending their scope to provide advanced
publication functions. Nuxeo stands out, with its capability to modulate articles
or news (from larger content). These tools are very powerful in structuring (the
creation of complex document types) and manipulating data (multitudes of loads
possible including excellent interfacing with Microsoft Office or Open Office). The
only area which is not developed or requires further development is the content
publication area. Webengine from Nuxeo enables the publication of mini web sites,
designed as folders in the content tree-structure. The Alfresco WCM module which
manages content production and dispatch to a CMS for publication is also
interesting.

Finally it is worth noting that the CMIS standard is being finalized to allow a
simple and efficient bridge between content managed in an ECM and to be published
in a CMS.

As we can see, there is a fine line between the tools; and a new distribution of roles
may very well come about in coming years.



[2.4] Promising solutions
Smile is committed to offering its clients the very best Open Source solutions. In
order to achieve this, we constantly monitor new and existing content management
tools. Some tools tend to become dated, while others are particularly dynamic.

In general, new tools are too young to be used in the framework of a professional
project but we are keeping an eye on these tools and hope that development on them
will continue.

Here are some of the new tools that we are closely monitoring:

 SilverStripe, Modx, CMS Made Simple, for the quality of their handling in
particular
 Sympal, Diem, Apostrophe, recent products based on the Symfony framework
 Cahaya, a product based on the Zend Framework
 Magnolia, a product which is having some difficulty in building up a
community
 Silverpeas, a product which recently adopted the Open Source model

Framework based CMS are not particularly advanced to date, but look promising. They
offer a real alternative for projects which require complex modifications to existing CMS.



[3] THE FUNDAMENTAL CONCEPTS OF CONTENT MANAGEMENT

[3.1] Structuring content
In the previous versions of this White Paper, we deal with a number of aspects of
content structuring and manipulation. Both issues are intrinsically linked; but the
notion of content structuring has taken such an important place in choosing a CMS
solution we felt it was important to go back over the main concepts of structuring.

[3.1.1] Structuring content
An article is a content element. It deals with a given subject, representing from a
few lines to a few pages of text.

An article is not the smallest unit of content structure; an article itself is generally
broken down into basic fields, for example: title, sub-title, image, text body.

There are two main ways of structuring articles: functional and semantic
structuring.

Functional structuring breaks down the article based on the role, or function, of each
item, often title, sub-title, summary. This function is independent to the subject
being treated, the theme of the article: whether we are talking about cooking or a
rugby match, we can identify a field title and a field summary.

Semantic structuring breaks down the article based on the significance of each item.
As such it is possible to distinguish between fields relating to ingredients, cooking
time, the oven temperature, the level of difficulty, etc. for a cooking recipe; to
distinguish between fields relating to teams, the stadium, date and time, for a
football match, etc. As we see, semantic structuring is closely dependant on the
theme of the article, this means, we may be led to define several structures or types
of articles within the same content management. As each content is one type or
another, it is not always easy to return a type 1 article where a type B article is
expected.

Correctly structuring each article in a specific way is greatly advantageous:

 This allows to guide the correct entering of articles using a customised form,
and as such ensuring that they all fall into the right categories. Hence
effecting to the quality of content.



 This also allows to distinguish between each of the components of the article
during publication, and as such to truly separate the form/layout from
content, as mentioned above. This makes it possible to define in the article
template that, for example, the “ingredients” field is to be displayed in italics,
while “cooking time” should be displayed in bold. This effectively makes it
possible to modify the way content is displayed without touching content itself.
In the absence of a suitable article structure, one would have had to either give
up on these effects on the ingredients and cooking time, or else inject
formatting in the body of the article.
 This allows to carry out specific searches beyond simple textual searches; e.g.
recover all of the recipes with a cooking time of under 30 minutes.
 Finally, this is what gives content meaning. Content is no longer text fields,
but attributes which describe an object: country, city, price, date, etc. as such
multiplying the possibilities for use of this content.

We have seen how important it is to ensure that article structuring is managed
correctly. But it must be recognized that these benefits are obtained at a certain
price, that of complexity. The CMS becomes a real database: where entities,
entities attributes, and relationships between entities are defined, together with
controls to be carried out on each field, etc. When the declaration of a structured
content type can be done without I.T. development, this is one of the features of a
CMS which is most appreciated.

The images above show two different ways of presenting a recipe for “Apple pie”, the
image on the left depicts the non-structured version, and the image on the right
depicts the structured version of the same content. It is easy to see that the control
of restoration as well as the use of content is much greater with structured content.



This concept of content management (structured or non-structured) is key,
in choosing your CMS solution. It is important to think about this and to decide
what type of information you want to publish and what you want to do with this
information.

Joomla & Spip do not natively allow to define specific types of articles (cooking recipes
etc.) This creates some restrictions, but also a large simplicity in the management and
organisation of a site. All of the content is entered on the same form; all content can be
restored on the same template. Nevertheless, a number of quality extensions exist to get
around this problem:
jSeblod CCK for joomla (which is relatively complete) and Champs Extras 2 for Spip
(which only allows to extend existing content types).

Drupal natively supports different types of content, but does not allow to directly
manage their editing. An operational module (CCK) provides this capability and allows to
simply create new types of content with the help of forms integrated into the Back Office.
The success of this extension has won it a native place in version 7 of Drupal.

Tpyo3’s TemplaVoila module allows to define new content structures, with customised
data-entry forms. While creation is still a little technical, the result is worth it, we can
create new types of content and use them easily throughout the site. Structured content
is stored in XML in a new field of the table of contents. It is particularly well adapted to
sites which require a lot of content structuring.

OpenCms has allowed to define specific types of articles based on XSD schemas since
version 6. The structure possibilities remain basic, not using XML potential to its full,
but it is possible to easily create new content structures. Structured content is then
stored as XML, in a database field.

eZ Publish really stands out here. This is the tool which most easily allows to define as
many content types as we like, online, using a web interface. The new types of content
have a standard template by default, displaying all content fields. For each type of
content, both an administration interface preview and restore interface template (front
office) has to defined. eZ Publish also allows to define content relationships.

Jahia allows to define new types of content using CND files in which the structure of
content is defined. There is no graphic interface to create new content types, but creation
is easy and can be done at the same time as definition of new rendering templates. Jahia
6 has made improvements in this area.

InfoGlue allows to create new content structures via its interface, without the need for
any prior technical experience. InfoGlue goes even further being the only CMS which
allows to define the rules of validity for each field, by using regular expressions. This
allows, for example, to ensure that the first letter be capitalised, or that there are no
spaces etc.



[3.1.2] Seperating form/layout and content
One of the principles of Content Management Systems is to create a divide
between form and content, between the presentation of articles and the article
text (or the attributes of these articles).

There are a great number of reasons for maintaining this divide.

Form and content touch on different professions: the page layout is created by a
graphic artist, while content is supplied by a contributor.

Both of these individuals must be able to work independently of each other. It
must be possible to change the site design without touching the content, and vice-
versa, to add or modify content without touching the page layout.

A unique page layout (template) is shared by multitudes of content: this is what
makes the site homogenous. It would be impossible to obtain this result if each
time content was entered the page layout also had to be defined.

Add to this that formatting is always defined in reference with a publication
medium, so that mixing up formatting and content means reducing the publication
possibilities to one single medium.

As such the layout and content are seperated. Practically speaking, this signifies
that the text inserted into the content database must not include formatting data.

This restriction is sometimes too restrictive for certain usage, as such exceptions
must be authorised e.g.: bold, italics; or the level of formatting accepted within a
newspaper article. The type of modifications which can be made must be limited;
and changes to font, character size, colours, aligning, column layout, etc. must
remain unauthorized under content administration. Some WYSIWYG editors
store all content (even in Bold, etc.) under XML format and provide total
separation of form and content.

To meet formatting needs, CMS generally include a graphic editing tool
(WYSIWYG); this allows to format text, but also to insert links and images.
Integration of such a tool can be partial or total, depending on whether CSS files
defined for the site need to be taken into consideration, or whether the insertion of a
link should allow to select site content or the insertion of an image into a media
library.

To conclude, the separation of form and content is important in order to carry out
multi-channel publication (web & mobile for example). Furthermore, it is essential
for the creation of accessible sites.



Joomla natively offers the Open Source solution TinyMCE (Sourceforge: Project of the
Month, January 2009), a quality WYSIWYG editor which produces good HTML code.
Other editors can be implemented on the extension principle.

Drupal does not natively integrate a rich text editor, but complementary modules allow
this function to be easily added using good Open Source editors.

OpenCms has a native graphic editing solution (FckEditor), which is well integrated
into the tool.

There are a few versions of this, Typo3 had opted for the VBscript solution which only
functions on Internet Explorer. In version 4, Typo3 now integrates the WYSISYG editor
HTMLArea RTE, which opens up compatibility with other navigators. This editor is
perfectly integrated, with image management and editor customization possibilities
depending on the user.

As for Spip, it does not have a WYSIWYG editor which is replaced by specific tags that
the user must be familiar with (a “mini-editor” allows to insert them). This greatly limits
page edit possibilities, like the inclusion of images in the text, or a more complex table or
structure; however this does allow the complete separation of form and content. It is also
worth noting that a full WYSIWYG editor such as FckEditor can be integrated.

Jahia includes the graphic editor FckEditor, which ensures functionality on all client
platforms. There are three distinguishable levels of use for this editor (light, complete,
etc.) configurable profile by profile. We can as such offer, for example, the full version to
the administrator and the simplified version to contributors.

eZ Publish integrates its own Open Source editor "Online editor", under GPL. This
WYSIWYG editor writes in XML as opposed to HTML, this results in some very minor
formatting restrictions, but ensures perfect separation of form from content.
Furthermore, perfectly integrated with the CMS, this editor allows to insert files from
the eZPublish media library, to upload a file directly as a content attachment. 5.0, the
latest version from the editor, is based on TinyMCE.

InfoGlue natively integrates a rich text editor, based on FckEditor (versions prior to
version 2 used HTMLArea), which is very well integrated with the CMS, and which
allows to create a link to content by selecting it, and likewise for the insertion of images.

Good separation of form and content is more a question of policy than a question of
tool.

On an integrated CMS such as Spip, Joomla, OpenCMS, or Drupal, it is not
unreasonable to authorise contributors to define formatting beyond Bold and Italics.
The multi-channel restriction is very slight, and we can count on validation processes to
control these contributions and ensure that pages are homogenous.



As opposed to this, in Enterprise CMS such as eZ Publish, InfoGlue, Jahia and
Typo3, this restriction must be closely complied with. It must be highlighted that the
possibilities of structuring of specific article types greatly limit the need to insert
formatting in articles, as for each article field a format can be defined at template level,
as we will see later.

[3.1.3] Multilingualism
For some time, multilingualism was manually implemented using handy hints built
into the CMS tree-structure and elsewhere. This meant that to give the site an
international dimension one had to create as many sections (e.g. FR & EN) as
languages, at the root of the site. The corresponding sites were managed
independently to each other.

Better handling of multilingualism is required for companies with international
presence.

As such the CMS must manage different translations for each piece of content to
build multilingual sites – this reintroduces a link or dependence between the sites.
This dependence makes it possible to go between one language and another on a
given page, to use an automatic page translation tool, etc.

Multilingual management can become very complex: fields that require translation,
fields that don’t require translation, the chain to validate translations, automatic
and semi-automatic translations, specific permissions for a given language,
consideration of the different “alphabets”, identification of the visitors’ language, etc.

This is why multilingualism is now a fundamental part of content management. All
tools offer different multilingualism implementations; some are limited to the same
container for different languages; others offer a full interaction with excellent
functions. This is an important point to be considered if you wish to communicate at
international level.

A plugin (content translation and locale) must be used if you wish to implement a
multilingual site on Drupal. This allows to configure languages and behaviours on your
site. Drupal, like Spip, creates links between the different linguistic versions, a basic
principle which is generally sufficient.

eZ Publish perfectly manages multilingualism; it is one of the forerunners in this
domain. Every piece of content can be translated into one or more languages. The
creation of linguistic versions of the site is very easy to implement. Configurable
management rules allow to define eZ Publish behaviour in the absence of a linguistic
version of a piece of content.



Infoglue offers a very appealing language management feature. The interfaces are
straightforward and linguistic versions are made around content not pages. Content or
structure (a page) is composed of two facets: range and version. The range contains
general content information (is the content protected? what is its lifecycle? etc). Each
piece of content and structure has one single range. Each element has multiple versions.
A version is created for an element as soon as we modify published content or when we
create a new language. This gives us a version tree-structure for each element, one
branch per language. This CMS is very comprehensive on this point.

Jahia perfectly manages multilingualism. The linguistic mechanism is well-oiled and
easily accessed via different screens. “By default” it manages languages based on user
preferences (e.g. where the profile is connected). The administrator can configure the
front office display rules according to the availability of content. Jahia allows to declare
content attributes that are not translatable. Very thorough multi-language management.

Joomla does not natively offer multi-language site management. To properly implement
a multi-language site (beyond two separate tree-structures), a complimentary extension,
such as Joom !Fish must be activated.

OpenCMS does offer multi-language management. Similarly to Jahia, different
linguistic versions can exist for given content.

Spip also offers multi-language management; it has evolved-well in this regard. As Spip
is more “page” than “content” orientated, article translation is carried out by the link
between two pages (data entered by the contributor); a simple but efficient solution.

Typo3 offers several multilingual site options. Apart from that of developing X number
of sites (one per language), it is possible to define several linguistic versions of a given
page (where one page has content in French another content in English etc.) For the
initialization of a linguistic version, the contributor can copy the content from the
existing source. From there on, the site administrator can delegate administration of a
linguistic version to a given contributor.

[3.1.4] Organisation of content
The traditional mode of content organisation is, of course, that of a
hierarchical tree-structure, similar in structure to a directory. Each level on the
tree-structure, each file or folder within the directory, corresponds to a concept, a
classification based on the sense of each item, for example based on themes.

To give an example: the content of a media site can be organised into sport, culture,
international, etc., the sport section can then be broken down into basket, football,
etc.

In this example, content is organised in line with how publishing is organised. It is
easy to see that where internal organisation reflects external organisation, the
administrators work is greatly simplified.



However, when content management is planned at company level as the platform for
several publications, it is unlikely that the organisation of publications reflects the
organisation of the content repository. In this case, it is worth defining in what
manner the articles will be placed in the structure of each publication, either
explicitly, by placing each article in a specific position, or implicitly using
management rules.

Pure hierarchical organisation is not always the best solution, even within a
lone site, as it can be too structured. There are a number of alternatives. We can for
example, associate an article with different themes, which is a more relational than
hierarchical approach to organisation. This is sometimes referred to as content
categorisation or taxonomy, which is an important feature of content
management.

Classification that is not strictly hierarchical is often a necessity at publication level.
An article on a local football match may appear in both the “sport” section and the
“local news” section. The possibility of finding an article in different areas of
the tree-structure allows to satisfy visitors who each have their own
rationale; we are talking here of multi-positioning.



This point is very important. Presenting content in a logical, organised manner is
not sufficient, one must also take the visitors manner of thinking into
consideration. As we don’t all follow the same manner of reasoning, content must
be made available based on different ways of reasoning.

Pages and content

For certain CMS, content is always created in a
specific page, or even a specific part of a specific
page. For others, the creation, validation, and
versioning of content is independent to the notion
of page. It is only once created and validated that
the content can be placed in one or more pages.
This approach comes from the principle of
separating management (upstream) and
publication (downstream).

Even when content is placed on a page first, it is important that it can be restored on
other pages without being duplicated. As such if the content is updated on one file
the updated version will automatically appear on all of the other pages that this
content is displayed on.

This multiple restitution of content, sometimes referred to as the multi-positioning
of articles, can be handled explicitly: where the manager places the article in a given
page or pages; or implicitly where rules are created to manage publication
(sometimes using taxonomy).

The display of the latest 5 news headlines on the
homepage, or on the side of certain pages, is a
typical example of publication by rules. A new
headline doesn’t need to be placed on such and
such a page (the home page for example), as it is
recognised as “news” content type (or it is
associated with the keyword News) and because it
is recent, it will automatically appear on the given
page/pages.

Some solutions are based on multi-positioning to
manage multi-sites; this corresponds to use of the
same content within different sites (in this case,
one single management tool with a single database
is often used).



Spip, Drupal & Joomla are “content” orientated; each piece of content (article,
newsflash, section, etc.) forms a page, with a URL. Keywords then allow to assign
content to different pages.

Typo3 is “page” orientated. A page contains one or more columns, and each column
contains one or more blocks of content or modules, which gives page layout great
flexibility. The validation and monitoring of versions are done at the level of the page as
a whole.

Jahia is also “page” orientated, reflecting its portal aspect. Page formatting is flexible,
and dependant on the templates created. Well-implemented categorisation – or the
“content picker” (improved on version 6) – then allows to assign content to several pages.
The validation and monitoring of versions is carried out by page and content. Jahia also
allows to carry out multi-positioning of content using the principle of “virtual links”.

eZ Publish is more “content” orientated. Content follows validation processes, is
followed-up in versions, and placed in several folders, which they themselves are
considered as content. A piece of content has a URL in relation to its position on the tree-
structure. Page are managed via templates. The eZ Flow extension allows to build page
layouts from repository elements (contents).

InfoGlue is “content” orientated. Content is validated, followed-up in versions, and
multi-positioned via components. Infoglue separates the content tree-structure from that
of rendered informtion. Content is visible in the front office via components placed in
pages by the webmaster.

[3.1.5] Versions of content
Version management and the capacity to conserve previous versions of a given
article (content in the larger meaning of the term), are basic functions of a CMS.
They apply to both old and future versions. As such, a given article can have an
online version, a N+1 version (accepted but not published), and a N+2 version (in
draft status).

As we will see further on in this document, having several simultaneous versions of
the same content is necessary for the workings of validation workflows. This is what
allows us to follow chains of validation for each modification, and so to always
ensure that a manager checks the quality of the published item.

Versions can be managed at either content or page level – where a page presents one
or more organised content blocks -, or at the level of part of the site or even the
complete site. Management of the site version is complex to manipulate, but is
useful to conjointly publish content blocks, divided up throughout the site. This is a
practise which is come across in large structures where a single communication can
lead to whole range of changes; in this case, the modifications can not be published
individually; they form a coherent whole which must be “manipulated” in one block.



Where version management is involved bug management is not far behind. The tool
must also avoid all loss, by prohibiting two people to access to a given document at
the same time or by creating different versions, one per person.

For traceability purposes, contributors need for one to know who has modified what
on the site, and secondly, what the differences are between the two versions, be it at
content, page or site level.

A differentiating point between the tools is the capacity to manage versions of
attachments, like PDF files for example, but also images. As when a contributor
modifies a press release with a PDF attachment, replacing the text but also the
PDF, the tool must be abel to differentiate between the two PDF versions for the
chain of validation and to make it possible to return to a previous version.

Joomla does not integrate a version management system. It does however lock articles
which are being edited, in order to avoid inconsistencies. This makes it impossible to
return to older versions unless the user copies the page and labels it as an archive.

Drupal now integrates a version manager. The creation of a new version is,
nevertheless, declarative; it is the contributor who decides when a new version is created.
It is possible to get around this, but the Drupal version management system remains
relatively basic.

Spip conserves article versions and can display the differences between two versions; but
management remains basic. Spip locks articles which are being edited, in order to avoid
inconsistencies. Spip’s weakness lies in the fact that it does not allow to modify an article
independently to the online version.

Typo3 allows to natively manage complete tree-structure versions thanks to the
workspace notion. Since version 3.7, a versioning module allows to create new page
versions, but also complete tree-structures, which can be worked on, and then uploaded.
The differential remains at the level of each piece of content. As such, a contributor can
work on Draft content, accept it, and automatically make this content Go Live (online).
This is a very practical feature.

OpenCms manages content versions. The separation of work and publication spaces
allows to work a tree-structure, piece of content or file without impacting on the online
version.

eZ Publish can manage content versions, including versions of files associates with
content; it is very complete in this respect. eZ Publish associates a version with a status
in the chain of validation, which allows to perfectly manage content, in modification and
monitoring. eZ Publish offers a version comparison system.

Jahia has a version monitoring module. Page or page content modifications and
validations are carried out in parallel with the online version, the draft version of the
overall site can even be previewed; which is a really interesting feature. Jahia offers a
version comparison system.



InfoGlue manages versions at content level, and allows a given piece of content both a
published status and draft status. Once content is published, its display depends on its
life cycle (creation date, expiry date); this introduces a new status which can be entitled
“archived”. Content is always present in the back office but not visible in the front office.
Infoglue allows batch publication.

[3.2] Manipulating content
This section deals with manipulating content, including lifecycle management. Once
the content type has been defined, content can be created, modified, published, etc.
This is obviously the main purpose of the CMS, and as such particular attention
must be paid to this content manipulation.

[3.2.1] The management interface
Over the years, the content management interface has become a key element of the
CMS.

Contributors and administrators spend most of their time updating. It is for this
reason that it is important that they have an efficient interface at their disposal
which facilitates their work and helps to save time.

The use of technologies such as Ajax (grouped technologies which allow to exchange
and manipulate data without having to reload the page) allow to implement
interfaces which have nothing to do with simple Web pages; this allows to build real
interactive applications which can be used via a simple navigator. This can be taken
further again: use of keyboard shortcuts, field “completers”, “drag and drop”,
contextual menus, etc.

It is easier to delete a page in one click using a contextual menu than by loading a
page, then finding the “delete” button and clicking on it. It is easier to associate
keywords using a “completer” tool (which proposes existing keywords based on the
first few letters entered) than by entered keywords one by one (without spelling
errors), etc.

Beyond ergonomics (a key part of a good management interface), ease of use is vital
in approbation of the tool. All too many tools are rejected by contributors, who are
not generally technicians. It is not surprising then that the CMS which are most
commonly used are those that are the easiest to access and handle.

Certain CMS with complex interfaces put the emphasis on the “productivity” of their
back office, which is to say that what they lack in user-friendliness is made up for in
efficiency once the tool is mastered.



Naturally, the management interface is only one of the criteria taken into
consideration; the others must not be forgotten: extendibility, performance, etc.

Joomla made a great impression right from the beginning, in great part due to the
quality of its management interface. Highly graphic and well-finished, its screens are
greatly inspired by Web computer tools. It interface is easy to master and even though
some terminology may be difficult to understand at first (menu, section, category). In
2010, it seems a little dated, especially in relation to Ajax (no drag and drop to put pages
into order, for example).

Drupal is also very easy to use. Its interfaces are low key and practical. Drupal
differentiates itself from its competitors with its management interface (back office)
which is situated in the front office. This can be a little disconcerting initially but is
actually very interesting to use. The only downside is complex navigation between
functions when numerous extensions are activated. Version 7.0, which recently became
available, provides improved ergonomics, with great use of Ajax. Very promising.

The Spip hasn’t evolved very much, in terms of graphics in particular, from version to
version. Users like its ease of handling, improved in version 2.0 to make it one of the
easiest to use CMS. The WYSIWYG editor for typographic shortcuts sometimes proves to
be confusing for contributors.

Typo3 has few weaknesses, but its management interface is one of them. Beyond the
“idea” behind the tool (that it may be complex but highly efficient), its screens are
difficult to read due to the great number of functions. Fortunately version 4.3 provides a
well-made frontend-editing contribution (from the front office interface – i.e. the part
visible to web-users) which makes it easier for those who do not have technical
experience to contribute. The eagerly-awaited version 5, promises to provide a new, much
more ergonomic, graphic interface. In the meantime, Typo3 users are highlighting the
productivity associated with its use.

OpenCMS has the peculiarity of “reproducing” Windows screens. This can be
advantageous as regards change management associated with certain projects. This
imitation can, however, lead to strange behaviour in web interfaces.

eZ Publish has a relatively staid interface which is straightforward and easily
accessible. It is a good compromise between advanced features and usability. The
recently released version 4.3 delivers a revamped interface, more neutral and most
especially featuring very practical Ajax functions.

Jahia provides a well-designed interface that it is hard to find fault with. Its front end
editing tool is exceptionally easy to use; guaranteeing that users will quickly take to it.
The only downside is the block architecture (a page is made up of several blocks); it is
sometimes difficult to find the entrance point for interface modifications; likewise for
workflow statuses.



One of the advantages with Infoglue is that it clearly separates the contribution step
from the page layout step. Its interfaces are nice but lack Ajax. Contributors can work
solely on content production without worrying about rendering or final positioning. The
positioning of content in the rendering tree-structure can be automatically or manually
carried out by the webmaster. Building a page from a black page can be a bit daunting
for a beginner, but it actually turns out to be quite easy.

[3.2.2] Depositing content
In the first versions of content management tools, content integration was done
exclusively by a simple form (e.g.: title, sub-title, text, etc.) without even using a
WYSIWYG editor.

Things have come a long way since then, and there are now a great number of ways
to incorporate content: a form with a graphic editor, multi-uploads, WebDAV,
frontend editing, Microsoft or Open Office integration, email, etc.

Forms and editors

Forms remain the main method for integrating web site content, but today they are
far more comprehensive and efficient.

Firstly, they almost all include a graphic editor (WYSIWYG: What you see is what
you get). This editor must be completely integrated with your CMS in order to
function efficiently (see above).

Secondly, forms (like content) are more structured (see the “cooking recipe” example
above) which allows to assist the contributor in entering data.

Frontend Editing

Frontend Editing consists in modifying content directly from the front office. We
always work using forms but this makes it easier to navigate and search for a page
to be modified. Frontend Editing is particularly well adapted to site proofing or
modification, going through pages and stopping at those which require
modifications. This is a very simple mode of contribution, mainly due to the fact
that the interfaces lack advanced functions.

Multi-upload

Upload fields have always existed in forms but in the past loads were made one by
one. Today, new components (often in flash) allow any number of files to be loaded
simultaneously. This greatly revolutionizes the creation of a media library!



WebDAV

The HTTP protocol has developed an extra layer allowing to make a web server a file
server. WebDAV (Web-based Distributed Authoring and Versioning) allows users to
access and modify files (or content in the larger sense) on distant web servers.

Compared to the well-known FTP protocol, the WebDAV protocol also allows to lock
files while they are being modified by a user, but more importantly, it avoids having
to make a local copy of the file before modifying it. This allows users to work in
collaboration on files that are stored on a distant server, as if it was a
simple shared directory on a network.

User workstations must be equipped with a WebDAV client in order to allow them to
access it. The Windows file explorer has one, as does Microsoft Word & Open Office,
together with several (free) clients for Linux and Mac.

The integration of WebDAV with content management tools opens up new
functionalities: access to files published and publication processes outside the web
interface.

WebDAV access to a CMS must employ the same security as web interface access,
with the same users and permissions.

Integration with word processors

For several companies and organisations, the creation of a web site goes through the
never-ending copy/paste phase. The majority of content is usually already available
in office format, preciously held by the communications department.

Today the best CMS provide interfaces which include the best word processors on
the market. Integration, in conjunction with the WebDAV protocol, is exceptionally
efficient! You just need to deposit your files via WebDAV and they are automatically
converted into articles on your site. Over time, you will be able to manage your site
(content at least) directly from your favourite word processor.

Email integration

Editors and communities have come to understand the obstacles to the use of their
solutions. They have attempted to increase the ways in which content can be
integrated easily.

Among these methods, we now find the integration of emails directly in the CMS.
The principle is: to route emails and transform messages into articles or flashes
(with consideration of attachments, for the most advanced solutions).

This method is very easy to use. It is recommended in Intranet mode to collect, for
example, news regarding various subjects and breakthroughs. Email integration
must be coupled with a workflow to validate content before it is published online.



A site which works well is a site that is up-to-date! It is for this reason that we
consider it to be a fundamental concept of content management. As we have seen,
there is a wide range of content integration methods; one must take care to choose
one which suits the organisation and format of your content.

OpenCMS allows the integration of content via structured forms, WebDAV and frontend
editing.

Typo3 offers different types of content integration: frontend editing, adapted forms,
multi-uploads and email via extensions.

Joomla integrates content using forms.

eZ Publish is very comprehensive as regards content integration. Content can be
integrated: using structured forms (often accompanied by a WYSIWYG editor), via
OpenOffice, via a multi-load flash component and via WebDAV implementation. eZ
Publish offers a frontend editing mode together with a content saving module via a mail
intermediary.

Spip is more restrictive in this respect. It provides fixed interfaces to integrate different
types of content (articles, flashes, sections) and multiple loads via a community
component.

Jahia provides content integration via structured forms, WebDAV, multiple uploads via
Zip files and frontend editing.

Infoglue integrates content via structured forms and multiple uploads (via a flash
component). It also offers frontend editing via back office etc.

Drupal allows content integration via forms. It also supports WebDAV and multiple
loads via plugins. Frontend editing is native; a Drupal commitment.

[3.2.3] The lifecycle of content
Articles are born, live and die within the content database. Let’s take a look at how
the CMS manages this lifecycle.

One of the standard needs consists in preparing an article before its publication date,
and programming this article to go live automatically on a certain date.

An article can also have a life duration that is known in advance: either in terms of
duration or in terms of a given expiry date. This allows for example to create an
article entitled “how to complete your income tax return”, and indicate right from
creation, that this article is valid for one year, or up to the 31 of January 2011.

What happens on this date? The article can easily be removed from the site
automatically. In certain cases, the contributor will wish to be informed of the
upcoming modification in advance. The CMS can then, allow to define the article



removal date together with a date upon which the contributor and/or webmaster will
be alerted on this looming site modification. Once alerted, the contributor can
update the article if necessary, and define a new article expiry date.

These are relatively basic lifecycles. One may need more complex options, and in
particular that article display options change between its creation and expiry. For
example, an article may remain on the home page for one week, then remain in the
news section for three months, and then one year in the archive section before finally
disappearing off the site.

We generally use process triggers and workflows to implement lifecycles.

In relation to lifecycle management, Joomla only allows to define the start and expiry
dates for articles.

Drupal has a “Scheduler” module which allows to manage content lifecycles.

Spip meets common needs and allows to publish articles, prepared in advance, from a
given date, without a publication expiry date. A slight modification (being developed) will
allow to implement publication start and expiry dates.

In the same way, Typo3 optionally defines a start and expiry date for the visibility of
each article, without expiry alerts. Typo3 also manages the duration that a page will live
for, even a full tree-structure.

eZ Publish does not associate the duration of life with content, but this functionality is
made possible by simply configuring the tool: add the two dates (or more) to each content
structure, and configure the workflow event so that it compares the date of the day with
the start and expiry dates entered. This is an important part of the tool. The extension eZ
Flow also allows to create pages by blocks and to create block actions (automatic rotation,
publication on the _, etc.

Jahia allows to define start and expiry dates for all content. It is also possible to plan
“daily” publications (for example, every day from 5pm – 6pm, etc.) and “weekly”
publications (for example, Monday from 9am – 10am, Tuesday from 15pm -16pm, etc.).
For more complex actions, the workflow engine must be implemented and configured.

InfoGlue allows to input start and expiry dates in content metadata, as such defining
the lifecycle for each piece of content.

Validation workflows

It is often necessary to be able to separate the contribution steps from validation
steps. This is the case when it comes to situations where contributions are external
and come from a great number of different sources. If we wish to keep full control of
content, as is often essential, an article must first be drafted, then accepted, and



then eventually published online. This is important as contributors are often neither
communications nor web specialists.

In certain situations, there are several levels of validation: a contributor writes an
article, his head of department accepts it at his level, and then the head of
communications accepts it at his level.

Validation or acceptance
must, then, be
implemented by the CMS
with all of the features of
a real workflow: the
contributing parties must
be notified by mail
regarding tasks that
relate to them, and
managers must be able to
consult the list of articles
that await validation, in
one simple click.

But validation doesn’t
end here, once content
has been created,
accepted and published
following the validation process, one must be able to modify it, accept modifications
and republish, where online content remains unchanged until the modified version
is published. Advanced management of versions must therefore be associated with
the validation process, allowing several simultaneous statuses for the same content.

Workflows are, then, elements that make up a whole part of the content
lifecycle. They have to be given serious consideration as regards the organisation of
your work. And this even more in that implementation varies depending on the
CMS.

With Spip, an article can be in draft, proposed, published, refused or deleted status.
Depending on their role as writer or administrator, one has/does not have publishing
permissions. The workflow is therefore relatively limited, but sufficient in most
situations. It should be noted that in order to modify an article that is already online, it
has to be duplicated to then go through the validation process, as Spip content can only
have one status at a time.

Validation management is very straightforward with Joomla. Content is either in
“published” or “not published” status. Only a user with the right permissions can change
the status of an article. Joomla is not adapted to a collaborative content production mode.



Drupal does not natively include workflow management. Nevertheless, it should be
noted that an excellent additional module exists for this purpose. Initial configurations
can seem work intensive but the resulting options are numerous.

Since version 4 Typo3 integrates the notion of workspaces which allow to work in several
environments (a 'preprod', a 2011 version, etc.) and then to switch a page or tree-
structure of pages into production. We define three groups for each workspace: members
(contributors), reviewers and owners (those who validate), corresponding to a 3 tier
publication workflow, specific to each workspace. The owner decides to publish the
content in the “live” workspace. This can be taken further by cumulating workspaces.

OpenCms, offers a workflow option which is both extremely generic, and practically
decorrulated from the validation process in the strictest sense of the term: it allows to
build all sorts of task flows, but there is no precise link between these tasks and content
management. The advantage is that we can, in this way, build workflows in which we
can ask a given individual to complete a given article, or to tidy their desk etc. The
inconvenience is that it doesn’t offer much added-value when compared with the simple
exchange of a mail.

eZ Publish allows to define workflows associated with sections, applied or otherwise
depending on the user or groups. This function allows to implement workflows with one
or more validation level. A notification system automatically sends mail alerts and
validation requests to relevant parties. Furthermore, eZ Publish allows to have as many
versions as you like of the same content, at any given time: 3 drafts, 1 pending
validation, 1 published, 5 archived, etc. which avoids inconsistencies when updates are
made by different individuals. The recent addition of “States” has increased eZ Publish
workflow possibilities.

Since version 5.0 Jahia allows to implement multi-stage workflows and to allocate
content according to a legacy logic. A new workflow can be defined interactively, in the
back-office. There are different types of workflows by default (levels 0, 2, 3 & 4), which
meet the majority of needs and are easy to implement. Easy and fun to use.

InfoGlue integrates basic publication workflows (contribution, validation, etc.). It also
carries the open source workflow tool OpenSymphony, which allows to define complex
workflows in XML. These configurable workflows can be applied to content, or used in
conjunction with other enterprise applications, via web services. Version management is
dealt with well here, with both the possibility of modifying content and monitor
workflows by leaving online content unchanged, and the possibility of publishing content
in packets, which allows to obtain coherent versions of sites, which can/cannot be
published.

[3.2.4] Collaborative contributions
The main purpose of content management tools is the production and publication of
content.



Content is created as part of the step-by-step lifecycle. Content is generally the
result of a collaboration that goes beyond simple validation processes.

Depending on whether your content is formulated content (completed content) or is
content that has yet to be produced, you may or may not need to pay special
attention to the notion of collaborative contributions.

Collaboration can take different forms: comments on articles, forums, shared
agendas with task management, wiki, blogs, document reviews with modification
monitoring, comments, ratings, etc.

The notion of collaboration must be considered in relation to the notion of workflows:
but isolated workspaces can exist which allow to create content.

CMS which include this dimension are rare; even though this is an element that
users expect to find. Today, we separate communications more and more according
to the media (we address the user differently depending on whether we are
communicating using a physical material (paper) or the web). CMS are becoming a
place where content is produced and as such are in need of collaborative tools.

For contributor collaboration, Joomla only offers a unique messaging system, the
equivalent of a “mini-webmail”. This allows to exchange mails between users.

Drupal does not natively allow to work collectively on content production but a number
of product extensions exist which can rapidly transform your platform into a real
community. One just has to find the right modules, configure them and assemble them
correctly…which is not always so easy.

Spip was undoubtedly one of the first CMS to introduce collaborative work. Though it
still has a way to go, it already offers good scope in this respect: proposition of an article
to evaluate other contributors, comments and forums between contributors for a given
article, agenda, post-its, email, notices, etc.

Typo3 natively proposes few collaborative features in the back office, the Workspace idea
is really the only feature worth mentioning. Extensions allow to implement dashboards,
email and ToDoLists.

OpenCMS stands out from a collaborative point of view due to its “task management”
feature. This is an interface which allows to delegate content tasks (for whom, for when,
urgency, comment, etc).

eZ Publish is relatively basic when it comes to collaborative functions. Few features are
available apart from management of versions associated with configurable workflows.
The release of eZ Teamroom will surely provide ideas for collaborative work in the back
office. Worth keeping an eye on…



The same goes for Jahia; numerous content management functions but few collaborative
work tools apart from workflows. As the front office and back office are linked, private
spaces can be created, restricting access to administrators.

Infoglue does not offer collaborative functions beyond workflows and separate work
areas: content and publication.

[3.3] Using content
The restitution of content (content delivery) consists in producing pages on a given
medium, by integrating content into a specific format.

The publication process can be broken down into two steps: selection of content and
formatting pages based on templates.

[3.3.1] Templates
The formatting of site pages, for HTML
production, is always based on a template
system which defines how content must
be inserted into pages and the formatting
instructions accompany this content.

One or more templates are used, for a
given page, to define which content is
selected, where it is positioned on the page
and which formatting attributes will be
associated with it. This allows, for
example, to define that such and such a
page will only display the title and sub-
title for a list of articles, that these items
will be inserted in a table, on the left-
hand side of the page, and finally that
the title will be in Bold and the sub-title
in Italics.

We can see in this little example, the benefits of separating content and format:
there is always time to change your mind and modify the layout of the page, moving
a table to the left-hand side, change font colour to blue, to define another page,
where each item is accompanied by an image.

There are several different techniques for implementing templates.

The simplest consists in inserting in a HTML page, tags which are not in HTML, but
which are addressed to the CMS. The CMS page elaboration system scrolls the



template, analyses these tags, deducts which content needs to be selected and
inserted in the tag position, carries out the insertion, and then sends the page. There
is no particular norm for the syntax of these tags; each CMS defines its own.

The advantage with these types of templates, which we will call HTML templates, is
that they are mainly made up of HTML and so easy for a webmaster or graphic
designer to manipulate. They are, however, limited to the “tags” offered by
the CMS.

JSP and PHP pages are also in the form of templates. In the case of JSP pages,
content insertions can be defined either by Java code, by tags or by taglibs. The
main advantage with JSP templates is that they are widely used for Java web
development in general, completely outside the CMS issue. As for PHP templates,
content is mainly inserted using PHP code (particular tags which are read by the
CMS before the PHP interpreter). Compared to the first method, these second
types of templates allow to introduce complex page formatting algorithms
via programming languages (we use the examples of PHP and Java).

The third option is that of XSL
templates, based on XML. Here,
content is first extracted and put into
XML object format, which describes
each content item to be presented on
the page. The formatting is defined
using another XML object, which refers
to main content items, and defines the
way in which these items are inserted
into HTML to make up a page. We use
XSLT (XSL Transformations), which
are standard tools, to insert content
and produce pages.



The XSL style sheet / XSLT technique offers many good advantages:

 This technique is based on known standards, which go beyond the issue of
content management.
 This offers a powerful and highly modular page creation mechanism.
 This is not limited to Web media, and also allows to create pages for other
channels, PDF pages in particular with the XML-FOP tool, which seems to
becoming a standard.

On the other hand, this technique is more complex than that of HTML templates:
certain expertise is required to go from a HTML layout to the corresponding XSL
template, and this can not be entrusted to a graphic designer or webmaster. We can
also add that the transformation process is relatively taxing on the CPU, hence slow,
but most restitution systems integrate a cache mechanism, so that the
transformation will not be executed each time the page is requested.

We can also add that, apart from the template system, there is another HTML
technique to separate structure and content: CSS (Cascading Style Sheets). The
principle is to only indicate the nature of an element in HTML, and to send all
presentation information in style sheets. The HTML page indicates that “J. Hunter”
is the author’s name, and the style sheet indicates that the author’s name must be
formatted in a given way. This practice, which is clearly to be generalized, is
independent to any specific CMS tool.

Joomla & Drupal use PHP pages which allow to create very comprehensive templates,
using all of the features of the CMS. Drupal refers to these as themes.

Spip uses HTML, with specific tags, which can be completed using PHP programming
where necessary.

Typo3 also has a HTML template system, which uses an interesting interactive
configuration system (TypoScript) authorising certain flexibility of changes on a simple
administration interface: colour, font, and even placing changes, which can be carried
out without having to touch a template, via a simple HTML form proposed by the back
office.

OpenCms defines a XML based template system, but which does not use XSL style
sheets. The technique is powerful and well-structured, but it presents the inconvenience
of not being standard, and so not having the benefit of generic tools which appear around
these standards.

eZ Publish uses templates in TPL format, which contain HTLM code and tags specific to
eZ Publish. Tags have a syntax which is similar to Smarty, and PHP code can be included
indirectly to add external calls.



Jahia templates are in JSP, which provide flexibility and improved performance. It has
to be said that it is these same templates which allow reproduction on the site and
content administration. The same template must have three different modes (preview,
view, & modification) and workflow functionality. It is generally possible to create a new
template, using the templates available in the tool (overload notion).

InfoGlue offers to create templates either in velocity, an Apache project template
project, or directly in JSP, which gives more flexibility and the possible interaction with
other programs. The page is a component tree-structure. The rendered part of the
branches are the deepest. Each component is analysed and processed and then injected
into the parent branch. If a component contains “<%” at the beginning, it is interpreted
as JSP; Velocity (or FreeMarker). This is why it is possible to mix languages between
each component. We can imagine a JSP component which generates Velocity code which
is then interpreted by the next iteration.

[3.3.2] Accessibility
Accessibility is defined as the level of ease of access to content by all, irrespective of
the technology the user is employing or their degree of competence (mobile
individuals, senior citizens, people with reduced mobility, etc.). In order to guarantee
accessibility to sites, technical standards have been established by the Web
Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C).

Creating an accessible web site obviously means taking different disabilities into
consideration (sensory, motor, etc.), but also ensuring that technical criteria such as
connection speeds, the type of navigator, or the absence of plugins, does not
disturb/distort site viewing or at the very least, does not prevent consultation.
Similarly technical knowledge, or rather the lack thereof, must not be an obstacle to
site consultation.

Compliance with these norms provides numerous advantages beyond those of
accessibility to all:

 Site access in text mode (e.g.: a menu image doubled with a cached text menu)
and the semantic emphasis on information (e.g.: use of h1 tags to describe
titles) makes it “comprehensible” to search engines and considerably improves
indexing,
 The use of style sheets in the place of images makes pages lighter and so
quicker to load, while limiting the server’s load,
 The differentiation between form/layout and content allows adapted display for
different supports (screen/printer/voice/etc.) by a simple change of style sheet,
without multiplying templates,



 Formatting modifications or corrections do not require much/any template
intervention, which hugely simplifies maintenance and also reduces costs.

Compliance with XHTML/CSS standards leads to completely separating content
(XHTML content) from format (page format, colours etc. defined by the CSS). This
makes it extremely easy to obtain graphically different sites, based on the same
HTML code and simply modifying style sheets.

This includes, among others:

 the use of text as an alternative to images
 appropriate use of tags and CSS (avoiding nested tables)
 identifying headers in table columns
 not using colours alone to pass on information
 using the minimum number of tables for page formatting

Nevertheless, accessibility is no longer merely a technical issue; it is something that
needs to be managed throughout the lifecycle of the website; by all of those who are
involved in site development (developers, contributors, administrators). All
individuals who add site content must be alerted to the manners in which this
content must be integrated.

In France, article 47 of the law of the 11 th of February 2005, obliges pubic sites to be
accessible; in order to ensure “equal rights and opportunities, participation and
citizenship of the disabled”.

As such, we consider accessibility to be a fundamental concept of the CMS;
as important as performance and functions. Even if accessibility is not just a
technical issue, the CMS which best separate format and content achieve the best
results.

It is important to differentiate between the accessibility of the front office and that of the
back office. Though editors and communities have made a great deal of effort, many
management areas remain inaccessible to certain publics (mainly due to JavaScript).

Accessibility to the front office depends essentially on three criteria: creating templates,
the code generated by the WYSIWYG editor and the content integration possibilities
available to the contributor via the WYSIWYG.

Template accessibility depends on integration work – as such there is no differentiator
(in relation to CMS) apart from some exceptions (block generation for example).



Generation of code by the WYSIWYG editor is a very specific issue. Format or layout
must be separated from content; the only editors which manage this are eZ Publish
(XML) and Spip (typographic shortcuts).

Finally, WYSIWYG editor capabilities are as important as accompanying the user in the
contribution phase. For tables, for example, the editor must supply the capability for the
contributor to abbreviate column headers (abbr tag); which is not always the case with
the editors tested.

It should be noted that Jahia 6 natively provides an accessibility controller (WCAG).
Upon each contribution, the system verifies the entry and flags inconsistencies or WAI
(Web Accessibility Initiative) warnings. The administrator can overwrite these alerts.

There is no clear winner as regards to this fundamental concept, notably in relation to
the front office. Those who do best base their solution to this issue on a complete editor
and generate their own code.

[3.3.3] Indexing
Indexing is linked to accessibility; from a technical point-of-view at least. Technical
improvements for one are beneficial to indexing, and vice versa.

There are different forms of indexing. We prefer natural indexing; this is based on
content. It means positioning your site based on its pages and words. This means
optimising the technical implementation of your sites.

A site must be created with a mind on search engine indexing in order for it to be
well- referenced; this means removing all potential obstacles to the passage of
robots.

Each web site page can define meta tags or keywords, which allow to explicitly note
the main words which characterise the page. With template systems it is possible to
define the content of this tag from one of the fields which describe the article; but its
prefereable to use specially defined attributes if the CMS allows. This is even more
important, in that it allows to supply different metadata for each page.

Furthermore, all pages must be accessible without having to use a form (indexing
engines never enter forms, even simple ones); URLs must be stable and in particular
must not include session tokens, as some development tools do.

CMS display their content using frames, templates. Some CMS produce URLs
incorporating configurations which allow to define the named page e.g.
www.monsite.fr/article.php3?id_article=18.

Today, comprehensible URLs are essential, i.e. URLs that indicate the content of the
page. This gives us URLs such as www.monsite.fr/finances/resultats-



financiers.htm for example, which displays content on finance, and the subsection
financial results.

The second type of URL, offers the advantage of being comprehensible to the web
user who can tell that they are in the “finance” section, by glancing at the URL. But
what is most beneficial with this type of URL is that it can be read by search engines
such as Google, the search engine bases the number of referrals to this page on the
information presented in this URL. These are referred to as “clean”, “significant”, or
“Search Engine Friendly” URLs.

The first URL has the advantage of being stable. For example, if a given article is
moved within the “finance” section to a subsection of “finance” entitled “financial
results”, its URL will remain unchanged. While with the second type the article’s
URL would be modified, which can, in some cases, lead to broken links.

All of the CMS now tend to use the second type of URL, though some do take this
idea further than others.

Two points seem important to us in the implementation of clean URLs. First of all,
the possibility for the contributor to customise the URL of a given piece of content in
order to even better master indexing by search engines such as Google. Second,
management of URL stability by the CMS. The CMS must avoid broken links, by
storing the history of content URLs, and making sure they remain operational even
after content has been modified.

Joomla offers “turnkey” functions in relation to indexing, as with the other features it
offers. Each piece of content has metadata (description, keywords, robots, and author)
which is automatically displayed in templates. As regards the URL, Joomla allows to
activate SEO-friendly URLs but without the possibility of selecting their format.

Spip was one of the first CMS to offer an alternative to complex URLs. You can now
choose the type of (friendly) URLs that you wish to use, via the management area. As
regards metadata, Spip offers to automatically generate metadata from site content. As
such it is not possible to natively narrow down by page the few meta description fields. In
order to optimize indexing, Spip offers some interesting features such as automatic
generation of sitemap.xml files (for Google) or robots.txt files.

Infoglue offers page metadata management and SEO-friendly URLs. Display or lack of
display of metadata in the front office depends on the components used. The same goes
for the Google sitemap which is a kind of detailed site map; a basic component.

Jahia offers a management interface with metadata for each piece of content. It also
offers the possibility of manually defining “URL keys” (a type of clean URL). Smile has
already implemented the automatic generation of clean URLs based on page names.

OpenCMS offers management of metadata per page and friendly URLs.



Typo3, like all complete CMS, offers metadata management per page and friendly URLs.
It also offers a Google sitemap, via plugins. Metadata can be automatically generated
from page content.

Drupal offers clean URL management. As regards metadata, it works like eZ Publish by
adding complementary attributes in content objects. A further module is also available to
manage metadata.

eZ Publish allows good natural indexing. It offers good management of metadata via
attributes but this necessitates configuration together with minor development work at
template level (in line with the philosophy of the tool). URL management is excellent,
with monitoring of broken links, multilingual URL management, an alias feature, etc.

[3.3.4] Audience measuring
Every site administrator needs to take an interest in the audience of each page, both
overall and in detail. Certain pages may be practically never seen, either because
they don’t interest anyone, or because they are badly promoted, indexed, etc.

This makes audience monitoring absolutely vital.

There are three audience monitoring techniques:

 The analysis of web server logs
 Externalised monitoring, based on tags embedded in site templates
 A measurement feature integrated into the CMS itself.

Web server log analysis is the
oldest technique used. The
HTTP server (e.g. Apache, IIS,
etc.), records all viewed URLs in
a log file. A number of tools
exist to analyse this file and
deduce a great deal of
information from it: the number
of pages viewed, the number of
visits, day by day, hour by hour,
where viewers come from, what
navigator they use, which pages
are most visited, the list goes
on.



There are a number of good quality Open Source site analysis tools, such as
AWStats. Internet hosts generally provide this service as part of their shared
hosting packs.

Externalised monitoring is a more recent technique, offered by specialised service
providers such as eStat or Xiti, together with Google Analytics (which is free of
charge and of a good standard). This consists in placing specific tags (invisible to the
visitor), in pages, which trigger hits to an external server which specialises in
audience measurement.

The administrator can connect to the service site to consult the many tables which
present analysis of this site audience. This area of site analysis is highly
competitive, resulting in a wide range of solutions and types of analysis. This is a
strong technique, but for one, it incurs a running fee to the service provider (apart
from Google Analytics, at present), and secondly, it involves page marking, which
can be done by the intermediary of templates, but requires special work nonetheless
(this work is greatly reduced if it is taken into consideration during site conception).

Tools such as Piwik or PHPMyVisites also exist, which allow to set up a
service similar to Xiti but on one’s own servers. This is a very interesting
alternative; especially in Intranet mode where user stations cannot access the web.

Finally some CMS log visits themselves, when pages are called up. In general, this
technique is much less powerful than the other two: it provides a lot less information
on the visitors and far fewer analyses. Its sole benefit is that it allows to use
knowledge of the audience in the rendering of the site itself, for example in
displaying, on the home page, the most-consulted articles of the week. This is,
however, rarely put to use.

Spip, Joomla, Drupal & Typo3 log the hits to pages served themselves. Statistics (the
breakdown of hits, but also the information on the navigators or operating systems used)
are available directly in the back office. Typo3 allows to include the Piwik tool in its
interface.

OpenCms, eZ publish, InfoGlue & Jahia require systems which are external to the
CMS. But as we have already indicated, these external solutions offer incomparable
analysis and as such are highly recommended nonetheless.



[3.3.5] Syndication
Sites often need to exchange content with other sites, either by recovering
information from partner sites or by providing data to another site.

The standard method of exchange consists in making content available in XML
rather than HTML format, which allows the recipient site to identify each field of
information without confusion.

From a legal point of view, recovering and
especially republishing data from other sites can
only be done with the permission of the site
providing the data; this can be negotiated on a
case by case basis or the intermediary of a
specialized company.

In order for the various sites to understand each
other, they have to describe content using the
same language. A standard exists for this: RSS or
Rich Site Summary / Really Simple Syndication, a
XML format, described below.

From a technical point of view, making information available in RSS format is not
very difficult. Most CMS offer a module to manage these types of flows. Another
method consists in using a specific template (this does require some development
work).

Inserting external content does, however, require a specific mechanism to analyse
RSS flows and insert them in the CMS. Structuring CMS do this very well and even
offer an interface to “map” RSS data in articles or content of any type.

It should be noted that the insertion of external content using a RSS interface is
historically one of the functions of portals based on portlets, such as Jetspeed or
uPortal, or even NetVibes.

Spip is particularly efficient as regards syndication, as it not only makes RSSS flows
available natively, but can also integrate one or more external RSS flows: one just has to
provide the RSS URL. Furthermore, Spip can offer an administrator link by link
validation of imported flows.

Joomla & Drupal allow not only to easily activate RSS flows for the site and to
configure their behaviour (identification, the number of elements, etc), but also to
aggregate external flows and display them directly on site pages.

In the Typo3 environment, RSS imports are not native but an extension allows to import
and export syndication flows.



eZ Publish allow to publish information in several formats, including the RSS format,
which allows to be syndicated by other sites. RSS flows can be imported and can be
configured to go through workflow processes before being published. It should be noted
that eZ publish imports flows in content objects (data/attribute mapping can be
configured), which allows to apply all available methods to them (multi-positioning,
translation, workflows, etc ;), and especially to aggregate the flows from different
senders.

Jahia has a RSS import module. Flows are imported separately in the content database.
RSS exports are native in version 6 is still based on the template principle, in which the
content to be exported must be specified (for greater flexibility).

InfoGlue does not natively offer RSS import or export features. On the other hand, the
XML import and export of content is native, it is, as such, possible to adapt processing to
reduce it to RSS format.

[3.3.6] Customising content display
Most websites present the same content to all visitors. In some situations, however,
a site may be configured to display different content to different visitors, using a
single content database, managed globally.

We can distinguish between customisation using user preferences, and customisation
defined by permissions.

The first is generally that where the user specifies which type of content interests
them (and as such what content is to be displayed), their layout preferences, etc. e.g.
MyYahoo! Having defined their preferences, each web user will be recognised either
by explicit identification or in a transparent way using cookies. This type of
customisation is often used in company portals, which we will take a look at further
on.

Customisation using user permissions is not generally managed at individual level,
but by creating visitor groups, defined by the profile. This customisation does, of
course, require user identifiers, which allow to find the profile of each.

This is essential for Intranet sits in particular, where access to certain information
is restricted.

Overall, customised rendering is seldom used as it poses performance problems. It is
easier for a server to serve the same page 1 million times than to serve 1 million
different pages. Web users, however, greatly appreciate this feature. When content
is public, we prefer to use client side page construction (with javascript for example).
When content is restricted, page construction using SSI or ESI tags is preferable.

For certain portals (as with media), work on animated content takes priority. Some
CMS offer modules to animate pages by taking into account article rotation for



example. The CMS takes charge of animating the site by varying content (on the
home page for example) according the pre-defined management rules.

Joomla offers customisation based on permissions on three access levels: public
(everyone), member (users with an account), and special (users with Edit rights).

Drupal only natively manages 2 levels of access for content rendering: public display &
member display. Additional modules provide greater flexibility and allow to define
detailed content permissions. Drupal has a Homebox module for the implementation of
personalized pages such as iGoogle.

Spip does not offer this type of customization feature. This can be a real drawback to
using Spip.

Typo3 manages permissions in a very comprehensive manner, and as such includes a
user preference feature. It is the same system as that applied to contributions and visits
to the site. Each page of the site can be associated with a user group, and is, as such, only
visible to those who belong to the given group.

eZ Publish manages display via access permissions and user account management. The
forum and memberships are functions which involve customisation and are implemented
natively. It should also be noted that eZ Publish offer a module named eZ Personal Page
which allows to supply the final user a page which they can personalise to their liking
(like iGoogle).

Jahia perfectly integrates the notions of customised display, notably based on the
connected user’s permisions, who will see or not see certain modules and certain modes of
these modules. Here again, the “portal” mode plays its role to its fullest.

InfoGlue manages read permissions to content and pages. We note that InfoGlue is
natively connected to CAS (see below).

[3.3.7] Collecting information
Sites are becoming more and more participative. Visitors now not only consult but
also contribute.

This new tendency requires tools which allow to collect information from web users:
from a simple comment form to an advanced questionnaire.

In order to respond to this need, a number of CMS include form generators
associated with information gathering databases. Others extend the concept of
“frontend editing” to make web users contributors of a whole other type; and this on
all web site content (irrespective of the type).

The ease of gathering information has become a very important aspect of the most
recent sites; as has the use of data. From this point of view, all CMS do not offer the
same level of quality and it is important to be vigilant in this respect.



Joomla offers extensions which gather information provided by the visitor: chronoforms,
artforms, polls, contacts. However, these plugins are generally independent of CMS
content.

Spip provides relatively good interaction between users and administrators via the
intermediary of form types. There forms are activated via tags (#FORMULAIRE_SITE,
etc.) placed in templates (requiring technical intervention). “On the fly” forms can be
created (from the management area) using extensions such as forms&tables.

Infoglue does not natively offer anything to deal with this issue.

Typo3 offers numerous modules which allow to collect information: surveys,
questionnaires, structured content, the options are limitless.

OpenCMS does not natively offer anything to deal with this issue.

Jahia offers information gathering features such as membership subscriptions,
comments, etc. Jahia also has a form generator (available on version 5, on hold on version
6) which allows to gather information in the form of manipulatable content.

eZ Publish is particularly good in this respect. When content is being defined, the
administrator can configure the attributes to be used as data collectors (which
“transforms” itself into a form). The principal of front end editing is to allow to edit
content by profile type based on the security policy; it is on this same principal that the
comments feature on eZ Publish functions. Information gathering is also used for surveys
and questionnaires; the advanced questionnaire tool the eZ Survey extension is a
particularly good complementary tool.

Drupal is particularly pertinent in this respect. This is obvious through the numerous
community modules. Its unique interface (front office / back office) facilitates information
gathering.

[3.3.8] Portal functions
The objective of the CMS is not, in theory, to become a portal; that is to say to
aggregate flows, create composite pages, gather content and applicative modules.

Yet, when we use a CMS to build an Intranet for example, we are quickly confronted
with this type of need.

We are well served in the world of Java solutions; where standards exist (Jsr 168 &
286) and we can easily implement portlets (blocks) incorporating flows and third-
party applications interfaces. PHP CMS do not have the same standards – we often
use alternatives like iframes and more and more commonly JavaScript (Ajax, web
services).



It should be noted that Smile has developed an Open Source solution called Esigate.
Both a cache manager and content aggregator, Esigate allows to build sites “on the
fly” using heterogeneous sources. It offers a real solution to the problems that arise
with PHP portals.

Jahia & Infoglue allow the inclusion of portlets (jsr168 for Infoglue, Jsr 168 & 286 for
Jahia) which give these products a portal aspect (without being real portals, like Liferay,
for example). These are the most comprehensive CMSs in this regard, even if we don’t
always use this feature.

Even though OpenCMS is based on Java architecture, it does not support Jsr 168 & 286
specifications. Its portal capabilities are quite limited.

Joomla & Spip do not offer portal functions.

Typo3 & eZ Publish offer portal functions via blocks for Typo3 and the eZ Flow, & eZ
Personal Page extensions for eZ Publish. They can also offer web user customisation
(control panels), to a certain extent. Third-party applications are generally integrated
using Webservices.

Drupal also has modules which allow the implementation of customised pages like
iGoogle. The module Homebox is of particular interest.

[3.3.9] Search engines
All too often we imagine that a search engine is mainly used to index full text
documents, or to search through content that is not very organised, forum threads
for examples.

This type of usage is restrictive. Many web users use the search function to avoid
having to figure out the organization of the site. They prefer entering two or three
words which are representative of what they are looking for and hitting “enter”, then
looking through the results offered, rather than reading the first menu, thinking
about which section is most appropriate, arriving at another level, thinking again,
and finally going backward to search elsewhere.

This search behaviour is instilled/encouraged by internet portals, which are often
the starting point for navigation.

This direct approach, of rapidly arriving at the relevant page, without having to go
through irrelevant pages, and having to think, sometimes goes against the
webmasters wishes, as the webmaster may like the visitor to take their time, view
as many pages as possible, and as such as much content and as many adverts as
possible.



But what the webmaster wants is not necessarily what the visitor wants, and one
must accept the idea that the visitor will have the final say, as if they don’t find
what they’re looking for in three clicks, they will go elsewhere.

There are three options for the indexing of data: search engines specific to CMS
(developed especially for the CMS); external search engines (proprietary or Open
Source) which indexes sites; and search engines integrated into the CMS which is
based on known solutions (often Open Source).

Search engines specific to the CMS are the most basic. They are based on
breakdowns and algorithms which are sometimes very rough. Relevance is often
lacking or of poor quality. There are, however, some exceptions.

External search engines can always be integrated on a site independently of the
CMS tool used, in so far as they index the site by indexing the HHTP by “crawling”.
They offer all result page presentation possibilities using a similar system to
templates. Some also offer APIs giving direct access to search functions, which
allows to better integrate them into specific applications.

The integration of external search engines is difficult in the case where restrictions
to certain content are put into place, as on the one hand, the engine must index this
protected content, and on the other hand, the engine must verify the web user’s
permissions to display the search results either including or not including protected
content.

The Open Source world offers some excellent alternatives such as HtDig,
mNoGoSearch, SolR & Lucene. These are sturdy solutions which offer excellent
functional scope.

The best option is that of CMS which take aboard known search engines (such as
Lucene) in line with the security policy. This is a developing trend both at CMS and
portal level.

This interfacing is good from a technical point of view. One must not forget,
however, to judge a search engine on its functions: document search (PDF, word,
etc.), search by section, management of relevance, consideration of plurals, search by
semantic proximity, etc.

Spip offers integrated but very basic search functions. It does a very rough search
which doesn’t take logical functions, document indexing, and classification by relevance
into account. If this feature is important to you, we would recommend that you use an
external engine.

Joomla offers three search modes: “AND”, “OR”, & “exact term”. Results can be sorted
according to the publication date (most recent/oldest), popularity, alphabetic order,
section/category and content type.



Drupal offers search taking logical functions into consideration and allows to filter the
results according to their category and content type. Thanks to the “Search Attachments”
module, Drupal can also carry out full-text search in attached documents. The “Apache
Solr Search Integration” module allows to couple Drupal with the Open Source Solr
engine.

eZ Publish offers a more advanced search function, with notably the capability of
searching by content field (title=…), but also a plain-text search on content and
attachments. eZ Publish now natively offers the eZ Find extension which is a connection
between eZ Publish and the Open Source search engine Solr. This is a great compromise,
providing excellent scope (facet search, etc.) while complying with content security
measures.

Typo3 integrates a search engine which indexes content, including attachments, and the
result list is sorted on calculated relevance criteria. This module remains inferior to
htDig and mNoGoSearch, but is very efficient nonetheless, and offer results arranged by
file/folder. For more advanced needs, an external search engine remains necessary.

Jahia integrates the Lucene, the Apache project search engine, which allows to index all
site content, without using http but with specific files and the database read connectors.

InfoGlue integrates the Lucene search engine, which goes through site pages indexing
them, offering as such, a full—text search on all content. Unfortunately, this search is
only available in the back office. An external search engine (such as Solr) has to be
implemented for the front office by connecting it via “interceptors”.

OpenCMS also integrates the Lucene search engine. Content is indexed once an element
has been published. The administrator has an interface for configuration and monitoring
indexing.

[3.4] Permissions and access security
A good CMS must offer flexible management of permissions and access rights. This
should be transparent to the contributor.

[3.4.1] Users, groups and roles
Small to medium sized sites often have only one contributor, the webmaster. Here
content is either created by the webmaster themselves or, more commonly, by other
company employees, and then collected by the webmaster for publishing. It goes to
follow that the webmaster has full, read, write, and execute permissions to all site
content.

For larger sites, it is impossible for one person to manage all site content on their
own. Furthermore when the content has been written up outside of the CMS, it has



to be rewritten or copied & pasted, in the CMS by the webmaster, which is a waste
of time.

For these reasons, it often makes sense to ensure that contributors interact
with the CMS directly in this regard, by allowing them to write and modify
their articles. In an Intranet context, collaborator contributions are factors of
participation, and as such membership: the Intranet is no longer a tool used to
receive information but rather an exchange tool.

In this context, it is often necessary to allow contributors limited access to
certain areas of the site. These permissions are defined in reference to the
hierarchical organisation of content.

As such we define for example, a “Human Resources” section, which is the starting
point of an important content tree-structure, and we allow certain contributors
permission to access articles that are relevant to Human Resources. The same
contributors will not have access the “Products and Services” section unless they are
also specifically given permissions to this area.

The permissions of each person are defined in reference to the organisation of content,
but must also be defined in reference to the actions that can be carried out on this
content. As such, a given user may have access to propose an article, but not to
accept it or publish it online. Another person can accept an article in a given section,
but may not have the relevant permissions to create new sections, etc.



CMS must offer two types of permissions management: the first relates to content,
and its organisation, the second relates to the functions linked with the management
of this content: viewing, updating, accepting, publishing, etc.

In general, permissions are defined at user level or user group level; with cumulated
permissions where users belong to several groups. To facilitate the configuration of
permissions, the majority of CMS use the notion of “Roles”; this means regrouping
the types of permissions that can be associated with a user or a group.

The definition of the site security policy is an important step which must be
prepared when the site is in the conception phase. To facilitate it’s implementation
and ensure that that it is monitored closely, a number of functions have been added
by both editors and the communities. Some CMS allow for permission delegation,
others offer default permissions, etc.; everything is done to simplify site
administration.

Spip allows several contributors to edit/publish site content under predefined roles. For
Spip, these are authors, who are either writers or administrators of content, and who
have access to all or part of the site. A writer can only create content, an administrator
can create and accept content for a given section (only administrator accounts can be
restricted to a given section – not both). Permissions management is very limited with
Spip but corresponds to a traditional manner of functioning which may be perfectly
satisfactory to many users. Extensions are available to extend native functions.

Joomla offers 3 main contributor categories: “author”, “editor” and “publisher” allowing
to respectively modify, create, and publish content. Each article can be associated with a
given author by a user with greater permissions. While this system is amply sufficient in
the framework of a simple web site, it is insufficient for larger sites. Version 1.6 is due to
provide ACL (Access Control List) management.

Drupal offers very precise permissions management. It is possible to create any number
of roles and to assign permissions for each function of each module. This model allows
Drupal to be adapted to any need. Several modules exist to restrict access to different
content: “Node privacy by role”, “Taxonomy access”, etc.

Typo3 offers a far more comprehensive system of permissions management than that of
Spip. As with OpenCms, it is based on the Unix module, with the concepts of users,
groups, & all. The smallest entity is the content attribute (field). We can also configure
permissions at column, language, block, tree-structure, etc. level, Typo3 offers group
legacies.

OpenCms offers Unix inspired management of permissions: each section of the tree-
structure is seen as a directory, and read, right, execute permissions are attributed
according to whether one falls into the category of user, group, or other.



eZ Publish allows to define roles, groups and users. Roles include all authorised
permissions, for each module, for each function, and for a given area (language, section,
status, etc.). This same system allows to restrict permissions to consult a site or submit a
comment in a forum for example. However, we cannot see, the permissions assigned by
content.

Jahia allows to define the profiles and permissions required for decentralised
management, using user and group notions, which can be configured in several different
ways. Permissions management is also applied to portal modules, which allow single
sign-on for all the applications implemented. As opposed to eZ Publish, the management
of permissions is configured at the level of each piece of content with, notably, a very
interesting notion of legacy. However, there is no notion of group to group (hierarchy).

InfoGlue allows to define groups and roles, associated with users, who can only access
certain modules, certain content, and certain actions.

[3.4.2] Directory/Phone book
Most companies now have a central directory. This lists all company employees,
along with their roles.

This directory is generally used to store user identifiers and passwords. In some
cases, permissions are directly listed here; even though this is mainly limited to the
notion of groups e.g. “Human Resources” group.

The CMS now offer interfacing with these directories (OpenLDAP, AD, etc.). This
allows to centralize user information – the repository is now the LDAP directory; not
the CMS. This is essential to guarantee good integration of the CMS into the
company information system.

Furthermore, users no longer need to memorize a new password – they will use the
same as that which allows them to access their machine.

There are different types of implementation:

 The directory can be used to create the CMS User database (with the
possibility of regular synchronization).
 The directory can be used upon each identification (the CMS user database is
then, no longer used).
 The directory can be used for each identification, while systematically
updating profile data (contained in the CMS database) to be used throughout
the user session (apart from the password).



Certain connection algorithms allow to recover user LDAP groups and to carry out
mapping with CMS groups. This is a relatively easy way, to manage permissions
from the company directory.

Finally, we should note that certain CMS authorize conjoint use of the local user
database and distant directory.

Drupal allows to connect to a LDAP directory. In order to do this an ldap_integration
extension must be activated. To use identification alone, the ldapauth plugin must be
activated. It is possible to carry out mapping between Drupal roles and CDAP groups
thanks to the ldapgroups module.

Since version 1.5, Joomla manages identification via LDAP. Older versions require an
extension such as JAuthTools.

eZ Publish allows to identify oneself using a LDAP directory. A synchronisation script is
also available to update users registered on eZ Publish.

Typo3 uses a LDAP directory via an extension (ig_ldap_sso_auth par example) for
identification. It is mainly aimed at OpenLDAP & eDirectory servers. As with eZ Publish,
it allows synchronisation of user data. Typo3 also manages OpenID.

Infoglue offers excellent identification management via LDAP. This necessitates the
activation of special modules which allow access identification and authorisation by
associating users, groups, and roles with directory elements. The “unusual” structure
offered by the native Intoglue connector sometimes means that one must write another
connector.

OpenCMS can manage LDAP support, this involves using an editor extension that
incurs a cost: Alkacon OCEE LDAP Connector.

Jahia supports identification via a LDAP directory (Active Directory, eDirectory,
LemonLDAP, etc.) and also allows the synchronisation of certain attributes.

Spip natively supports identification via a LDAP directory. The management of
authorisations can be put into place even if it is limited to the management of user
permissions (1 section).

[3.4.3] Single Sign-On
Single sign-on (SSO) allows the user to log on once giving access to all web
applications rather than having to enter a login and password for each system.

Single sign-on works particularly well with intranets where identification on a
Windows system, for example, allows access to applications which make up the
intranet, without having to go through additional identification forms.



SSO can be implemented using a number of different solutions. CAS (Central
Authentification Service), Kerberos, etc. The CMS must be able to support these
solutions in order for a SSO to be implemented.

CMS which do not natively support SSO can be modified; but this requires the
intervention of specialized technical experts (Smile frequently carries out this type of
intervention work).

Several CMS use plugins to implement SSO. One must pay particular attention to
the quality of these plugins.

Several SSO implementations have already been carried out on
eZ Publish (by Smile in particular) but there is no official editor support. eZ Publish
does offer “SSO Handlers” which allow to implement SSOs such as CAS, Kerberos, etc.
but these require development work.

Joomla does not offer any official support. However, one or two extensions can be found
which allow SSO implementation but without any reliability or security guarantees.

Spip natively supports LDAP which is a good start. As regards SSO, a relatively
comprehensive extension was available before version 2.X. This plugin is no longer
maintained and no guarantees are offered with it.

Drupal integrates SSO management using plugins. CAS is particularly well
implemented.

Infoglue natively supports SSO implementation, which is relatively rare in the CMS
world and as such an important point to emphasise.

OpenCms does not natively include SSO support. Implementation is possible and
quality tutorials exist in the community but this requires development work and ideally
the support of LDAP (which incurs a fee).

Jahia natively supports most single sign-on systems: CAS, NTML, etc. Jahia offers an
“identification plugin” system for protocols which are not yet supported.

Typo3 offers excellent extensions which allow to implement SSO (LDAP/SSO
Authentification for example). This is a community extension which must be verified by a
service provider, such as Smile, when it is being implemented.

[3.5] Technical platform
The number of people to use the Internet is rapidly increasing day by day. The
volumes of site consultations are literally exploding. A simple blog can quickly
attract thousands of visits per week, or even per day.



This phenomenon cannot be ignored. Beyond the functional scope of a tool, it’s ease
of handling, level of community activity, etc.- its scalability is of the major relevance.
Imagine your dismay if you discover, after weeks of planning, that your site cannot
be seen due to a weakness in the site architecture!

In this section, we suggest an approach to the technical platform; if you would like
further information on this subject, please see our White Paper on Good Site
Architecture.

[3.5.1] Framework
The quality, performance and stability of Open Source development libraries and
frameworks are no longer in question. They are behind the success of some of the
most widely-used applications in the world.

These same tools are now regularly used in the creation of content management
tools. This is particularly true in the Java world even if the PHP world now also
offers exceptional frameworks such as Zend, Symfony or CakePHP.

A framework allows to reduce the time it takes to develop applications by providing
effective solutions to the problems commonly encountered by developers. This time
saved can be put to good use working on specific areas of the application, the key
functions of the CMS in our case.

Furthermore, using the same framework contributes to the industrialisation of
development processes: the structure of the application and the programming
methods are standardised, maintainability is much improved.

A framework is the fruit of the work of dozens if not hundreds of people who apply
themselves to proposing new functions and correcting problems or security failings
discovered by users. This is why framework libraries are generally better designed
and better coded, but also better tested and as such more solid, than what a single
programmer (or small team) could produce. This type of solution saves time and
provides great benefits in regards to quality.

Framework based CMS generally provide great expendability, in that the
components which make up these frameworks are perfectly documented and, as
such, open.

Several CMS are not based on frameworks; which are not an end in themselves,
sources always need to be studies in detail to guarantee scalability, stability and
security capacities.

Spip, Joomla and Drupal are not based on frameworks. These solutions use
applications “from scratch”.



eZ Publish is partly based on its eZ Component framework. The entire application is to
be gradually rewritten based on this framework.

Typo3 is not framework based. However, the upcoming version, version 5, is to be
entirely rewritten with its Flow3 framework.

Jahia is based on a number of Open Source Java components such as hibernate, struts,
spring, gwt, jgroups, pluto, etc.

OpenCMS is also based on a number of Java components: Lucene, Dom4J, JTidy,
Doomdark JUG, Log4j, Digester, Commons DBCP/Pool, Quartz, Junit, etc.

Infoglue is based on: Webwork1 for back office views, Castor for CMS data, Hibernate 2
for OS workflow data, OpenSymphony workflow for the management of specific
workflows, Velocity to define back office views, and many more.

[3.5.2] Distant API
An API (Application Programming Interface) is made up of a number of features,
procedures, and categories made available to applications to guarantee their
interoperability.

CMS are generally controlled and managed from an administration interface (back
office). Being able to access the CMS from a distance, or via third-party programs,
can also be useful however.

This is the case in particular when we have a complete Information System which
manages product description files. These documents can be updated via the IS and
published on the CMS using a script (of any type). This script generally uses the
CMS API; if this is not the case, the script must work directly with the CMS
database, which cannot guarantee content integrity.

For large-scale projects, there is no way around interfacing with third-party tools; in
this case, it is hugely important that a well-functioning and well-documented API be
used.

Typo3 integrates SOAP and offers a complete API.

Jahia offers elements such as Rest. Full integration of JackRabbit should allow, in the
long run, to reach all content in this way.

OpenCMS does not natively support exchange protocols such as SOAP. However, the
community has started to write exchange modules based on the JAX-WS protocol.

Infoglue offers a complete, native API which is accessible via SOAP.



eZ Publish offers a SOAP server with some functions. These can be extended upon using
the local eZ Publish API.

Joomla offers some extensions (such as XML_RPC_Joomla) which allow exchange via
XML-RPC.

Drupal also has an extension which allows exchange using the XML-RPC protocol.

Spip does not support exchange protocols.

[3.5.3] Plugins and extendibility
CMS cannot do everything – or at least not natively. They already provide excellent
functional scope, covering most needs.

But needs are ever-expanding. As such it must be possible to extend the CMS
without having to modify its kernel, i.e. the core of the solution.

This notion of extendibility is now offered by most CMS; levels of quality vary (a
subject which brings thousands of community developers together).

Some CMS have hundreds if not thousands of extensions. In this case, one must be
able to go through them and recognize which are the best. Community comments
can be very helpful when making your selection.

For CMS that use this model (kernel + extension), success is mainly based on the
capacity of the platform to provide an operational and coherent whole (access to
functions, dependence, etc.).

If you do not find exactly what you are looking for, you can always develop a new
extension. Depending on which CMS you choose, this can be anywhere from easy to
difficult.

Joomla allows to add functions by adding modules. The website
http://extensions.joomla.org/ lists the extensions available (over 4 000). Some are
essential to compliment Joomla’s sometimes limited scope.

Infoglue does not offer a classic extension system; the Infoglue engine has several
specific points called “interception points” (“a point in the system where a possibility for
custom logic has been added to intercept processing and extend InfoGlue’s own logic”). Its
Java architecture, however, does allow to incorporate portlets.



Spip has included the idea of plugins since version 1.9. Its active community provides
good, well-referenced plugins. Spip also offers a site dedicated to these extensions
(http://www.spip-contrib.net) which lists compatibilities and includes user ratings. Plugin
activation is pretty straightforward, even if extension files must be placed on the server
first.

eZ Publish has a mainly professional community which explains the limited number of
extensions (several hundred nonetheless). These are, however, of a very high standard
and often deal with complicated issues.

Typo3 can be easily extended using thousands of plugins. The website
http://typo3.org/extensions/ lists every single one of them! It is easy to consult the most
popular of these such as tt_news or powermail.

OpenCMS offers some extensions on its main site
(http://www.opencms.org/en/download/contributions.html). They are not very numerous
but are of a high standard and very useful (KonaKart Shopping Engine, jBPM Workflow
Engine, etc.).

Drupal provides a choice of over 10 000 extensions! You will find any module that you
can think of.
You can see what extensions are available at http://drupal.org/project/Modules. The “view
module usage statistics” page, allows you to see the most widely used plugins: views, cck,
token, etc. Module installation is easy, and uses dependence rules.

Jahia has a community site: http://www.jahia.org, but does not offer easily-deployed
extensions. As with Infoglue, its architecture allows to incorporate portlets.



[3.5.4] Performance
As mentioned in the “Technical platform” section, the performance of the CMS has
become a fundamental concept of content management.

It is impossible to create an important site without taking this aspect into account.

This, however, is the most complicated element to assess. Performance depends on
the creation context (what modules, options and customisations are chosen) and on
the use context. There is no scale of performance apart perhaps, from that offered by
integrating companies such as Smile, and even at that, it all depends on your exact
needs.

Taking a look at which companies use the various different CMS can give a good
indication as to the quality of the solution (or the equivalence of its architecture); as
can testing different tools in conditions similar to your own (how many simultaneous
sessions can be opened while maintaining response times of less than 1 second for 90
%?).

Beyond tests, a powerful CMS is a CMS which offers a good cache system, i.e.
keeping the most frequently requested pages in memory while refreshing them upon
updating. Some even go so far as to offer static (HTML) versions of the site, or even
complete interfacing with solutions such as Squid or Varnish (“proxy-cache” or
“reverse-proxy”).

Finally, we should note that certain CMS offer extendable architectures, i.e.
architectures which can evolve (e.g. the number of servers can be increased)
depending on the load demands. We invite you to read our White Paper on High-
Performance Web Platforms to find out more on this subject.

Typo3 has a number of cache elements, by page and by block. This cache can be
managed in different ways: by file, by database, by memcached. It is also possible to
install Typo3 in cluster mode and to offer static generation of pages.

OpenCMS provides good performance.

Jahia provides excellent performance, as is often the case with JEE architectures. It
natively offers a cluster mode and fragment caching. Benchmarks are available on the
editor’s site.

Drupal provides excellent performance in stand alone mode, mainly thanks to the very
powerful cache system.

Infoglue is one of the most “sturdy” CMS on the market.



eZ Publish performs well if one uses the numerous cache systems provided, correctly. To
obtain improved performance, eZ Publish allows static generation of HTML pages and
the use of reverse-proxies like Squid or Varnish (with a refresh link). eZ Publish provides
cluster building for high-performance architectures.

Spip provides very good performance with its native cache system. Its configuration is
relatively concise but allows to implement a content site without customisation.

Joomla offer acceptable levels of performance which can be quickly found lacking if
there is a high level of consultation.



[4] SUMMARY
Before getting to the conclusion, let us recall that our analysis is based upon the core
concepts of content management, not around the choice criteria, which are far more
numerous. Our goal was not to build a matrix evaluating each CMS solution on
each possible criteria. Our goal was to convey our vision of the field of Content
Management and to position the best open source solutions.

As for choice criteria, they will refer partly to these core concepts, but will also
include other issues such as the vitality of the community, number of customers,
documentation, etc.

There is no single tool that would come out as a sole winner in this study: the
selection was done upstream, which means we only mentionned quality products,
which are all among the best possible choice for building your websites or more
generally, managing your content.

Open source solutions are sometimes seen as comparable to generics in the drug
industry: once a domain is mature, once the underlying concepts have gone stable,
the best practices and best solutions get to be a common good. This is what has
happened in the field of content management, where open source solutions have
gradually climbed up the ladder, starting with low-end basic but easy solutions, and
now going all the way to advanced enterprise level offerings, that compete with the
best proprietary products.

Smile has deployed content management systems in several hundreds of websites,
be they Internet, Intranet or Extranet, and we will be happy to bring this expertise
to your projects.


Wp smile cms-julio2011

More Related Content

Similar to Wp smile cms-julio2011

More from Jordi Sabater Domènech

Recently uploaded

Wp smile cms-julio2011