eZ Community » Blogs » Joe Kepley » CMS Bake-offs - Contrasting eZ...


CMS Bake-offs - Contrasting eZ Publish and Drupal

Wednesday 25 June 2014 2:26:50 pm

  • Currently 5 out of 5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

A few years ago we ran a bake-off project, contrasting eZ Publish and Drupal for the same task. Are you starting a big project where the CMS will be a major factor? Consider doing some research first to look outside your normal set of tools and understand how you might implement the same solution in multiple systems.

I’ve spent some time with an inherited Drupal site recently, and every time I work with it I’m blown away by the fact that, given the haphazard nature of it’s construction, it’s one of the more popular content management systems on the web. There’s a longer post about that in me somewhere, but it reminded me of a research project we conducted a couple of years ago, but never published.

A client of ours with a large, static web site was looking to move their site into a CMS, and they took a step that few clients take: rather than getting sales pitches from multiple vendors, they initiated a research project. They asked us to spend 40 hours each with two different projects, actually migrate some of their key pages, and compare and contrast the two systems. Given the client’s site - a large, hierarchical repository of static content, our choice for a CMS was eZ Publish. The client asked us to compare it with Drupal, mostly since it’s popular and they had heard of it.

This was a great opportunity; how often do you get to build the same thing, twice, in two systems, and compare the results? And what could we take away from that as a learning experience? Here’s a quick breakdown of what we learned.

Obligatory grain of salt: While Blend has been building content management solutions for years, we’re far more familiar with eZ than we are with Drupal. Nevertheless, we took pains to follow best practices with both platforms and tried to minimize our own bias.

Content Management

eZ and Drupal represent two general schools of thought in the content management space: the Tree and the Pile.

  • In “Tree” systems, every piece of content has a position in a hierarchy of content. This is an enforced primary taxonomy. When you look at your sitemap or nav, you’re usually looking at exactly how the content is arranged in the administrative interface as well. You can create secondary taxonomies and navigation through tags, keywords, or manually building navigation lists. eZ Publish takes the “Tree” approach - everything in the system has a primary location, and most navigation derives naturally from that.
  • In “Pile” systems, every piece of content is a basically a row in a table. All content falls into a big list. It’s up to the site editors to create structure using manual selection on navigation or through other approaches. There’s not an enforced primary taxonomy. This is the way Drupal works. You can declare a page as a parent, but it’s optional, and left to it’s own devices everything lives at the same level.

From a content strategy perspective, I far prefer the “Tree” approach. It forces the site to take on at least a basic level of organization. Users tend to think of content as a hierarchy (thanks to years of book sections and chapters, outlines, and etc), so this makes the content follow a logical model. I’ve seen far too many projects built on “Pile” systems where you’re pulling your hair out because the navigation structure has been built without a plan and winds up as some arbitrary mishmash with navigation changing on every page.

Another major difference is how content is stored. Drupal (and almost every other CMS) stores formatted text as HTML - for a Web CMS this is the default approach. eZ is different in that it stores text as XML - when an editor enters formatted text, it’s HTML on the client side for compatibility with the online WYSIWYG editor, but it’s converted to an XML format as it’s saved.

There are positives and negatives to both approaches. The XML format means that eZ Publish has total control over how content is rendered and what’s allowed. Want to convert all of your ‘b’ tags to ‘strong’ tags? Want all of your H1 tags to include a new class declaration? No problem, you can just change the template, since even content within the WYSIWYG interface is templated. You can also include custom tags and embedding - editors can be given a custom tag to easily add Youtube videos, or embed a special widget in the article that displays a constantly-updating list of the latest 3 posts from the blog. The XML approach is very powerful.

The only downside appears when migrating old content into eZ Publish. Since eZ controls the content vs presentation boundary better than other CM platforms, it means that it’s not going to let you get away with some of the haphazard, broken HTML that’s probably in your old system. While the end result is a better, cleaner markup, the transition process can be more manual - Drupal and other HTML-based systems are usually happy to take whatever lousy HTML you throw at them. eZ’s a bit more picky, and this means a better experience in the long run, but potentially more work up front if your content is already messy.


I’ll go ahead and start the flame war up front: to a general PHP developer, Drupal’s code organization is atrocious. It largely eschews the normal object-oriented, class-based approached to development. Drupal developers will defend this approach, largely for historical reasons, and point you to other ways that Drupal organizes code into an object-ish arrangement. This winds up sounding like someone saying that they don’t trust engines and gas is expensive, so they cut a hole in the floorboard and move their car along Flintstones-style.

Sure, there have historically been challenges with taking an object-oriented approach to PHP, but ignoring a key feature of the language feels like tossing the baby with the bathwater. Drupal developers won’t be able to take the code practices that they use on Drupal to other projects, and developers new to the Drupal community will have to learn everything from scratch. Drupal 8 should improve this situation somewhat, but it’ll probably still be dragging along a lot of historical baggage.

eZ Publish went the opposite direction by completely embracing the OOP approach (the fact that both systems were developed around the same time disproves a lot of Drupal’s historical basis for not using classes). This provides a well-organized approach that, while complex, is at least understandable to most developers.


