Plone vs. Drupal, Take One
Sunday, September 2, 2007 at 12:17PM Recently, my colleagues and I decided that we needed to replace our public website's content management system. After some preliminary evaluation, we determined that we would evaluate Plone and Drupal. In the end, we went with Plone at work, and I've been working with it a lot for the past few months. However, I was impressed by Drupal, and that's what I use to run this blog.
Having seen both worlds a bit, I see a lot of comparison of the two systems. Here, I'd like to present my take on their similarities and differences. I will admit up front that I am more intimately familiar with Plone, and that, all things being equal, I prefer python to PHP. However, really, they are both technologies, and technologies are supposed to solve user problems, not necessarily make me happy; I will try to keep that in mind while writing this evaluation. If I misstate a limitation/feature or am ignorant about some active project, please let me know in the comments, and I will update this post accordingly to keep it accurate. Both systems are extremely feature rich and complex, and I do not claim nearly perfect knowledge of either. My comparison will primarily cover Drupal 5.2 (which this site uses) and Plone 2.5 (which I work with for my employer). When talking about third party code that changes the way the systems work, I'm going to use the term add-on, because it's neutral.
On a meta note, I realize that this is a little long for a blog post. I'm starting the topic on this blog, though, with the hope that people will respond and help me correct inaccuracies and draw together more resources, leveraging the usual tools of the bloggosphere. As the sections get a bit more developed, I'll move this content to a format that's more appropriate (e.g., something like an article) and place a link from here to the updated and reorganized version.
Table of Contents
- 1 The Basics, for the Uninitiated
- 2 CMS as a CMS
- 3 Extensibility
- 4 Scale, Speed, and Deploying
- 5 Community
- 6 Summary
The Basics, for the Uninitiated
Plone and Drupal are both Content Management Systems (CMS), which means that they make it easy for non-technical users (i.e., not designers or programmers) to publish content to the web. They both offer powerful templating systems (to ensure that your site has a consistent look), flexible information architectures (IA), fine-grained permissions, reasonable user models, and sane extensibility. Both CMSes are open source projects, supported by communities of programmers, integrators, and designers.
CMS as a CMS
The most important part of a CMSes job is managing content, meaning making it possible for nontechnical users to publish information and making it easy for website visitors to find that information. For me, this breaks down into easy of actual publication (how much do you need to do to edit your website) and flexibility of IA. In my evaluation for my organization, Plone won this; we had specific IA needs that Plone supported well. However, your needs will probably be different than ours, so I'll try to provide some general strengths and weaknesses, too.
Easy Publication to the Web
For me, a CMS should make it very easy for a content creator who does not know much about web technology to publish content. Out of the box, Plone wins this one; Plone's built-in and tightly-integrated Kupu editor removes any semblance of HTML from the user's sight, reducing the barriers to web publishing without any configuration. For users who prefer to use HTML or some other markup (such as wiki syntax), Plone also offers options, out of the box. Because all modern Plone installations come with Kupu, many Plone add-ons interact well with Kupu, which saves configuration time and improves usability. However, Drupal is not far behind there; Drupal modules integrate several rich text editors (e.g., FCKEditor, TinyMCE, Dojo Editor) with Drupal easily, and with a little bit of pear magic, it's not hard to enable mediawiki syntax and forgo a rich editor (as I have on this blog).
Placing content in the two systems is pretty different, which reflects the systems' assumptions about information architecture. Although I discuss this more below, briefly, with Plone, because the content is generally organized in a hierarchy, users navigate to the correct place on the site for their content and add it to a folder. In Drupal, because tagging is used heavily, users instead pick the correct "node type" for an add-content menu and then tag it accordingly, trusting the CMS to sort the content accordingly.
Flexible Information Architecture
This one is a tie, out of the box; the two systems handle IA very differently, and your mileage will vary depending on your needs.
Plone, by default, supports hierarchical navigation most strongly. It has built in folder and page types, and generally, pages go into folders. Plone's folders are pretty flexible (they allow a variety of views), and hierarchical IA is intuitive in Plone. Plone also offers a rudimentary keyword tool to support something like folksonomy, and it has a content type (smart folders/collections) that allows site builders to aggregate content on the basis of any metadata (e.g., page location, creation date, keywords, creator, etc). This allows users to, out of the box, create an IA that is keyword driven, assuming that the site creators don't need anything particularly sophisticated (e.g., multiple keyword lists, hierarchical lists, a highly-usable tagging system).
Drupal excels in folksonomy-based IA. The base Drupal installation includes a powerful tagging module called "taxonomy" that allows for a wide variety of tag structures (from simple to poly-hierarchical with synonyms; from "free tagging" to controlled vocabularies) and an intuitive interface for modifying tags. Taxonomy is a really elegant feature, because it scales nicely with a site, letting an administrator start with a simple setup and grow. Unfortunately, in our experience, a hierarchical site is extremely difficult with base Drupal, and even adding several Drupal add-ons did not help the situation much.
In the end, the system that wins will generally depend on your requirements. Both can be coaxed to do any IA; Drupal's category add-on promises sophisticated hierarchy in Drupal (but mind the warnings), and Plone's ontology offers extremely sophisticated keyword management and tagging (but note that it is not a final release, nor are its dependencies). However, IA is hard (neither folksonomy nor hierarchy will scale well without serious planning), and trying to use third-party extensions to modify something as crucial as a CMSes IA can be risky (add-ons do not follow the same release schedules as the core CMS, can go inactive, etc).
Extensibility
In reality, it's a tie. For me, Plone wins. Both systems have proven themselves to flexible and extensible. Plone has hundreds of extensions, and Drupal thousands. Both offer extremely sophisticated APIs for developers, patterns to follow for extensible development, and API references and books to help new developers get up to speed. They also both have their warts: storage logic is not always cleanly separated from business logic in Drupal; you'll find plenty of Python code in Plone's templates that mingles business logic with presentation.
The major reason that Plone wins for me is a utility called ArchGenXML (AGX), for which I've found no analog in Drupal. ArchGenXML lets me draw a Unified Modeling Language (UML) diagram, export it as XMI (an XML format for diagrams), run the file through a script, and have a working Plone extension that follows established software architectural patterns. It will setup a unit test framework and scaffold tests for methods, and it integrates with several of Plone's infrastructural add-ons to make complex use cases more manageable. It's a great learning tool, and it really speeds up development; if you can follow a tutorial, you can create new Plone add-on. As a bonus, you get a UML diagram that can help explain your code to other developers. It let me develop an entirely new content type (a folderish page) for Plone in hours; I simply have not found anything similar in Drupal.
However, it would be unfair not to note that, with Drupal, many things that I use AGX for are handled through the web. Drupal's basic unit of content, the node, is highly customizable in how it is displayed, named, and organized, and with modules like Content Construction Kit (CCK), it is trivial to add fields to a content type. I am not a big fan of working through the web on CMS extensions (Plone offers something similar in content flavors, which I also eschew), but it certainly does reduce the barriers to customization. It may not be of the same power as AGX (because in AGX, you're dealing with the APIs and can add all kinds of logic to your model), but it also allows you to extend your CMS quite a bit without writing any code.
Briefly, PHP vs Python
Once you start talking about development, you invariably raise the specter of a language debate. I have no expectation that I can avoid the ghoul, and I made my position clear in the introduction. However, lots of people know PHP, and for many web projects, it is the tool best suited to the job (many very simple use cases will be significantly easier in PHP than python on the web). It also has warts (mysql_escape_string comes to mind, and its OO implementation is not well regarded) and a less-than-stellar reputation on security. However, it's not unreasonable to find designers who can hack PHP, which means PHP programmers are going to be cheap (compared to, say, Java programmers). Furthermore, although I hear PHP often maligned, I've seen plenty awful C++ code, too; PHP may not be a terrifically elegant language, but the quality of the programmer is going to determine the quality of your code, not the language (assuming you're not insane and thereby using something like Malbolge).
Python is a well constructed language that prioritizes clarity and simplicity (see Python's design principles in 19 aphorisms). It is a versatile language and is used for web applications, system administration, and even GUI desktop applications. Python is also not as popular as PHP; this means you're going to be hard pressed to find a non-computer scientist who can come in and maintain your Python codebase (there are, of course, exceptions). This can mean a higher total cost of ownership of your system, and it is certainly something to consider. If you're going to need a lot of complicated custom work for your site anyway, this cost may be neutralized (really good PHP programmers aren't going to come cheap, either); but, if your needs are in that painful zone that can't be done "Through The Plone" but don't require a serious new product, it's something to consider when making your choice.
Briefly, LAMP vs Zope (and the ZODB)
As with PHP vs Python, this is, in part, a popularity contest. The Linux, Apache, MySQL, and PHP (LAMP) stack is extremely popular, and is known to work well. Trivial setups are very straightforward -- drop the PHP files in the right directory, setup a user for the database, run the setup script, and you're up and on the web. With Plone, initial setup might be easy (run the installer, run the start command), but to go live, you're definitely going to need to setup (at least) some sort of proxying, which is enough to scare off some folks. Additionally, many developers have not worked with an object database like the Zope Object Database (ZODB) before, and it is different. To me, it's wonderful; I have no desire deal with SQL directly. It greatly simplifies the storage layer; in most cases, you design Python objects to model data that meet your user's needs, and Plone handles persistence without your needing to think about it. The ZODB excels in organizing hierarchical data, something very important to many content management setups. Although it's not as popular as MySQL, the ZODB certainly isn't difficult to use or manage, and it really simplifies the model layer for programming. It, however, does not handle relational data or BLOBs very well (yet), so if you're site is going to be a social network or YouTube clone, it's probably not a great choice. The ZODB works well for Plone though, and it is certainly not a strike against the system; it is really pretty simple to run and manage.
Amusingly, in my experience, the hardest part of configuring Plone to go live has been the part that has nothing to do with Plone -- getting Apache's httpd.conf and squid's configuration right. This discussion, of course, will lead directly into talking about speed and scaling.
Scale, Speed, and Deploying
I do not know of hard numbers about the actual performance of Plone vs Drupal -- I sometimes hear people complain that Plone is "slow," and I see the reply that "every feature-rich CMS is slow in nontrivial setups." If you have any hard data about Plone's and Drupal's performance relative to one another, please leave a comment and I'll gladly link to you here. I do know that Plone's general philosophy relies on sophisticated caching, and with squid or varnish, it's perfectly feasible to create Plone sites that support huge numbers of visitors (see, for example, Discover Magazine, the CIA's website and Novell's website, all of which run on Plone). Because I know that Drupal can be setup to work with squid, I have little doubt that, for anonymous users, it would perform just as well (see, for example, the Onion and Spread Firefox).
Otherwise, speed is going to be generally hard to compare, because it really depends on what you're doing. Nothing out of the box is going to work well under the stress of, say, millions of users sharing videos. Plone is going to be a bear with relational content (think social networks), unless you feel like replacing huge amounts of its subsystems yourself. I've not looked as hard into Drupal's specific weaknesses, so I really can't speak to where it might fall down; however, I have heard that systems that require many security checks (such as organic groups) will kill performance. If you have more experience here, please comment.
Hosting Requirements
At the low end (personal sites that cost around than $10 per month for hosting), Plone requires more sophisticated hosting. I cannot run Plone with my current hosting at Site5. Drupal, obviously, is not a problem, though. Although there are inexpensive hosting services that offer Plone support, you're not going to find a lot of shared hosts who support Zope's "long running" processes. If you're hosting a personal blog with a few other pages (like modulus), Plone may not make sense, because it could easily triple your hosting costs.
At the higher end, the hosting requirements are going to start to depend a lot more on your site's content and popularity. Dedicated, virtual, and managed hosting offer many advantages over cheap shared hosting, and if your site is for anything but a very small company or personal use, you'll probably need dedicated hosting. Once you're on dedicated hosting, the complexity will be mandated by your site's traffic. Both systems run on an incredible number of platforms, and if you're site is non-trivial, your sys admin is going to be able to install either.
Security
Neither system has a particularly bad security record, and both communities keep their systems up to date nicely. Plone, because of the way its application server works, is immune to several common attack vectors (e.g., SQL injection, unvalidated input, buffer overflows, and even many XSS scenarios). For a (maybe somewhat biased) overview of Plone's security characteristics, see Alex Limi's Plone Security Overview. Drupal also strips harmful tags from input (by default, at least), neutralizes SQL statements, and offers a large library of input validation functions. It also offers a wonderful system that lets you know when your modules have fallen out of date, which is invaluable to a person who does not have a ton of time to devote to system administration. I hope Plone finds a way to impliment something similar. I would also love to see something similar to Limi's evaluation for Drupal. If you know of one, please leave a comment and I'll gladly link it here.
Both systems also offer relatively fine-grained security models for content on the site. Out of the box, Plone offers something on the order of five printed pages of security options, which are managed for individual content objects through Plone's workflow system. An administrator can then create roles, which are collections of permissions in a given context (such as the site's root, or some sub-folder), and assign those roles to either individual users or groups of users. Drupal offers something similar through its "Access Control" settings, although it is somewhat less granular (I can't, say, turn off the ability to see content listings for some users but allow those same users to get to the content if they know its url), does not have a distinction between groups and roles (at least out of the box), does not vary by context (out of the box) , and has no workflow control (out of the box). I know some of these differences are handled by add-ons (I'm using workflows on modulus), and I would not be surprised if most of the others are not also already covered by add-ons (or even settings that I've not found yet); please comment if I've missed something obvious.
Community
With an open source project, the community is probably as important as the code. Drupal and Plone have very different communities, in part because of the size of their userbases. Drupal's community feels huge; at NTEN's 2007 Nonprofit Technology Conference, in a room of 30 webmasters, I was one of two Plone users. More than 25 of the others were drupal users. Drupal's website also reflects this; the forum topic volume is very high, and there is an incredible amount of contributed content on the site. However, size isn't everything. Plone certainly has enough developers and users that I don't want for support there more than I do when working on my Drupal site. Additionally, although Plone's community may be smaller, in my experience, it is an extremely helpful one, with accessible developers and a dedicated documentation project. As with any other decision, there are tradeoffs, as will be discussed below.
Contributed Add-ons
I'm sorry Plone(istas), but, superficially, Drupal wins here. Drupal has thousands of contributed modules that modify its basic functionality (e.g., adding fields to basic content types), offer it useful features (e.g., workflows and content rules), and integrate it with other systems (e.g., openID, civiCRM, salesforce). Obviously the add-ons are of various quality, and there are certainly abandoned ones, but they are also legion. Drupal's huge user-base, combined with the popularity of PHP, cannot hurt it when it comes to having a ton of add-ons. Interestingly, several of Drupal's add-ons have spawned their own customization communities; the views module, which is not a core component of Drupal, has nearly fifty of its own add-ons.
Plone, however, is not hurting when it comes to add-ons; it has hundreds of released add-ons and even more in the community's subversion repositories. Furthermore, some particularly high value components of the CMS (e.g, workflows, WYSIYG editor) are in the core, meaning that they are maintained by some of Plone's most talented programmers and follow Plone's regular release and maintenance schedules. Furthermore, new modules are added and released regularly; the past few weeks saw new LDAP support, salesforce integration, and video-sharing add-ons.
In this area particularly, the sheer number of modules matters far less than your specific use case. If you need to use CiviCRM, that pretty much locks Drupal for you. In many cases though, the two systems have very similar functionality, and you will probably do well to research the add-ons that exist for both; both communities are actively extending their systems to meet both common and advanced needs.
Documentation and Community Support
This is a tossup. There are books for both Drupal and Plone, and although Drupal has slightly more current ones right now, there are Plone books in press that will fix that shortly. Both also have lots of documentation categorized on their sites, with Drupal's handbooks and Plone's Help Center. I do think that Drupal does a better job giving a beginner a clear path with its handbooks section; however, after one stops being a beginner, the incredibly high amount of noise on drupal.org can make it arduous to find information -- it's bad enough that the community has a name for repeated content on the site (druplicates). I know that, personally, because of the druplicates, I have had a hard time finding answers to pretty basic questions (e.g., how to enable draft support without modifying drupal's core). The druplicate phenomenon also attests to the sheer volume of information available at drupal.org, though, so, it's a tradeoff. Plone keeps its community support off of Plone.org, which generally means a search will turn up only relevant documentation, if any exists. Otherwise, you Google and hope for hits in mailing list archives. This is certainly not ideal, either. Both systems also have thoroughly documented APIs, at least, into their most current versions.
Summary
In the end, the two systems have philosophical difference that make them somewhat difficult to compare. However, we did come to a summary conclusion in our comparison, and I'll share it.
Drupal is a community content management system, and it largely farms out other tasks (e.g., asset management, CRM, etc.) to other web apps, choosing instead to integrate with them. This is a reasonable stance; Drupal is a CMS, and it integrates into a larger world of apache served web applications.
Plone, however, looks at a most web application problems as specific instances of content management. Thus, with Plone, is it not absurd to develop extensions to handle your asset management system, or your email newsletters (complete with server). Plone is built on a powerful application server, and it makes sense to leverage it and your data once you're used to programming for Plone.
For us, the learning curve for Plone seemed much steeper. Drupal is appealing because it has many, many add-ons that solve many, many small problems pretty well, allowing one to play integrator effectively instead of programmer. However, when we realized that we were going to have to do a lot of work to support our hierarchical IA and user permissions, we switched to Plone; Plone feels like it's designed for programmers, and once you get over the initial "oh my god, I thought archetypes were psychoanalysis, not code" feeling, it can be really wonderful how much you can get done quickly.
If you're starting a site from scratch, plan to power your IA with tagging, and want to have an open community of participants, Drupal will do the job well. If you have a planned site that needs to support a more traditional IA, you know you'll need a lot of custom work no matter what, you have complicated restrictions on what participants can and cannot do, Plone is a wonderful choice. Both systems will teach you a lot about content management. Feel comfortable in the knowledge that you can't go too wrong.
Reader Comments (26)
On site searching, plone's catalog system (which gets a lot of stick for its percieved slowness) gives internal search results which are awe inspiring - i cant ever remember a time when ive searched for something in a 5000+ document site and not found it in the first couple of pages. This is a Drupal weakness - I know many sitte admins prefer to use Google site search inside their sites rather than the standard Drupal search.
However, when it comes to theming, the shoe is on the other foot. Drupal themes are very easy to put together, use one style.css file and are well separated from the bones of the system. On the other hand, Plone skin designers have to sift through over 15 css layers - if you see '!important' outnumbering every other word in a css file on a 2 to 1 ratio, chances are its a Plone skin :). There was some talk of improving the theming situation - lets see where it ends up....
As for theming, I couldn't agree more. I know they're sprinting on that very subject next week, and I'm planning to try to contribute plonetheme.minimal, which would be a set of unstyled templates that '''do not have tables,''' for designers to style with CSS. But, anything that's that vapor-ific is a point to Drupal :)
I'm not a techie, but Plone is really slooooooooooowwww. hahaa
Facebook and MediaWiki (which wikipedia uses) use PHP. Enough said.
The problem appears now much more clear to me, but I have a question for you:+ I work for an attorney community who would like to have a website where they can easily share experiences (a forum), list rules and directives (consulted by keywords, publication date, thematic areas, ...). You can suppose they have a very limited knowledge on web and computer systems. You see that the website is not very complicated a part from the fact they will probably publish a lot of documents (several hundreds). They would like to be very autonomous once the system has been developed: make their own content modifications (text modification, introduction of links, images, new files and documents, ...). What do you recommend in such a case specifically?
Thanks in advance for your time and efforts.
I found it more realistic to bolt a couple of WordPress blogs onto my site, rather than continue my own development.I've spent the last 24 hours sketching out the future. I looked at multi-user WordPress systems to learn from their schema, and re-discovered Plone and Drupal.
Your article seems well thought out, and informative. Just what I needed. Thanks again.
Regards
Plone has left me a bad taste in my mouth. After dealing with it for months for a community project (not a small one, by the way), I finally delivered a half-baked product to the client committee and a great sense of UNsatisfaction. I suggested the committee to allow me to try another solution. In this case, it was Joomla, but I'm pretty sure any other one would have thrown about the same results: I've managed to setup all the features that the project required in one week (one week!!!) compared to the months that it took me with Plone.
Stay away from Plone unless you have a lot of time in your hands and you naturally have a tendency toward the unnecessarily complex.
I got here from this plone v drupal comparison, http://versuswiki.com/w/index.php/Plone_vs_Drupal, you should have written that one! This article so thorough, thanks!
I did some pretty extensive research and comparison a while back for a large scale project I was working on. I made a proposal to use Plone based on the requirements, though that was scuttled by some Drupal-istas.
I agree with pretty much everything you've said - I liked both Drupal and Plone, but Plone just felt more sturdy for the scale of the site we've planned, and the ACL would have solved most of the "own your own content" mindset our clients have right out of the box.
Just wanted to say good work. This article is as balanced as any "vs" article I've ever seen.
Great article! I am learning Drupal right now after a year and over 200+ hours of Joomla. I LOVE Drupal right now. Seems like Plone may have even a steeper learning curve. Your article makes me feel good about my decision to learn Drupal. Drupal crushes Joomla and i will NEVER use Joomla again! I am on the Drupal cloud right now!
Any chance of an update to the article now that Plone is on v3.x and Drupal is on 6.x? Great work, looking forward to an update if you have the time!
@Josh -- I've been thinking about that very thing for a little while now, but it's always tricky to find the time. I do hope to get to do it though.
Great comparison!
My no profit organization has to make this decision in about a month ore two, and this article helped me to clarify my mind...
Any chance of an update? ;-)
Thank you!
@Vittorio -- I've been meaning to update for a long time, but there just isn't time lately. One day though, one day.
Simply outstanding post and although it's a few years old, a lot of the content still holds true.
I'm a drupee but just started researching on Plone.
Thanks for the detailed write up
I hope Plone finds a way to impliment something similar. I would also love to see something similar to Limi's evaluation for Drupal. If you know of one, please leave a comment and I'll gladly link it here.
At first, i have to say that I am a developer with about 8 years.
Even that, I cannot catch what plone trying to say ,which actually is based on zope, which has copied many ideas from Java,but in a very bad way.
I believe Plone is going to death in a slow steps.
Following are the points I concluded after I've tried it 9 months.
1)Zope,which is the basement of plone, is actually a very old programming model and very hard to understand and use,and also impossible to achieve your own cusomization.For example,Adapter, which is obviously copied from Java, is very ugly in Zope.I cannot believe that the Adatper pattern can be used in such a way that only to lookup some classes.I cannot either believe that the you can declare an interface,but you are just use it to mark something.I don't know what I should say upon these applications of Java idea.Zope has just grap ideas from Java and use them to do the thing that can be done in a more simple and easy to understood way.
2)ZPT, I either dont't how to say, is very very ugly. It's purpse is good.It don't want to destroy the structure of html.But unfortunately,it's overdesign.If you read zpt,you'll found structure of zpt is very head to recogonize because the mixing of the html property and zope property. I cannt bear that I have to use thousandas of prefix "TAL" or "METAL" to be attached on my html page.
3)Because of the ugly programming model of zope,Plone is very very hard the tidious to customization.I suggest you'd better not to read its documentation on how to theming.I have read them from begging to end(Oh,I am so patient).After finish reading, I said to myself, Oh,what a mess! Looking at these concepts:Viewlet,Portlet,Layer,ZCML,Page,View,Context.Adapter,Factory.Acturally,creating pages in Java is very simple,but these concepts making changes in Plone is very very ugly.
4)If you have some specical requirements, It's almost impossible to achieve it using plone.For example, if you want to build an ecommerce functionality. There is only one plugin "GetPaid".I just the same one word on it,"ugly".
Because the points above, I strongly suggest you not to touch it.Better stay away from it.
Hi, for me Drupal seems to be the effective and more flexible content management system comparing with Plone .There are lot of modules available for Drupal to enhance the functionality and flexibility of Drupal CMS. So try Drupal.......
--Drupal Web Developer