9 reasons to consider eZ Publish CMS for your next web project

Ivo Lukac
Tweet

Introduction

With the recent refactoring of eZ Publish content management system as a full stack Symfony application it should be interesting for a broader PHP public to consider it as a content management solution. We at Netgen have been using it for almost a decade and would like to share our reasons why it is a good choice in certain cases.

Before going deeper into the reasons why someone should consider eZ as a CMS solution, lets note a few disclaimers and audience filters:

  • if the development team is really small or the project is just a simple web site then there is no good incentive to consider eZ. There are lots of other solutions that are easier to learn.

  • if your web project doesn’t need content management or that part of the project is very simple, there is no good incentive to consider eZ either.

This post is about reasons why you should consider eZ, it’s not about praising it is an ultimate solution. It has its share of problems, like the following ones:

  • Currently eZ is shipped as dual stack (version 5.* with new and legacy code) and this could be an obstacle to less experienced teams. Recently I discussed on our blog about the hybrid approach we are currently taking and in short: it’s not simple. But its a temporary situation which causes some bad side effects like confusing dual documentation, etc. Installation could also be troublesome like Sitepoint’s editor Bruno discovered recently. But by the end of the year eZ should release a developer preview version with the new stack only. Next year the first stable version could hit the streets (named : eZ Publish 6 or eZ Platform).

  • Historically, it always had a steep learning curve. This might be the number one reason why eZ didn’t get more traction over the years. With the new stack implemented as a Symfony application this could change. Putting aside the transition situation, where some features are not yet implemented on the new stack (hence falling back to legacy), the new stack should be easier to learn as the development practices are more common (especially to Symfony developers) and less specific only to eZ.

  • The Community is not very big. Some prefer 10000 active developers behind a product, but this is not the case here. Actually, the community is quite active for its size and it consists of people from companies and larger teams that use eZ. And given the fact that Symfony is now the underlying PHP framework, the community could get larger very soon.

If you are not completely repelled by the problems, lets focus on the good side: reasons why I think PHP developers should consider eZ Publish’s new stack for their next content oriented web project.

1. It’s open source

Yes, it certainly sounds obvious for the readers of this portal, but its still worth emphasizing. There is still a lot of content managed with either agency or in-house developed software, more or less closed source. As a professional who builds solutions on top of CMSs I strongly think an open-source baseline is the way to go. The reasons are many: from practical ones like solving bugs directly without the need to wait for the vendor to solve it, to faster innovation boosted by the community.

eZ Publish was open-sourced before 2000. It did not conquer the world in these 15 years but it certainly left a strong footprint. It is now being refactored completely for the second time. It uses other state of the art open-source solutions like Symfony, and it contributes back, too. You might think that open-source is only important for developers, but its very important for business decisions as well. We decided not to build our own CMS 10 years ago and chose an open-source one. One of our important selling points is that the client will not be vendor locked if he uses an open-source product backed by an active community. Clients are becoming aware of this more and more, some only after really bad experiences with closed source solutions.

2. It’s enterprise

Although this might sound as a business topic, it is also in a way connected to development. The enterprise tag means that a client is able to get reliable support from a vendor. It also means that the roadmap should be more “committed”. It doesn’t mean it will be executed exactly as it is laid out, but with an enterprise tag you should expect the project to be backed by a company which can better budget and plan future releases. With the enterprise tag you would also expect a clear upgrade path provided by the vendor for every new version. Those traits are usually interesting for more complex projects, for clients that would rather pay the fee upfront to better control the risk and to better plan ahead. It’s basically a risk management decision whether to go enterprise or not.

eZ systems, the company behind eZ Publish, were following the more obvious open-source business model at first: work on projects and have the core open-sourced. Five years ago they started to shift and today their model is different. They work on the core and sell subscriptions for the enterprise edition (there is also a free to use community edition under GPLv2). They don’t work on projects any more, all implementations of enterprise instances are done by the partner network or in-house by the client. It might seem like a simple thing but not so many vendors are using such a model successfully. The idea is to maintain the open-source spirit and focus on a higher level market with the enterprise edition, but it’s hard to find a good balance. From a developer’s perspective, enterprise open-source offers liberty in combination with security.

3. Has a great architecture

