Thursday 05 April 2012 7:02:27 pm
You must have heard at least some noise about it: eZ Publish 5, aka Kilimandjaro, is coming by the end of the year. This is a major step for all the eZ ecosystem as it consists in a complete re-design.
We are working hard to bring you a new shiny eZ Publish, with awesome features and even more extensibility. I know that the "complete re-design" phrase might frighten some of you and make you wonder:
What about my current extensions ?
What's the plan for migrations ?
These questions are more than legitimate, so let me try to reassure you a bit.
First, databases from eZ Publish 4.x will be compatible with Kilimandjaro. This is a very important point since it will allow eZ Publish 4.x and eZ Publish 5 to cohabit (new features on your website could be developed with Kilimandjaro while other sections still remain in the old eZ Publish).
Secondly, eZ Publish 4.x will still be supported in the future and community releases will continue.
Okay, but you don't answer on migrations
Right, but be aware that there will be no magic! So YES, you will have to rewrite some parts of your existing code, as the whole MVC stack will change (including the template engine).
That being said, I can give you some hints that can save you from upcoming headaches.
This is the most important thing : Separate your business logic so that it's not too tightly coupled with the current API.
Some examples can be:
The key point here is to delegate all your business logic to custom PHP classes, even for a simple template operator. Every eZ Publish extension point should be covered as much as possible. For example, if you have developed an SSOHandler, try not to write your code inside your SSOHandler class. You might create another class, independent from eZ Publish, that handles the necessary login actions with your SSO.
The same piece of advice goes for a template operator, a workflow event type, a content edit handler... Leave your entry points to eZ Publish API clean by moving your logic to your own classes.
If you're tightly coupled with an eZ Publish feature, like an eZPersistentObject implementation for a custom database table, the hint given above might not be sufficient. But you have other options ! Use abstract classes so that the common code between the legacy and the new API can be easily shared in a mother class.
eZ Publish 5 will use PHP namespaces massively. Thus, you should start to use them (and migrate to at least PHP 5.3 if not already done). eZ Publish 4 supports namespaces since Annapurna (4.6) and even Traits as of upcoming Etna (or if using Community edition: 2012.1).
As I said, our 10 year old template engine will change with Kilimandjaro. We're currently not completely decided on which we're going to support, but we're looking at the most modern ones (did I mention Twig ?). More information will come on this side.
That's all I can say for now, but be sure that we will make migration the least painful possible. We know the amount of work it represents...