In summary eZ Publish 5.0 introduces a new technology stack referred to as "Platform" (earlier sometimes referred to as "new stack", "6.x stack" or "Symfony stack") next to the existing eZ Publish 4.x technology, herby referred to as Legacy. Platform Stack will throughout the 5.x series mature for each release until it becomes ready to be next evolution of eZ Publish.
This approach allows for very high degree of forward and backwards compatibility, its accomplished thanks to a Legacy Bundle acting as a "bridge" between the two, passing on platform/symfony requests to legacy whenever needed and injecting sessions, configuration, user and integrating cache across the two systems.
This document will explain why we are renewing our technology platform, and to some degree explain what this evolution in architecture means to eZ Publish developers and users, and last but not least how eZ Systems is affected by these changes.
Why this change in technology
The background for the changes is to meet the challenges ahead:
The overall goal is to reach Digital Service Excellence, ie, we would like our partners to be able to offer the customers exactly what they want, within acceptable timeframes and price tags on the eZ Publish Platform.
What are the changes?
eZ Systems is now introducing the following as the new "Platform":
Introducing a backward compatibility between the new "Platform" architecture resulting from the above and the "legacy" architecture as known in eZ Publish 4.x
What will be gained?
With Symfony as the web framework eZ Publish will be more accessible. Thanks to the framework, it will be used for instance to extend eZ Publish applications with new features, potentially not based at all on the content repository (for example, business specific application logic) using a standard PHP framework and a very clean application design with minimum interlocking with eZ Publish itself.
a better quality of the code
a lower entry point to do developments in eZ Publish
more innovation faster since more developers will use a standard PHP framework
Symfony has an open-source community that will help developers
Symfony is commercially backed up, so they are in it for the long run and Sensio Lab (maker of Symfony) will naturally extend the eZ offering to the framework level if need be.
Initially, eZ Systems has developed its own templating engine. eZ has also worked and redeveloped a second one at some point as part of the eZ Component project. When designing eZ Publish 5, we knew the old template engine was not good enough anymore and needed to be replaced. We knew the eZ Components template engine we contributed and originated was an option, but we decided to go for another one: Twig. Reasons are multiple: quality of course (even if the eZ components one was also very high quality), integration and cohesion to use it with the Symfony stack and finally again the strength and size of the community using it today. Symfony has developed Twig as a standard template engine, and eZ Systems is using it to further the following:
This is a move that will influence every stakeholder in the eZ Publish development. As developers will implement faster, this also mean project will significantly improve in total cost of ownership as well as in time to market.
New storage systems
In order to meet performance and scalability requirements in the future, eZ introduces new storage systems with the version 5 serie.
The ultimate goal is to open for custom storage developments.
In order to meet all multi-channel requirements we are developing a Rest API that cover all core feature of content management so we can integrate with any application on any channel in any programming language.
The gain for users will be for anyone integrating eZ Publish with other applications, not only the development will be significantly improved but more importantly, the value of an API also lies in the maintainability and sustainability it offers. the new rest api is designed to stay and will remain identical in all future 5.x version. this means that development done on top of the api will seamlessly support eZ Publish version upgrades.
The PHP API, also called Public API, is the development glue and will a create shield between internal and external developments on eZ Publish. This will cater for an easier maintainability of code and speed up the performance of eZ Publish. PHP developers will experience a better extensibility which in turn will enable them to create extensions to eZ Publish faster and easier.
The Public API is key to development speed, shorter projects and better quality. Important to be noted: the php api is the foundation for the rest api and the second is naturally relying on the first.
Compatibility with the legacy architecture
When we introduce changes of this magnitude, eZ Systems as an international software house must also consider the reality of the installed customer base. Every installation must be able to take care of the old and create on the new architecture.
The reason for change is of course to be able to meet new requirements and the need to enable progressive changes.
Understanding the architecture in more detail
The target architecture: "eZ Platform"
The first important thing to understand about the new architecture is to explain it standalone, without considering the old legacy architecture.
|Simplified view||Detailed view|
The new architecture is layered and uses clearly defined API’s between the layers.
A motto for this new architecture is to heavily use APIs that will be maintained on the long term to ease upgrades and provide lossless couplings between each part of the architecture, improving the migration capabilities of the system at the same time.
The "real" version 5.x architecture: "Legacy" and "Platform" together
The chapter above is only explaining the new architecture but, as mentioned, version 5 also offers a way to run the legacy eZ Publish stack, in order to simplify upgrade and switch to version 5. This result in the end in a more sophisticated architecture that is illustrated in the diagram below.
The main difference is, the cohabitation between the new architecture explained in the previous chapter (on the right) and the previous architecture (on the left).
These two ways to implement a compatibility between the past architecture and the new one offers a wide range of possibilities and a smooth transition path.
Summary on the ways to use eZ Publish 5
Using eZ Publish 5 in
This way is the less disruptive coming from 4.x. In this way, eZ Publish 5.0 totally behave as if it was an eZ Publish 4.7, or we should say 4.8. This is ideal for users who have large existing applications with large amount of data and who are not willing to invest in learning and migrating them immediately.
In this way, even the siteaccess and vhost configuration bypass the your vhost is setup to go directly to legacy stack, and developers will see almost no differences.
Using ez publish 5.0 through the legacy stack but relying on the new controller and new template system as well as the new kernel.
In this setup you can not use any of the new Symfony or Platform features, and legacy "bridge" will not be used used for integrating the two system together.
If you choose this because of performance concerns, see our recommendations in Legacy code and features on how to alternatively handle those.
Anchor Usingezpublish5.0throughthelegacystackbutrelyingonthenewcontrollerandnewtemplatesystemaswellasthenewkernel. Usingezpublish5.0throughthelegacystackbutrelyingonthenewcontrollerandnewtemplatesystemaswellasthenewkernel.
Using eZ Publish 5 with both legacy & platform stack to start to take advantage
This way offers a transition and allows to combine old template and new templates in the same application. In this case, the users will rely on the administration interface of eZ Publish as well as on the ez tool bar for front-end editing, through the legacy templates, but the front end will be either based on legacy or new twig based templates.
In this model, the two kernels can be used and the system can this way benefit from the Public API and the new REST API built on top.
This setup can be configured in "legacy mode" per siteaccess, if enabled legacy handles dynamic url alias lookups and page layout handling, it's what is used out of the box where admin is configured in this mode and demo frontend is not.
See Legacy code and features for how to take advantage of this for gradual transition your siteaccesses.
Using the brand new "Platform"architecture only
This case is the one that will deliver very strong improvements in scalability and performance, in this case the whole new architecture is used and there is no way to reuse components from the legacy architecture.
This means that:
the The administration interface is not available in 5.0
existing Existing templates and site won't run without having been migrated
the old (Optional) The legacy storage system is not used any more
Note: because of these restrictions, a new storage engine has not been made yet. Similar setup can use the "Legacy storage engine" for the time being to be ready to migrate data and not have to change code when a new engine is added in the future.
While this might sound restricting for the time being, it is clearly the foundation of the future of eZ Publish: eZ Platform.
In the context of eZ Publish 5, it can be useful for new projects relying only on the concept of "content as a service" the platform is a high performance and scalability content repository with very advanced services but provide no editorial user interface. for traditional content management.
Learn more with this video :