10 years ago we started with the version of eZ which was based on what’s now called the legacy stack. Although the learning curve was steep at the beginning, when we got the big picture, it was like a pick-up truck – you could really do a lot of stuff with it. It was really good PHP software, but a bit ahead of its time. Things like the meta content model, separation of content and presentation and 25+ kernel extension points were excellent features but maybe not very needed 10 years ago. Back then, other CMSs just stored HTML files and got away with it. Today, when content needs to be very flexible and adaptable to different channels, those features are necessary. Even more stuff is needed, like APIs, REST, scalability for big data, etc.

eZ Systems recognized this several years back and decided to refactor the CMS from scratch while maintaining all the good things: the meta content model, separation of content and presentation, extensibility, etc. This is still a process as the stable and standalone new stack of eZ is expected next year. The new stack is architectured with the following things in mind:

  • maintain the easy extendable content model for channel agnostic content

  • provide APIs on several levels for easier development, integration, extensibility and upgrading

  • “do not reinvent the wheel”, use existing best-of-breed tools

  • focus on content management

  • use newer PHP (5.3+) features to simplify the code (like closures, etc)

  • make the storage type replaceable to the point that different storage engines could be used

  • be fully backwards compatible while having both stacks (new and legacy) in the distribution to ease the transition period for existing projects

Check the eZ Publish 5 hybrid architecture diagram (provided by eZ Systems) for better understanding of the current situation.
eZ Publish 5 Hybrid Architectue

4. Has a future-proof content model

The current content model was introduced in 2003. As I already mentioned, it was ahead of its time but today we can really use its full potential. Today, content needs to be broken up into smaller pieces to manage it easily, and to easily integrate and distribute it over more channels. With eZ, changing the default content type set or extending it to fit your needs is a breeze. Usually, it’s a matter of a few clicks in the admin interface, and this operation will not change the database model which will ensure a straightforward upgrade procedure.

5. Separates content from presentation

Again, this was introduced 11 years ago. Rich content is not stored in the repository as HTML. It is stored as a simplified XML version. It has some standard HTML tags like <b> or <h1> but also some custom ones like <embed> for inserting other eZ content. On one hand, it sounds like a limiting option, but is excellent if you have more distribution channels, not just the web. It’s also resilient to HTML standard changes etc. Presentation was implemented via the eZ templating engine (which looked very similar to Smarty), but with the new version, it’s rendered via Twig (Symfony templating engine) or directly from controllers as JSON or XML. E.g. implementing dumping of rich content in Markdown should be really straightforward.

6. Has several APIs

When developing some feature or extension on top of the eZ legacy stack you would usually use 25+ extension points and/or call some mid level functions from the kernel. If no other option was available you could also read/write directly to the db or even hack the kernel. With the new stack this practice changed a lot.

  • First of all there is a well defined public API for managing content. So if you need to get a piece of content there is only one way to do it. Check some examples in this detailed post on our blog if you want to learn more about this.

  • There is a REST API which directly maps the Public API. This one comes hand to hand with the REST client in PHP and Javascript. So integrating across repositories and building rich client web applications should be possible. eZ Systems is currently building its new editorial interface on top of this.

  • Last but not least, there is a persistence API. The storage layer is in the new kernel implemented with the generic part and the legacy SQL specific part is separated. They communicate via the persistence API. This was done like that to have the possibility of using a different storage engine like, for example, MongoDB. Previously, there was no chance for this as SQL code was scattered on many code levels. There is still no NOSQL storage engine developed (there are some more important features to implement at this moment), but the base is set.

7. It’s Symfony

If the legacy eZ could be called an obscure and too specific piece of code, then the new stack is the opposite. The “don’t reinvent the wheel” approach really kicked some butt in the case of building the new eZ. They didn’t just use a few components, they went the full Symfony stack approach. This means that all Symfony components are there or just a “php composer update” away, and this gives a myriad of options to developers. Even more, it brings us to the situation were present Symfony developers could learn the new eZ faster than the eZ legacy developers.

8. It’s highly extensible

I already mentioned that the legacy kernel had 25+ extension points. There are some documented extension points also in the new stack. For example, if you need a custom field type, there is a cookbook on how to make your own.

But this is just the tip of the iceberg. The whole new kernel is built using the Symfony service container and implemented as numerous services. This enables enormous extensibility. If, for some reason, the usual extension points are not enough, you can inherit a class from the kernel, add your code, call the parent where needed and configure the service so the system uses your class. This was not possible in the legacy code and as far as I know not many other CMS products give this kind of flexibility.

