Content management with Plone

As those of you who have read my post Building a university website will know, I've recently been working on a website that uses the open source CMS Plone. I promised a more detailed article on Plone, and this is it.

Now that I've spent a couple of months first learning Plone and its underlying technologies, and then using it to build a fairly large website, I'd like to share some of my impressions of it, both good and bad. I'm not going to provide any code examples. Instead, I'll focus on topics related to ease of use, accessibility, web standards compliance, and developer friendliness.

Some basic Plone facts

Plone is built on top of Zope, a web application server and development system written in the Python programming language. Zope has been around since the late nineties, and Plone was created in 2001.

Zope has a built-in database and web server, so you don't have to have anything else. However, it can also be used with web servers like Apache and Microsoft IIS, and most relational database systems, and the recommended setup is to run Zope/Plone behind a web server like Apache.

Plone is highly customisable and extensible, is technology neutral, has an internationalised interface, and many add-ons (called Products) are available.

Platform compatibility

One of the major benefits of Plone is that it runs on just about anything. When I took a first look at it, I installed it on my PowerMac G4 at the office with no problems. It just worked. When the serious development work began, I installed Plone on an Apple XServe G5 and moved what we'd done so far to that machine. Again, no problems.

The client is hosting the site on their own server, which is running Sun Solaris, and when development was done we successfully moved the entire site to that server. Plone also runs on Windows, Linux, and BSD.

Unlike many other CM systems, especially commercial ones, Plone's administrative interface works with just about any web browser. It works best with modern browsers, but you'll get by with an older one if you need to. In other words, using Plone will not force you to use Internet Explorer for Windows. That is a major benefit. Hello, all you CMS vendors that lock yourselves into Microsoft technology: It's time to wake up.

Basic installation and setup

Out of the box setup, at least on Mac OS X , is very easy. It just works, and I had Plone up and running in a matter of minutes. Excellent! As far as I know it's just as easy to get started with the Windows installer, but I don't have any hands-on experience with that or the Linux version. If you know otherwise, feel free to speak up in the comments.

XHTML + CSS quality of default templates

The default templates are better in this regard than those of any other CMS I have worked with. The default templates actually validate, and there is a tableless skin (a Plone skin is a set of page templates) included, although it isn't the default. Still, much could be improved.

Many Plone skinning tutorials assume that you're just going to edit the CSS and use the XHTML from the default templates. That may be acceptable to someone doing only very light customising, but we chose to rebuild just about every line of XHTML from scratch. We also completely replaced the default CSS files.

This was mainly to reduce clutter, remove extraneous whitespace, and to improve on document structure and semantics. The default templates use lots of presentational class names, unnecessary class attributes, and plenty of non-structural span and div elements. They also include a 27 KB JavaScript file with functions that the site we were building has little or no use for. For some strange reason, a base element is added to all pages before they are sent to the browser. Apparently there is no way to remove it. Quite annoying.

My point here is that there is more to the spirit of web standards than just using valid (X)HTML. Despite my complaints, Plone does do very well here when compared to others.

Accessibility features

Again, Plone does well here in when compared to other CM systems. However, there is still some room for improvement. As an example, the tabindex and accesskey attributes are used somewhat overzealously.

The tabindex attributes, which are used to define the order in which various parts of a document get focus when the user navigates by pressing the tab key, are for the most part unnecessary. The tab order established by the XHTML source is fine, so the tabindex attributes just add clutter.

When it comes to accesskey attributes, specifying one for all non-content links and form controls is nice in theory. However, they are very likely to conflict with browser or operating system shortcut keys (or with each other) unless they are applied carefully and manually. Some accessibility experts even argue that using the accesskey attribute, while being great in theory, is more or less pointless.

WYSIWYG editing

Plone comes with a WYSIWYG editor called Epoz. Other editors can be used, but we chose to stick with the default. Epoz is based on the editing capabilities built into Internet Explorer 5.5+ for Windows, Mozilla 1.3.1+, and Firefox (Firebird) 0.7+. This caused some confusion at first, since the behaviour is slightly different depending on which browser you're using while editing a document (try deleting a table in Mozilla or Firefox without switching to HTML mode -- you can't).

Epoz does a reasonable job compared to many other WYSIWYG editors in commercial CMS packages, but the code produced is not good enough by my standards. Yes, I'm really picky about this.

Fortunately, it's possible to configure Epoz to use HTML Tidy to clean up the XHTML before saving it to the database. Since I wanted to minimise the risk of invalid XHTML being entered, I installed mxTidy on the server and configured Epoz to use it. I also wrote a whole bunch of regular expressions to further clean up the markup after HTML Tidy has done its job. The end result is not perfect or foolproof, but acceptable.

A package like Plone that claims to be fully standards compliant and accessible would really benefit from having a very strict WYSIWYG editor that makes it impossible to enter invalid XHTML. XStandard is the only such editor that I know of, but unfortunately it's commercial and only works on Windows (though it does work in Mozilla and Firefox as well as in Internet Explorer), so it isn't really an option for an Open Source system like Plone.