Beyond the code level, eZ Publish and Drupal share a somewhat similar structure - the software has a fairly small modular execution framework, with standard modules encapsulating the code and handling the execution. The Drupal Project and eZ Systems both provide a set of standard modules that extend the framework with the features needed to implement a CMS. This approach works well. Any good CMS is really just a collection of tools for delivering content, so having a good way of delivering those tools and adding new ones is key.

The difference arises in who provides the tools. Many of the components that are considered core functionality are delivered as addon extensions in Drupal. As of Drupal 6, things like WYSIWYG editing were still provided in addon modules. This has changed somewhat in Drupal 7, but it’s rare to build a Drupal site without using community-maintained modules. By contrast, eZ ships with most of the common tools delivered in the core product. It’s normal for an eZ site to be developed with only the modules provided in the initial download.

Where this comes into play is during upgrades. If you’re using third party extensions on either system, you can’t upgrade the core until all of your extensions support the new version. So it’s important to pick your third-party extensions carefully. If they’re abandoned by the original developer, the maintenance of them will become your responsibility.

eZ Publish and Drupal are both currently in the process of major architectural revisions, and both are incorporating the Symfony project, albeit in different ways. Having started before the current prevalence of MVC frameworks, most content management platforms have developed their own ways over time to manage code, and their own libraries for doing low-level things like database access. Symfony has gone a long way in the past few years towards providing a de-facto web architecture for PHP, in the same way that Rails has done for Ruby. This shift will allow both platforms to re-use the code of other projects for low-level components and focus development efforts on tasks unique to content management.

eZ Publish version 5 is essentially a ground-up rewrite of the platform as a full Symfony application. Given the amount of code eZ ships in the project’s core, this is a massive undertaking. They’ve addressed both the coding effort and the upgrade challenge by taking a ‘dual core’ approach: eZ 5 ships as a Symfony wrapped around the existing legacy core. Each release moves more code into the Symfony stack, but still provides the legacy implementation to maintain compatibility. It’s an elegant solution, but it does often require knowledge of both stacks through the transition.

Drupal is taking the alternate approach of keeping their own framework core, but integrating libraries from the Symfony project. More code will be shared, but Drupal 8 will still be its own animal, as opposed to being a Symfony application. The project is still under development (with alpha releases available as of Q1 2014), so it remains to be seen what the transition will look like for existing Drupal developers and sites.

Security and Performance

From a performance perspective, both platforms make heavy use of caching, and both perform acceptably for complex requirements if you make use of the correct features of the framework to cache content and correctly clear those caches at the right times. Similarly, both can perform poorly if configured haphazardly or improperly.

On the security front, Drupal has a far more spotty track record, owing in part to the fact that most modules are provided by third parties and the lack of encapsulated code exposes more of the system. eZ’s codebase has proven more secure, and has passed the US Department of Defense’s DITSCAP security certification process.

Business concerns: Licensing, Ecosystem, and Support

eZ Publish has a big advantage in that while it’s available under an open-source license, the codebase itself is managed like an enterprise product. This means a lot of roadmap planning, quality control, and code policy enforcement that’s not always possible in a completely open project.

eZ Publish is also available under a fully supported Enterprise license that can be treated as a closed-source option where needed. This is possible because all contributors to the eZ Publish core have assigned copyright for their code directly to eZ Systems, meaning that the organization has the flexibility to relicense the eZ platform as closed-source in situations where it’s advantageous. Since all contributors to Drupal retain their original copyright and agree to license it only under the GPL, this flexibility isn’t available.


In the end, for our particular project, we wound up using eZ Publish. This sort of comparative analysis is extremely valuable, and I try to make an effort to occasionally find reasons to use systems that I usually don’t in order to gain experience with them and get some exposure to other ways of doing things. While I don’t think we would select Drupal for a project given our other options, some of the things it does well, like Block and Zone management, were ideas that we could port over into the systems we already use.

Run your own ‘Bake-off’

My advice would be that the next time you start a big project, instead of doing things the way you’ve always done them, take a step back and consider comparing your normal solution to another option. Ask yourself these questions:

  • What features provided by a CMS are the most important for this project? What’s the emphasis and level of sophistication at which each of your available solutions implements these features?
  • What will the editor experience be in doing day-to-day work in each of the solutions you’re considering?
  • What are some of the non-technical factors (licensing, legal, etc) that will come to play in the life of this solution?
  • Remove yourself and your firm from the picture. Can the system be maintained by another integrator, or by your client directly? You should build a solution for the long term. (Stepping out of the equation doesn’t mean being fired - you may want to initiate a hand-off to some other firm in the future for reasons that you can’t see now, or you may move on to another project)

In short, figure out what your most important factors on the project are, and see if there’s an alternate system out there that has a stronger feature set to meet those factors. Then, if possible, run through all of the key features of each system and compare, or even better, get in there and play around a bit. On a large project, this isn’t wasted time, it’s planning, and avoiding the old blindness of “I have a hammer, so everything is a nail”, that can crop up if you’ve done things the same way for too long. Even if you don’t go in a new direction, you’ll have more insight into the alternatives and will pick up a few new ideas along the way.

Proudly Developed with from