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
Platform: Zope application server; Zope is licensed under the GPL-compatible Zope Public License; evaluation was done with Zope version 2.7.4-0
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.
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:
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.
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.
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.