Plone and Drupal – Which is Better?

I get this question all the time and I bet if you have experience with any of the popular CMS tools then you do too. Well I’m tired of this question so I’m going to use my own soapbox, and hopefully a bit of experience as well, to answer this question for all the people that constantly ask me.

To start off – if you’re familiar with my blog then you’ll know that I’ve worked with Plone for about 3 years and Drupal for about 6-8 months. I’ve also worked with a number of other CMS solutions from Vignette, Intraspect, Joomla, Documentum, Microsoft, IBM, etc., so before you write me off as an idiot (but reserve the right to do it later) please understand that my opinion is based on my real world experiences (good and bad) and not just on preaching from the pulpit.


I have to admit that my architect heart lies with Plone. The concept and design of Plone is really elegant and it is implemented very well. It is clear to me that the guys building the core of Plone are a talented bunch. They back this up with a very well organized open-source project and foundation. Support is great, the community is great, there are numerous conferences, sprints, training events, and the product is technically advanced.

I started using Plone for small departmental websites that were collaboration heavy. It is very simple to deploy a small site, get it working, and add-in products from various sources. After depoyment, Plone scales very well and is very stable. I have some Plone sites where the content store is pushing 10 GB in size with no slow down in performance. I have about 10 sites on one 380 DL server with 4GB of RAM. Each one is fairly large, but when combined with Apache and Squid these sites all perform incredibly well. The system is very stable as well. In 18-20 months I do not think any Plone server has ever crashed.

We use a number of add-on products with Plone: Quills, Plone Software Center, Plone Help Center, Zwiki, Plone Gallery, and others work well. We have customized a number of skins and visual themes. We have created some of our own products as well. Developing in Plone is elegant and a dream for OO people, but does present some difficulties for most mainstream developers. I think in general terms this is a weakness for Plone. Although the design is great, there is a steep learning curve to start development: learn python, learn zope, learn ZODB, learn UML, learn Plone. Yikes! This curve is a major inhibitor to Plone adoption. There are not a lot of developers out there that have the time to learn all this stuff. It takes a major commitment. The result is that there is a smaller core of people building add-on products in comparison to other CMS solutions.

Once you get used to Plone development, building very sophisticated web applications is amazingly easy. You really need to experience this to understand it. Development involves building a UML model, developing validation rules, and then some UI rules and graphical design work. All the form rendering and logic is handled thru generator tools like ArchGen. As a developer you just concentrate on your objects and business rules. Python has a couple of IDEs for programmers: ActiveState’s Komodo and the PyDEV Eclipse plugin are the two best.

Plone skin/theme development is pretty easy as well, but you need to know CSS, HTML, XHTML, and you need to know how to deal with the Zope application server. Luckily some of the Plone core developers (most notably Alex Limi) have developed some really great documentation (another strength of Plone) around theme development. Plone 3 adds a lot of AJAX functions to the UI. I have not yet tried to build a Plone 3 skin.

From the content side Plone uses a very familiar folder/file hierarchy that is intuitive for everyone. Creating a page is dirt simple. Adding images, linking them , updating pages, and getting them published could not be any easier. What’s more difficult in Plone is how to hide things from people and how to manipulate the workflow engine. This requires some configuration, but can be done once you learn how.

For me the main problem with Plone really is upgrading. Moving up to a new version can really be a nightmare. For one thing there is no “upgrade” program that reliably deals with things for you. You basically copy over python files and restart the server, crossing your fingers, and if stuff does not work your only choice is to reindex stuff, update schemas, blah blah, and pray to the almighty that everything will be ok.

The ZODB backend’s unfamiliarity does not help either since most developers will not be familiar with squat about it (myself included). I’ve successfully upgraded several sites with Plone and never has it been smooth or easy and never has all my content come over with 100% success. It usually takes many attempts to get it right or simply making a decision to leave some content behind.

Add-on products are another issue with upgrades. Since these products are not version coordinated with Plone you can get stranded unless you are willing to dig into these and upgrade them yourself.