No query strings are used in Plone URLs, which is good. You can specify a specific URL fragment for each document (or other content object) you create. The complete URL is then composed of the URL fragments found in the path to the current object. If you don't specify a URL fragment, one is created for you. Automatically created URL fragments aren't exactly user friendly, but at least they are search engine friendly.

I miss the ability to specify a document's full URL. That would allow you to create a short URL for a deeply nested document, which is sometimes desirable. Other than that, Plone's URLs are fine.

Learning curve

In my opinion, the major drawback of Plone/Zope is the extremely steep learning curve. Plan on spending a few weeks getting to know Zope before even looking at Plone, unless you're going to use it as is, without making any customisations beyond tweaking the CSS.

To customise Plone, you need to learn the basics of Python, Zope's templating language TAL, the Zope Management Interface (ZMI), and when to use what. Most likely you will also need to learn Archetypes, which is a framework used to create new content types. Having to learn everything at once can be incredibly challenging, frustrating, and time consuming. The available documentation does nothing to make it easier either. More on that later.

Despite being warned of the steep learning curve, I made the mistake of jumping straight in and start customising Plone, instead of learning more about Zope first. I just couldn't imagine the learning curve being that steep. Looking back, things would have been a lot easier if I had started by reading up on Zope, TAL, and Python, and then tackled Plone. This is especially true when you want to rewrite all of the templates and the CSS -- doing so will require a decent understanding of most of Plone's components.


I'd really love to be able to say that documentation for Plone is good and easy to find. Sadly, it is neither. Far from it.

Documentation is hard to find, inconsistent, confusing, unorganised, incomplete and sometimes outdated. Most of it also assumes that the reader already knows the ins and outs of Zope, Plone, and Python. This only makes the already steep learning curve even steeper. I know several people have worked hard to create good and usable documentation for Plone, so please don't take this personally.

Apart from the free documentation available online there are a few books that you can buy. Unfortunately, The Definitive Guide to Plone, the book that many recommend (and I have bought and read), also suffers from assuming that the reader already knows a lot about Zope. I haven't read the other books that are available (Building Websites With Plone, Plone Content Management Essentials, Plone Live), since they hadn't yet been released when I started working with Plone, so I don't know if they are any different in that regard.

The documentation for Plone is being worked on, and what's out there is getting better, but at this moment, the lacking documentation is a major hurdle you have to overcome in order to learn Zope and Plone. Be prepared to spend a lot of time searching for answers.


Plone and Zope are Open Source software, so it's natural to turn to the developer community for help and support. In general, most people are helpful, some more so than others. I subscribed to the Plone-users mailing list, and I've sent plenty of confused messages to it. Sometimes, especially in the early days, I didn't really know what to ask or what terminology to use, so I realise how difficult it must have been to help. In the end, I did manage to find answers for most of my questions.

I've found that whether you get any help or not (as well as the quality of help) depends a lot on how you ask your questions. You need to be as specific as you possibly can. Unfortunately that can be very difficult when your problem may be related to Plone itself, Zope, Python, your server setup, etc, and you don't know where to start looking. You'd better make sure you have looked everywhere before asking though, or you're going to get some RTFM responses.

I'd like to quote Andrei Herasimchuk here: I would RTFM if there was an FM to FR. With documentation being in the state it is, I'm sorry, but there will be stupid questions from apparently clueless newbies.

It's hard to be a Plone newbie. Remember that!

The portal emphasis

All CM Systems aren't suitable for all kinds of websites. Out of the box, Plone's emphasis on being a community/portal CMS makes it a bit confusing when that's not the kind of site you are building. Things like people being able to register themselves as users and every user having a home folder are not really appropriate for "normal" websites, in my opinion. This is not really a problem, since these features are easily removed. I'm mentioning them because I was confused by them at first.


By default, Plone is set up for development, not deployment. Before launching a Plone site, you need to make some configuration changes to enable caching and make sure debug mode is off. If you don't, performance will not be good, to say the least. Unless your site gets very little traffic you will want to use a caching proxy in front of Plone, something that is highly recommended. Zope is not the fastest thing around, so anything you can do to reduce server load will help.

Summing it up

If you've read this far you might think I'd recommend against using Plone. Well, that depends. You do need to be aware of the really steep learning curve. Unless you have previous experience with Zope and Python, count on spending a lot of time -- much, much more than you think -- learning, searching for documentation, browsing mailing list archives, sending questions to mailing lists, etc. If you're prepared to do that, go ahead. If not, maybe you should look at other systems. I know I definitely would have, had I realised how hard it is to learn (or taken the advice I was given).

Don't get me wrong. Plone is a very powerful and highly extensible CMS. It's just incredibly hard to learn to develop for, especially if you don't have any previous knowledge of Zope and Python. I'd say that this is to a large extent because of the poor documentation. The lack of really good beginner's tutorials and some kind of roadmap that tells you where to start and where to go next has made me send countless messages to the Plone-users mailing list, hammered Google with searches related to Plone, Zope, and Python, and pull my hair in frustration.

Despite the troubles we ran into, there is something that makes me like Plone, and now that I know it reasonably well I may consider it again for similar projects. However, I'm not so sure I'd recommend it to anyone without previous knowledge of Zope and Python. At least not until better documentation is available.

Posted on March 1, 2005 in Content Management