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

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.

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.