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.

Plone

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.

Drupal

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 drupal.org 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.

Conclusion?

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 🙂