eZ Publish 5.0 is coming

With Etna (4.7) now out the door, eZ Publish's git repository is now re configured for 5.0.0alpha1, signaling that development of 5.0 has started. This has no effect other then signaling ezpublish repository is about to see some larger changes than you would normally see in the next 4+ months.

5.0 will actually consists of two parts:

• An enhanced version of Etna (referred to as 4.x stack),
• Kilimanjaro (referred to as 5.x stack). 

Those parts will be tightly integrated together and allow you to use either part side by side or in combination.

IMPORTANT NOTE: But before you read on, do know that we intend to allow your existing 4.x site to work as is and that there is no plan for removing the "4.x stack" for several years to come.

5.0 from a high perspective:

What we have

Kilimanjaro has been in development for a bit over a year now, it's been available on github.com/ezsystems/ezp-next for almost just as long. It is intended to become a fully modern HMVC architecture, but so far our main focus has been on the M, the Model, with all APIs and layering (adhering to Separation Of Concern & Domain Driven Development) to allow us to transparently switch to NoSQL in the future, this is thus seen as the largest and most important part of eZ Publish 5. It is a big step up from what you might call APIs in current eZ Publish, and will help you accelerate development and time to market considerably.

The architecture you can find already in ezp-next is:

• "Public API" ( eZ\Publish\API\Repository ), 
• Refactored Business Layer ( eZ\Publish\Core\Repository ), 
• Persistence API ( eZ\Publish\SPI\Persistence )
• Storage Engine using current database model ( eZ\Publish\Core\Persistence\Legacy ).

Not a complete list, but some improvements native to the new Public API:

• No inline SQL or SQL dialects needed, this is handled by persistence layer, reducing code and possibility of injection attacks.
• Permissions should be handled by Public API, making recent security fixes a thing of the past.
• No need to reverse engineer the code in lack of documentation, everything has documentation.
• Full use of exception & type hint to catch wrong api/code use as early as possible
• Fully continuously tested, also for code examples

We have also been working hard on preview of Editorial interface and REST API v2, and as hinted in overview above these parts should be available within the next month.
What you can expect to see:

• Editorial interface:  Personas > user Scenarios > concepts > wireframes > early designs > skins
• REST API v2: Hateoas based REST interface that talks directly to Public API and transfers objects serialized over the wire as json or xml, also includes a PHP SDK for easier being able to talk to a REST server.

Current prototyping

In addition to REST and Editorial interface we are also working on prototyping the rest of the architecture (the Hierarchical, View and Controller parts of HMVC).

The requirements are:

• Full 4.x backwards compatibility, following more or less normal upgrade instructions a existing site should be able to work as is*
• Modern HMVC like architecture
  • H: Hierarchical, means embedded views are native to the stack (see links in the end of this post for an example)
  • M: Model Covered by Public API
  • V: View a configurable view system where Twig is used as default template engine
  • C: Controllers (actions) are thin, usually no need to deal with permissions, sql or input parameter parsing  (see links in the end of this post for an example)
• As small as possible additional overhead for 4.x kernel
• Covering migration scenarios between 5.x and 4.x that are realistic for 5.0** (see the 3 top green arrows in diagram above):
  • Adapting 4.x to be able to be used hierarchically, hence reuse view output from 4.x in Twig templates
  • Adding template operator in 4.x to be able to use hierarchical views inside of existing templates
  • Add template function in Twig to be able to include existing 4.x templates ( with converter support for converting 5.x objects to 4.x objects )

* We do intend to remove most deprecated features, we are also considering adjusting certain features that should be shared between 4.x and 5.x (Session, SiteAccess, ..) and discussing removing features that do not fully make sense in the 5.x architecture ( first and foremost: a 4.x stack only static cache ).

** We intend to add support for more migration scenarios in "Stetind", the eZ Publish release in May 2013.

More information about this prototype will be available in the beginning of June, stay tuned! :)

How to contribute

Until we start to merge in code to eZ Publish repository and the features described in this blog post start to appear in community builds (eta: mid/end of June), here is currently how you can test out Public API using an existing eZ Publish installation, discuss it in our API forum section and create pull requests:

• Make a backup or clone your setup ( eZ Publish + db )
• Checkout https://github.com/ezsystems/ezp-next
• Enter new folder
• Copy config.php-DEVELOPMENT to config.php
• Create settings/override/service.ini & add configuration like described in forum.
• Either modify index.php or create your own cli script similar to index.php (also see forum link above)

Further reading

eZ Publish 5 : Be prepared for the future + with additional information in comments

HiMVC: Early Proof of concepts for eZ Publish 5:

• (page) layout.twig example
• Header view as used in layout.twig above
• Content\Controller::read example