9. Known for its upgradeability

A decade ago when we were starting our web development business, sites were usually redesigned and reimplemented once every few years. For bigger sites, that meant pain when switching to new code, new CMS, new hosting, etc. In a few years the old site would end up in a stage where there was no option to advance it. Hacking and extending the CMS made it impossible to upgrade.

Today, the web life is much faster. Feature changes on the site are needed almost every day. This means that web development agencies need to be agile and always moving forward. This is possible if they have a solid core that can be upgraded without breaking extensions and integrations, and is where eZ is really strong. We at Netgen have installations that were built in 2005, were upgraded several times over the years and are currently running a version from the beginning of 2014. The upgrades are sometimes not completely simple, there are some bigger gaps between versions, but it’s usually just a matter of executing a few PHP and SQL scripts. Upgrading from legacy to the new stack (once there will be no legacy code bundled) will probably be hard as the whole architecture changes but possible, I have no doubt about that.

Conclusion

If you are searching for an enterprise open-source content management system built around the best-of-its-breed PHP framework, highly extensible, upgradeable and easy to integrate – search no more. eZ is the choice for you. Start getting into it and by the time you figure it out, there will be a version with no legacy luggage :)

In case you are not yet convinced check a recent comparison between eZ Publish and Drupal by a fellow eZ community member Joe Kepley. Should be a very interesting read for Drupal developers :)

In case you are eager to learn more you still have a chance to register for the PHP Summer Camp / eZ Publish Summer Camp. It’s a double event that we are organizing at the beginning of September in Croatia.

Or just try it out. The latest community edition can be found here and installation information here.

Feel free to share your feedback in the comments.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • Alex

    Drupal comparison:

    1. Pile VS Tree analogy is good I agree with it. However I disagree with the author…structure should not be implied so I prefer “pile”. If you look at any large corporate site with a million pages…the actual unique page layouts are usually only a dozen or so. Pages in drupal are composed of blocks and content types. A page call “classifieds” will use a single uniform design and simply paginate the “classified” type in that layout — for consistency this is way preferred in my opinion.

    This argument about structure VS flat is typical of anyone who sees a CMS as only a article management system…Drupal is a CMF…not all content models well in a rigid hierarchical fashion. For instance, I am building a issue/ticketing system where an implied URI structure would not be of any benefit and infact get in the way.

    I would rather start flat and build in hierarchial flow, then have hierarchy forced upon me and hack core to get it to act flat.

    2. Content is Drupal is stored as plain text…not HTML…I often use the Markdown module to eliminate any HTML f**k ups…content is stored as simple Markdown and later rendered as HTML or whatever format I wish. I could just as easily store content as XML and have it rendered to HTML or JSON if I wanted. Drupal is flexible that way.

    3. Drupal’s code organization is atrocious…sure I guess so…but so is PHP…and most every open source project…code starts with something simple and grows over time. eZ code…Joomla code…WordPress (really bad)…Typo3…all theses software systems have horrible code…until you learn the hows and whys…

    You can organize code well using assembly…object oriented programming does not intrinsically make code better. In fact GOD objects, MI, and pretty much anything anti-SOLID are common in every OO codebase I have ever seen or worked in in some 20+ years — this argument is so moot…like claiming your $H1t don’t stink is supposed to convince me your software systems are better.

    4. eZ ships with all common modules…Drupal core comes with a minimal and standard install profile. There are dozens of other install profiles which can bring you up to speed instantly for a given niche. CRM? Check…LIMS? Check…ERP? Check…I think there was even a project optimized for high traffic until D7 was released…

    Upgrading uncommon modules is a pain…would be in any system where they are maintained by someone other than dedicated developers. most sites use only a handful of modules which are well supported and actively maintained…the 1000’s of others are one off crap shoots some beginner uploads for fame or notoriety. All open source extensible system has this problem.

    5. Security and performance…I need more tangible evidence than that…a SQL injection is probably worse than session fixation…but it depends on context and what your does. SSL isn’t always needed. Comparing these two qualities is like saying a mini-van is better than a 4×4 — except in winter or when off roading…or moving lumber or working in rough terrain…towing a trailer…and on and on and on…

    6. Drupal is supported indirectly through Acquia…but it is truly open source. I believe they have a core developer or two on their team…other agencies do as well I think. As for code quality…again…show me the numbers…opinions are like a$$holes…everyone has one. Who has the most unit tests? Integration tests? Highest SLOC or lower cyclomatic complexity values. Which has more extension points VS overall performance…API count VS documented API’s…it’s one thing to try and clinically define “better” using a variety of metrics and actual numbers others can test and verify…but to make the claim “better quality assurance” sounds like a marketing buzz term to me.

    Regards,
    Alex

    • Ivo Lukač

      Hi Alex, thanks for your feedback , but would make more sense if you replied to Joe’s original article :)

  • Ivo Lukač

    Ok, I will need to ping Joe to comment on this :)

    And yes, this is a biased article, (although I really tried to be objective as much as possible), it wouldn’t make sense to say otherwise, but reasons are simple:
    – there is not so many information about eZ in the wild and
    – given the interesting situation eZ is in at the moment, it should be very interesting for other PHP developers (especially who know Symfony already) to learn about eZ, at least on a higher level.

    If time permits I would like to dig deeper and make a tutorial of some kind, which should have more practical use.

    +1 for the CMS data model comparison. Feel free to contact me if you need to know more about eZ’s.

  • Ivo Lukač

    Hi Alex,

    As Carlos already said, eZ has a content model which doesn’t generate additional entity tables or entity classes for custom field types. In some cases its needed and can be done, but in most its not. Hence creating and maintaing a custom content type is simple. This type of content model I like to call: meta content model.
    There are some performance drawbacks when you reach tens of millions of content objects (which should be tackled with the new version) but otherwise I see only pros for this kind of architecture.

    • crevillo

      In some aspects, is the same approach as Magento. Not entirely but in some aspects could be compared. In Magento you can add more fields without the needs of new tables.
      As Ivo said, there are some perfomance problems when trying to do queries that may involve several attributes, but fortunately eZ Systems provides eZ Find extension, (a bridge between eZ Find Content Model and Solr) that helps a lot with that.

      Going back to your first reply, yes, eZ Publish is thought as a CMS. A CMS that can be extended with whatever you may need but yes, mainly a CMS. But my point is this CMS offers you, and in its core, functionalities that i would expect of a CMS. Thinking here in multilanguage, workflow for publications, easiness in finding desired content to edit, versioning system, possiblities to manage who can read this or that, landing pages management, and finally (even probably i forgot more) an API that could help the developer in terms of performance, letting the dev choose which content can be cached and which one not, when those caches should expire… whatever

      Again, yes. ALL that could be with Drupal Modules, but not with Drupal Core alone. And i simply prefer eZ approach in this.

      .

      • Alex

        I prefer the minimal core of Drupal and work up…it has almost always meant less work as opposed to a system that requires you to work down (ie: uninstalling core modules which are not required for specific project). Drupal install profiles let developers build cookie cutter type sites quickly — for instance if I found I was building a lot of classified sites…I could prepackage the core along with required modules, types, roles, etc and get it all running instantly. Interesting convo.

        Drupal and Magento use the EAV data model I believe sounds like eZ uses something similar…it’s fascinating data model

        • crevillo

          well, everything opinable. but take in account what you said: “Drupal install profiles let **developers” build…”. Ok. that’s cool. But take in account eZ is though to be sold to customer as a nearly final solution. None of our customers having an enterprise license wouldn’t go for it if eZ offered, by default, same as Drupal.
          Briefly, conversations between then and us could be something like:
          – Has eZ multilingual possiblities? – Yes
          – Can i host several domains and subdomains from an only admin? – Yes
          – Workflows? – Yes
          – Restrict acces per sections, domains, languages? – Yes, yes, yes

          And what about Drupal
          – Has Drupal multilingual possibilites? – With the help of a bunch of modules
          – Can i hos several domains? Well, you need domain module for that
          – Workflows? – Rules, maybe
          – Restrict acces per sections, domains, languages? – Err… let me check if there is something in the drupal.org site.

          Totally different approach indeed. About perfomance, we normally didn’t disable any module from a ez install and don’t have any perfomance problem with that, because again, eZ and Drupal behaves differently here. Is not thought as a hook system. Perfomance is not affected by the number of extensions you may have enabled or not. it there are modules that aren’t used, well, that modules stays there doing nothing.
          And as it happens with database, you normally wouldn’t add more than 5 extensions to your ez install. this means number of files to be checked for something wouldn’t grow that much. thats not the case with drupal.