I don’t really like Drupal. I don’t like PHP either (I’m a C++/Java programmer).You know this if you follow my blog. I’ve been working with Drupal for about 6 months. I have to admit however that I am starting to appreciate Drupal. To me Plone is much easier to get started. For generating a simple website, Plone is hands-down easier. I know this flies in the face of everything you hear on the Internet, but I think it is true.

Getting up and running with your own Drupal server can be a serious pain. There’s no “point-click” installer due to license constraints with some of the products you need. I’ve found the instructions on to not be that great. You need a bunch of things installed: apache, php, mysql, php extensions, and then Drupal. Ugh, but you’ve got my post for Win32 users 🙂 so do not despair. 🙂

Despite all the ugliness of PHP, it has a familiar programming metaphor that any seasoned developer can start hacking in 10 minutes. The same is true for the relational backend. These two factors – ugly and brutish as they are – do make it easier to get over the hump for developing new features, skins, and software products. I was able to step in a do things with Drupal that I’m still not able to do easily with Plone.

For example diagnosing database errors and data type errors. I still can’t figure this out in Plone, but in Drupal it is not a huge problem. Here’s a great example of a problem and how I could figure it out without too much of a problem. I could not do something similar in Plone and Zope. I just don’t know how. PHP as a language bothers me, but there are a number of good IDEs that offer excellent support for PHP. Making it easy to get in and develop things quickly gives Drupal a major advantage because the community momentum grows at a faster rate: more add-ons; more themes; more help on major upgrades.

From the content creation perspective, Drupal is not as simple as Plone. Users need to create the navigation menu, set the default pages, and screw around with a lot of properties to get things right. For example just getting pages to display using their full HTML support requires a number of steps. Getting a page to be the main page for the site takes administrator actions. Even simple things like linking from one page to another is complex and requires you to understand Drupals “node” concept rather than simple folders, URLs, and files. Once you get used to it, the model is ok and you can start to see some advantages in how you can control the menu structures very tightly. I still have some troubles for example with FCK: How do I link to something other than an image? Nodes to do show up as linkable objects! I can’t figure this one out yet so I have to manually link anything other than an image with an absolute URL. Not cool.

Another big area of strength for Drupal is the overall size of their community. It is much larger than Plone’s. This results in a lot more products and people to help with trouble. It also has drawbacks – there are a lot more half-baked products and poorly documented things. Documentation on Drupal is better than t first appears. As with most thing on their site, if you can find the documentation, then you are generally in pretty good shape.


So ok – what’s the bottom line? Ok –>I’m not going to dork out. I still prefer Plone, but I’ll admit that I do have a growing respect for Drupal too and will start to use it more and more. In some ways Drupal is easier to screw around with. I live in the traditional programming and relational world so for me it is just easier to get into the guts and mess around.

Here’s how I how answer the main question when people ask my opinion on which to use:

Go for Plone if:

  • You want something very simple and want users to be able to create pages and things with very minimal training/intervention.
  • You think you will have sophisticated applications to build that make learning the technologies worthwhile.
  • You envision large sites where scalability and “enterprise” quality are built in. I mean come on the CIA uses this stuff! It rocks!
  • Think you need advanced/early support for Internet content standards (ex. OpenID, Dublin Core, AJAX).
  • You intend to standardize on one platform for all CMS applications.

Go for Drupal if:

  • You have needs that center on static content creation (blogs, wikis, forums).
  • Have developers that can step right into the PHP/MySQL space easily.
  • You know that you need to integrate external relational data into your CMS applications.
  • Have mostly mid-sized sites with medium scalability concerns.
  • You will have multiple tools for CMS applications.

If you disagree – let me know why. I’ve been known to change my mind from time to time 🙂

