Skip to content.


Home Articles Plone review

Plone review

This review follows on from my previous article, which outlined the criteria I applied to many of the main open source CMSs to determine their suitability for a developer.


Version evaluated: 2.0.5

License: GPL

Platform: Zope application server; Zope is licensed under the GPL-compatible Zope Public License; evaluation was done with Zope version 2.7.4-0

Commercial support:

Example sites:


Plone is a flexible, full-featured and enterprise-ready CMS. It is built on top of the Zope platform, a powerful, generic framework for building content management systems. Throughout this review, I will refer to Zope frequently, as much of the extensibility and elegance of Plone comes from its foundation in Zope.

While Plone is relatively easy to install and has many features out-of-the-box, the learning curve for building your own extensions to Plone is relatively steep, requiring good knowledge of Python, as well as web programming more generally. The situation is improving as Plone gains in popularity, and several books have started to appear.

Having said this, the core functionality provided by Plone (form validation, content type definition via Archetypes, etc.) automates much of the donkey work that would be involved in building a CMS from scratch. So even if you don't do any custom programming, the default installation provides a very full-featured web application platform.

Plone would be a good choice for an organisation looking for an extremely flexible, scalable CMS. It would also be a good fit for organisations who are au fait with object oriented programming and modern programming techniques, such as the use of XML for defining content types and separation of content from presentation. It rewards good design principles, simplifying the task of creating an easy-to-maintain website infrastructure.

Default capabilities

Standalone installation packages are available for all major operating systems, including Windows, Mac OS X and several Linux distributions. The raw Plone Products are also available for download, and are easy to add into a standard Zope installation.

Plone stores all content in the Zope Object Database (ZODB), and all of the elements of a Plone site are "objects" within the store. This means there is no need for a separate database to be installed (though the ZODB can be stored in a database if desired).

Below are some feature highlights included in a standard installation:

  • Management interface: Almost all of Plone's functionality can be managed through a web interface, including starting and stopping the server, viewing logs, setting permissions, and creating and editing content.
  • Epoz editor: This is a WYSIWYG editor for all content on the website.
  • Member areas: Each user of the site gets their own personal area, where they can build their own set of pages, including news items, events, and discussion topics.
  • News: Any added news item becomes part of the "news feed" section of the site.
  • Events: Events can be added by any user, and are incorporated into a clickable calendar displayed on every page of the site.
  • Accessible templates: The default Plone templates conform to the WAI WCAG level 3, and the page mark-up produced is valid XHTML.
  • Workflow: Plone has one of the most flexible and fully-featured workflow systems of any of the CMSs reviewed here. The default workflow for new content items allows private editing of the new item, followed by submission to the review queue, then publication once approved. At each stage of the workflow, user and group permissions can be set to define who can move the item onto the next stage (or back to a previous stage if it is rejected). Workflows are also heavily customisable, and a wide range of scenarios can be specified.
  • Archetypes: This is a framework for adding your own content types to the default Plone types. New types are defined in a text file ("schema") which specifies the fields the type has, the kinds of content allowed in those fields (e.g. text, HTML), the widgets to present when those fields are edited (e.g. drop-down box, radio buttons, text field), and the validation rules to be applied when new instances of the type are created. Plone uses the schema file to generate all the forms necessary for updating, deleting and adding instances of the type; it then handles all modifications automatically, without the developer needing to write any persistence code. While the generated code (e.g. HTML forms) is often adequate, it is possible to further customise it to improve its appearance or usability.

Additional modules

As Plone runs on top of Zope, all of the features of Zope, including its multitude of Products (packages providing additional functionality), are potentially available inside Plone (in some cases, they may need a bit of tweaking, though). Products and tools specifically targeted at Plone are available from the Plone Collective. Some of the more useful ones are summarised below.

  • CMFWeblog: Blogging functionality for Plone.
  • Calendaring: Calendar functionality which extends the base Plone calendar, including iCal import and export and a variety of different views (day, week, month).
  • CMFStaging: Adds "staging" functionality to a Plone site, so a development version and a live version can be worked on concurrently within a single site.
  • Database adapters: A variety of adapters for different databases are available for Zope, including MySQL, PostgreSQL, Firebird, SQL Server, and Oracle. These products allow Zope (and Plone, by association) to interact with a database external to the Zope installation (e.g. to pull records from a database and display them).

There are many more Products available for Plone and Zope (far too many to go into here). One thing in Zope's favour is its relative maturity compared to other CMSs, so many of the Products available for it are well developed and stable.

Plone also provides facilities for creating tools, which provide functionality (typically, site-wide properties) for a whole Plone site. For example, a tool might provide data about membership of the site, or about the site's navigation.

Another interesting feature of Zope is the possibility of clustering Zope instances to create a robust, scalable web serving infrastructure.

Template extensibility

Plone has a very flexible and powerful templating system called ZPT (Zope Page Templates), based around TAL (Template Attribute Language) and METAL (Macro Expansion Template Attribute Language), both of which are specific to Zope. These languages provide facilities for pulling elements from the object database and displaying their properties within HTML (similar to how PHP can be used to pull data from a database like MySQL and create HTML pages from it).

It can initially be confusing when getting to grips with how templates are organised and written in Plone. For example, working out which templates to edit to achieve a desired effect can be a challenge in itself. However, once you get used to the extreme separation of content from presentation, and you get to grips with ZPT, the templating system is very powerful.

For developers who don't want to create custom templates, a lot can be done simply by editing the site-wide Plone styles: for example, it is easy to change fonts, colours, borders, spacing etc.. It is also possible to add, remove or move "portlets" (small chunks of HTML displaying in side borders) using the management interface: so, for instance, you could use this to move all the portlets from the right-hand column into the left-hand column, resulting in a two-column layout rather than Plone's default three columns.


Plone has been designed using object-oriented principles from the beginning. This means that the code is very elegant by comparison with some of the PHP offerings available. The fact that Zope was developed by a professional software house before being open sourced was possibly a factor in this. One consequence of this good design, though, is that the code is extremely abstract: it is often difficult to pin down where a particular piece of functionality comes from, as it may have originated a long way up the tree of inheritance. You may occasionally find it necessary to delve into the Plone code to work this out.

Having said this, a lot of Plone functionality can be added by creating Zope Products without worrying too much about the Plone code. A Product is basically a bundle of Python code, packaged according to a packaging specification. Products have access to an API which gives access to virtually the whole of Plone. So there really is little need to customise the core of Plone, as a Product has all the flexibility most developers will need.

My short experience of Plone development indicates that the biggest challenge may be understanding how Plone is organised, where properties are configured, where I should add my new stylesheets, and so on.

Related articles: