wp smile cms-julio2011

Content Management

open source solutions

2010 edition

By Grégory Bécue

Version 4

Further information: www.smile.frTel: +33 (0)1 41 40 11 00Email : [email protected]

http://www.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.


http://www.intersport.com/

http://www.fujifilmgraphic.fr/

http://www.bonduelle.de/

http://www.alice-dsl.de/


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 11th 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-


http://www.monsite.fr/finances/resultats-financiers.htm

http://www.monsite.fr/article.php3?id_article=18


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.


http://www.monsite.fr/finances/resultats-financiers.htm


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

Technology

open source solutions1

best open source solutions

stable open source solutions

open source flow controls

smile offices

theopen source vpns

promising open sourcesolutions

integration of systems