11 Responses

  1. berenerchamion says:

    Hi Jeff Eaton – I screwed up and by accident deleted your comments. Can you re-post? Very sorry! 🙁


  2. berenerchamion says:

    I’m an idiot and deleted some comments like:

    “Hey! Thanks for the great writeup. Most of my time is spent in Drupal space, but I’ve been poking around Plone and Django yo learn more about their architectures. I’m not sure that I’d disagree with any of the comments you made about it, though I’m curious what the scalability and performance related issues look like with Plone. It seems like there’s not a lot of information sharing between OSS projects on how to improve those kinds of things. I’ve worked on a number of pretty heavy-duty Drupal sites, but I’m not sure how they compare in traffic and load to Plone and others.”

    I’d be particularly interested in finding out more about Dublin Core support. Drupal’s CCK plugin provides a lot of rapid customization of structure content types, but there’s no clean way to share the structural information with systems outside of Drupal right now. Universal interchange formats for that kind of stuff could really improve things.

    In any case, thanks!


    Also (quick follow-up question)… How would you describe the distinction between dynamic and static content? You mentioned blogs/wikis/forums, etc in the ’static’ category.

    Sorry for screwing up…

    To answer these:

    On Plone Scalability:

    Plone comes with several excellent integrations with Aapache, Squid, and a Plone product called CacheFu. Combining these things with the Zope application server and the ZODB object-oriented database you can achieve some pretty incredible performance statistics. Wehn correctly configured on a decent capacity machine, Plone can really pump out content, especially if you have a few GB of RAM to spare.

    With Drupal and other PHP tools I have found their sweet spot to be at the lower end and maximizing efficiency for smaller scale websites. This is not to say that you can’t run a big PHP website with Drupal or PHP alone, but that I have not found an easily implemented solution for this.

    On why I call “wikis/blog/forums” static web applications – the content is dynamic but the application/presentation is static. I think of these these as so common and standard in format that they have become “static” in nature and everyone knows what to expect. Contrast this to custom web applications where content can appear in any shape/form and can vary from one site to another even though the “name” or “description” of the content is the same. I guess that’s probably confusing.

    I think Plone has a leg up on Drupal for design of new and dramatically different types of web applications. For example there are laboratory information management systems built on plone that are responsible for capturing instrument data, creating reports, and publishing it.


  3. Jeff Eaton says:

    I think Plone has a leg up on Drupal for design of new and dramatically different types of web applications. For example there are laboratory information management systems built on plone that are responsible for capturing instrument data, creating reports, and publishing it.

    Yeah, that makes sense. I’ve had good success presenting things in wildly different forms using combinations of Views, CCK, Panels, custom code, but everything really does orbit around the central concept of the ‘node of content’. If you aren’t using something like that, it’s just a needlessly heavy db abstraction/session management/url routing/caching framework.

    I’d love to kick around ideas on the optimization front. A lot of attention definitely goes to the low end for optimization, though there’s work going on at the high level to provide swappable caching infrastructures, better compatability with squid, memcached integration, and so on. None of those things are to the point that someone could drop them in place and just flip the switch, though.

    Anyhow, thanks again for the excellent writeup!

  4. berenerchamion says:

    I have not seen any good overall write-ups on drupal scaling, but with Plone Joel Burton has done a number of excellent presentations (search on and there are a bunch of other good ones on by others. I did a “how to” on my blog on building an “industrial strength” plone server. Alot of of my writeup is based on apache and squid – many kudos to Joel and Alex Limi. Joel and others talk about additional scaling using the ZODB clustering. I have not yet tried that.

    Thanks for your comments!


  5. tmg-studio says:

    This is a great example of the kind of dialog that needs to exist for Drupal from a marketing perspective.

    I have been actively deploying sites with Drupal now for over 3 years and in that time I have tried many other CMS systems, including Plone (which by the way, I agree is a very cool framework). All of them have their strengths and weaknesses, and I agree that on first glance Drupal can be a bit hard to grok, but once you get hooked, it is hard to see a web development project and not see Drupal as the answer.

    Recently, I was given the task of converting 2 very large sites from a mish mash of PHP and ASP (yes both sites had database backends in both worlds, go figure). I had a timeline of three weeks.

    19 days, 36 content types, 19 views, and 7 panels later, I had two very functional sites, setup under a multisite install, sharing content yet existing with separate users and workflows. I cannot imagine rolling this kind of setup any other way.

    Please continue to report your thoughts and insights back to the community because it is perspectives like your own that can really help move the Drupal project forward.

  6. Jon Stahl says:

    Great post, I think you hit a lot of ideas spot-on.

    One thing I think you’ve missed, though, is your statement that “Plone doesn’t have an ‘upgrade’ program.” That’s simply not true. The Plone team puts a *ton* of effort into their migration routines (which are part of every copy of Plone!). Most difficulties in Plone migration stem from third-party add-ons and/or custom code which the authors don’t upgrade. Plone itself can’t control that.

    It is true that nearly three years ago, the Plone 2.0 -> 2.1 migration was unusually rough, but the Plone team learned a lot from that experience, and the 2.1 -> 2.5 and 2.5 -> 3.0 migrations have been very smooth for most people. But then again, we are very conservative about using add-on products and careful to make sure our customizations are “sane.” Not everyone is.

  7. Jon Stahl says:

    One other thought: the great beauty of Plone is that you don’t have to know squat about the ZODB database. It just works. It’s ultra-reliable. Stuff goes in, stuff comes out. It’s easy to back up, and easy to administer, and as you point out, it scales really big. I don’t know about you, but I *love* not having to think about SQL.

    If you need to integrate with relational databases (and lots of us do), then there are some great Python SQL libraries available, like SQLAlchemy, which can be used through software like collective.tin (
    and other techniques. Plone + SQL data *do* play nice together after all!

  8. berenerchamion says:

    Hi John,

    It was the product upgrade issue that I was referring to. The Drupal project seems to be much more focused on aggressively getting popular modules and theme upgraded and working on new releases including upgrade scripts for data conversions irregardless of whether or not these are “core” or not.

    This simply isn’t true for anything on Plone except the core product. For example if you have a Plone 2.5 install that used PSC and POI (two of the best Plone products) you are basically unable to upgrade to Plone 3, even today, due to duplicate key conflicts in the catalog. This is an open bug in PSC (#57) that I opened last September. With no ETA for resolution from the PSC developers, I’m basically screwed for just the thing you say is good: ignorance of ZODB.

    I agree with you that ZODB is a fantastic and mysterious tool. Its fast, works great, and you can do many amazing tricks. The problem is that troubleshooting it is essentially impossible and can have dramatic impact on you when upgrading or trying to figure out how to fix something. To make things worse there are (from what I can find) no tools to browse or query the database directly on Windows.

    I certainly don’t enjoy SQL either, but at the same time I understand how it works, can get in with tools (GUI or command line), troubleshoot, update data directly to fix specific data issues, etc.

    Don’t get me wrong – I’m a big fan of Plone, but if the Plone team does not recognize that the vast majority of people simply are stuck on 2.x due to upgrade issues with “popular” modules I cannot see how people will continue to build on the tool.

    Perhaps establishing some kind of “level” for products based on number of downloads, or number of releases, or quality of support, should be established. Products that rank high could be “helped” somehow by the core team during upgrade cycles. Just an idea.

  9. Chuck Linart says:

    I love Drupal, but the messiness of PHP has me looking at other options. I wonder if anyone has successfully managed to migrate content from a Drupal site with hundreds of nodes to Plone. I know nothing about Zope and ZODB and don’t even know where to start.

  10. Beren says:

    Hi Chuck,

    Unfortunately I don’t. I did successfully move stuff from Plone to Drupal. I don’t think it would be terribly hard to move stuff back and forth, but I think it probably would depend on what kinds of nodes you have in drupal and how you want these to show up in Plone.

    Regarding where to start with Zope DB – I would suggest, but that’s pretty obvious.I guess. There aren’t a whole lot of other sites out there with great content on the zope db. Another place to look is the site. There are a number of good things there – although not specific to importing content.

    I agree about the “php mess”…as much as I like drupal I find myself drifting back to Java.

Leave a Reply