To Plone or not to Plone?

Simple Answer: Don’t go there.

Plone, despite its flashy coat of paint, is still a development work in progress. Upgrades from version to version have no guarantee except that they will be problematic. For now, and for many years to come, content management systems based on a relational database are the way to go.

More details later, but save yourself the hassle, unless your a python hobbyist that likes to mess around with code a lot.

4 thoughts on “To Plone or not to Plone?”

  1. Yah, but…
    How come so many places are using plone? In just the last couple of days I noticed these two:
    The Free Software Foundation: and
    Triumf Communications Task Group:

    Surely the Free Software guys must know a good thing when they see it. It pains me to see so many smart guys like you, Danny and Simon getting frustrated by plone. I certainly trust your opinions, too. However, there must be SOMETHING really wonderful about plone or you would not find so many people adopting it.

    Here’s what I think it is: once you get through the pain of setting it up, it is REALLY EASY to use. I hate to say it, but for a normal mortal end-user, it’s easier than using DataFace, for instance. Everything works. And you can have everything working nicely with workgroups, with multiple languages and with good authentication and security. All this (and more) is handled well in plone. If you wanted to make DataFace work with multiple languages just think what would be required. And that’s just one example.

    I suppose the thing about plone is: it’s two or three steps ahead of you. As a young programmer, you have yet to discover that people are going to come along (maybe in only a few months) and say: “Can you make me a version of DataFace that handles workflow?” or multilingual data, etc.

    I suppose the complaints you make are correct, and I sure hope the plone crew can address them, but in the meantime if you are a place like TRIUMF or FSF, or for that matter and you need all those capabilities and you want it to be free and open source, there are not too many choices.

    That’s what makes plone so popular.

  2. Ah.. you came across a blog from a bad day with Plone. There have been many bad days with Plone (though there have also been a few good days). The blog may paint an overly one-sided picture, however, as you point out here. Plone does have many nice features tied into it (such as i18n language support and workflow support) and the usability is excellent. All of these are nice features.

    Comparing Dataface to Plone, however is not a fair comparison, since they are two different things. Dataface is an application framework, where as Plone is a Content Management System. Dataface is better compared to Archetypes. Archetypes is a framework for developing content-types for Plone. Dataface, on the other hand, is a framework for building applications for MySQL databases.

    There are, however, a number of free content management systems that can be compared to Plone.
    – Drupal (
    – Mambo (
    – Magnolia (

    There are thousands more…

    That said, I chose to use Plone to set up the Dataface website because I am familiar with it and, thus, am able to work with it quite easily. Plone does offer some excellent re-use and modularity. For example, I was able to add PloneHelpCenter to my Plone install which automatically gave me a help centre with content types for tutorials, how-to’s, FAQs, Reference manuals and more. This is very convenient, I must say.

    However, I am constantly on the look-out for better alternatives that, in particular, use a relational database back-end so that the “data” is a little bit more secure.

    Your comment about plone being two or three steps ahead of me, I have to disagree with. I regularly deal with software that needs to handle workflow, and I have dealt with a couple of instances where multiple-languages were an issue, and if someone were to come along and say “Can you make me a version of Dataface that handles workflow?”, my answer would be “yes” (since workflow is basically just a fancy word meaning that data has an “state” associated with it – which is routinely modelled in a relational database by adding a “state” field to the table in question).

    I do recognize that Plone has accomplished a LOT. However, I feel that it suffers from the “let’s turn the web into rocket science and not document it very well” syndrome. Perhaps the reason it seems like they have turned it into rocket science is BECAUSE it is not documented very well – let me qualify that comment because if you go to there seems to be a myriad of documentation. There are lots of “how-to” documents that you can sift through, so you may luck out if there is a “how-to” document for the particular thing that you want to do. It falls apart at the “reference documentation” stage, where you need a particular piece of information about a class or an object or a task. DocFinderTab will show you the names of the methods available for an object, but there are no code samples showing you how to use them. Any time that I have had to figure out how to do something at the python level, I have had to look at existing products as try to figure out what they were doing (and often these weren’t helpful either). Plone could learn a lot from the PHP method of documentation where you can type in the name of a function or class and immediately see a description of the method or class, along with code samples, community comments, and links to related methods and classes. I have often thought of starting up a more PHP-style documentation centre for Plone but it would be unfeasible for me to do this without support from the core of the Plone community (not to mention I just don’t have time). I have fancied theories in my head that perhaps the main players are leaving it undocumented so that they’re expertise will be more valuable. (of course this is ridiculous).

    Perhaps as we move from 2.1 to 2.2 it will become better documented and offer a smoother upgrade path and I will forget about the pains of the past and become a wholesale supporter. Only time will tell.

    Anyways, Thanks for your comments, Barry. This blog-post needed a little bit of balance.

  3. I still say plone is ahead of the pack–maybe only one step, not two steps–when it comes to a lot of things. E.g. multilingual support. I could not find a good multilingual solution in Ruby on Rails recently for instance. A quick search of Drupal found this recent post which indicates they are getting there, but they are still not as far along as plone that comes out of the box with support for 42 languages including right to left ones like Arabic and Hebrew.
    I certainly like your idea for a documentation system that includes code snippets. The first book I ever wrote (Concise Guide to HyperTalk) was just this. I took every function and operation in HyperTalk and created code snippets for each one. It sold tens of thousands of copies. Plone sure needs something like this. I hope you do it.

  4. I have to agree with Steve on the upgrade from 2.0 to 2.1 was unbelieveablely difficult. So many things were broken and getting site errors everywhere. They really should have come up with a better upgrade script before relieseing a final reliese.

Comments are closed.

comments powered by Disqus