eZ Community » Forums » Discussions » eZ Publish 5 : Be prepared for the...
expandshrink

Thursday 05 April 2012 7:02:28 pm - 25 replies

» Read full blog post

Introduction

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.

 

Friday 06 April 2012 9:53:12 am

Twig could be a good choice. There is a lot of interesting thing in it:

  • templates inheritance
  • blocks
  • creating custom operators is very easy

And it looks like a lot http://jinja.pocoo.org/ who is very good too.

Friday 06 April 2012 10:55:55 am

This looks really promising. My wish is that you decide to go for a template solution which has proven stable and is not a fad.

Twig does indeed look like a smart solution, but smarty probably has more traction, so i guess this a hard one. Personally the idea that there is a c compiled extension for instance should make for an improved performance and this is of great importancehappy.gif Emoticon

Modified on Friday 06 April 2012 10:56:14 am by Lars Eirik Roenning

Saturday 07 April 2012 4:26:29 pm

wow. it seems like a lot of changes. great work!!

what's the plan for the admin-interface? it's going to be also updated? i heard something about getting some html5 awesomeness ^^

and can the community help with this changes?

Tuesday 10 April 2012 10:43:16 am

Quote from Juan Pablo Stumpf :

wow. it seems like a lot of changes. great work!!

what's the plan for the admin-interface? it's going to be also updated? i heard something about getting some html5 awesomeness ^^

and can the community help with this changes?

Thanks Juan Pablo happy.gif Emoticon.

We'll indeed redesign the admin interface with all nice HTML5 stuffs.

We'd be very pleased if you want to lend a hand ! We'll let you know on the right time, don't worry happy.gif Emoticon

Tuesday 17 April 2012 1:29:40 pm

Hi,

Thank you for your great work ! What about this http://share.ez.no/feature-requests/support-for-enhanced-template-engines ? Do we have the choice on the template engine to use ? -- the idea here is to provide by default the eZ template engine for backward compatibility and  let to devs the possibility to define a template engine (php, zeta components, smarty, twig, etc) for their project. Personnally i used twig on some modules it was fine happy.gif Emoticon

Modified on Tuesday 17 April 2012 2:02:43 pm by Yannick Komotir

Tuesday 17 April 2012 1:41:31 pm

Hi Yannick

There are very few chances that we embed eZ Template engine for BC... However, the idea to have several engines is studied blunk.gif Emoticon

Tuesday 17 April 2012 3:54:11 pm

Quote from Jérôme Vieilledent :

Hi Yannick

There are very few chances that we embed eZ Template engine for BC... However, the idea to have several engines is studied blunk.gif Emoticon

That's a relief.  I hope that backward compatibility is a priority otherwise I think I'll have a bunch of pissed off customers who would have to either have to no longer upgrade or see a total rewrite of their templates (I suppose I'd be very busy with that.. but, I'm busy anyway and have better things to do).

When I first read this thread I was thinking, oh crap, a totally new template engine.   Multiple engines would be cool.

Wednesday 18 April 2012 10:47:20 am

 I hope that backward compatibility is a priority otherwise I think I'll have a bunch of pissed off customers who would have to either have to no longer upgrade or see a total rewrite of their templates (I suppose I'd be very busy with that.. but, I'm busy anyway and have better things to do).

Yes, definitely ! BC is one of our strongest priority. However, about the venerable eZ Template engine, it's way too old to be properly ported, and porting existing templates as-is would be a non-sense since lots of operators and fetch functions are tightly coupled with the old database (with sometimes raw SQL queries sad.gif Emoticon).

Actually, the goal of this post is mainly to inform you how to be prepared and minimize the upgrade with the guidelines I provided. We are currently working on solutions to have new and old kernels side by side, so that migration would be less painful, but still, some stuffs would need to be rewritten as concepts are completely different.

Wednesday 18 April 2012 2:59:04 pm

Long time, no see.

Very interesting news! It's great to hear that there will be deeper changes to eZ Publish project.

Few questions and thoughts:

1) Where can we learn more about the depth of changes that are taken under consideration? I think it would also be both interesting and helpful to see a list of areas/layers/subsystems, that will not change, no matter what blunk.gif Emoticon

2) Assuming, that the changes will be VERY DEEP, do you consider to perhaps move what's best in eZ Publish in terms of content managements onto an existing, modern, testable, extensible PHP framework platform?

3) Will anything change as far as licensing goes?

4) If I was to choose one thing to definitely re-engineer in the upcoming version, it would probably be the forms subsystem used for content object editing. Please get rid of the archaic field addressing that makes it very difficult or impossible to replace the form subsystem and unlock the ability to rely on the datatypes' built-in validation and processing capabilities.

5) Are we to expect any mid-level content model and other functionalities APIs?

Looking forward to any more information on the subject.

Thank you,
Piotrek

Wednesday 18 April 2012 3:12:00 pm

Hi Piotrek

1) Where can we learn more about the depth of changes that are taken under consideration? I think it would also be both interesting and helpful to see a list of areas/layers/subsystems, that will not change, no matter what 

As I said, more information will come in the near future. Cannot say more for now, sorry happy.gif Emoticon.

2) Assuming, that the changes will be VERY DEEP, do you consider to perhaps move what's best in eZ Publish in terms of content managements onto an existing, modern, testable, extensible PHP framework platform?

This is indeed currently in discussion.

3) Will anything change as far as licensing goes?

As far as I know, NO.

4) If I was to choose one thing to definitely re-engineer in the upcoming version, it would probably be the forms subsystem used for content object editing. Please get rid of the archaic field addressing that makes it very difficult or impossible to replace the form subsystem and unlock the ability to rely on the datatypes' built-in validation and processing capabilities.

+1, definitely blunk.gif Emoticon

5) Are we to expect any mid-level content model and other functionalities APIs?

Nothing to tell about for now as we fully concentrate on redesigning/porting old features happy.gif Emoticon

Wednesday 18 April 2012 3:29:10 pm

Thanks for a quick response!

One more: how will the changes affect the enterprise version of eZ Publish? Are we talking about a final fork between the two? blunk.gif Emoticon

Wednesday 18 April 2012 4:36:07 pm

Quote from Piotr Karaś :

Thanks for a quick response!

One more: how will the changes affect the enterprise version of eZ Publish? Are we talking about a final fork between the two? blunk.gif Emoticon

Hi Piotrek,

These changes, large changes affect the common ground of eZ Publish : the kernel. No fork is in question, absolutely none, there is one single eZ Publish kernel, the one everyone can grab from github.

Cheers,

Saturday 21 April 2012 9:26:09 am

Hello Nicolas,

Thanks for the info. You did catch me at my not fully understanding what the enterprise version of eZ Publish really was blunk.gif Emoticon And I admit, I didn't really follow that after the split into enterprise and community editions. When I read about the upcoming version and on the community blog, I thought that it meant to affect community edition only. In any way, I believe it is high time eZ Publish got itself a new code foundation and that can only be good news for business critical sites and eZ Systems. I just hope backward compatibility doesn't become too much of a burden and doesn't prevent a really deep refreshment blunk.gif Emoticon Good luck!

Cheers,
Piotrek

Friday 27 April 2012 1:33:06 pm

Interesting technical details, but a crucial moment for eZ Publish customers. If the backward compatibility is limited to the point where a lot of extensions/templates will have to be changed/updated, existing customers will automatically reassess their choice for the eZ Publish. If a lot of money will have to be spend on the upgrade, why not take other CMS systems in consideration as well? Being the best from a technical point of view does not always make sense when you try to sell a product.

I said it before, and I will say it again: within the eZ ecosystem there is too much focus on the technical aspects of eZ Publish and not enough on the business aspects. We have a top product - now can we please focus on making it more user-friendly for users and formulating an effective marketing/sales strategy?

Sunday 29 April 2012 5:22:23 pm

Hi

Let me reassure you : BC is our major concern ! We are currently working hard in order to have a compatibility bridge between 5.0 and 4.x. However, current eZ Publish will most likely need to be slightly adapted.

Monday 30 April 2012 11:50:53 am

Sebastiaan,

we are fully aware of that. While I fully backup what Jérôme said above, you sometimes have to face the truth, and take decisions that will affect people.

We have been maintaining eZ Publish with full backward compatibility for more than 8 years now (13 would be closer to the truth), but we really believe we have reached the end of this particular path. Everything has evolved a lot in between: technology, expectations, requirements.

We simply can not build a bridge over this gap while carrying the whole thing with us. It is just impossible (well, not impossible, but you should be getting what I mean). And trust us, we have tried.

So instead of trying to grow up on the existing foundations, we have decided to build up new foundations, but build bridges between the new ones and the old ones. You can basically identify two bridges:

1. Make data 100% compatible

Existing data will work. Without any migration. This means you can keep using the old site, and build a new one on the side. Data can be written using eZ Publish 4.x, and shown using eZ Publish 5.x, and vice versa.

2. Make it possible to use the new and old systems simultaneously

Using advanced routing, our goal is that eZ Publish 5.x and 4.x can be used simultaneously. Content could be published using your existing, 4.x admin interface, and served on the frontend using the 5.x APIs and templates. Or the opposite. In the meantime, out of 6 custom modules, 5 could be 4.x ones, while 1 would be written using the 5.x API

We know this is big. The goal isn't that all projects are migrated to 5.x, we know it isn't gonna happen. But on the other hand, eZ Publish Enterprise 4.x will be maintained for... I think it's two years (it might be more). We are also making sure that our training services are up-to-date, and able to smooth things up for our partners. And last but not least, we also know the community will be following this up, and won't let us skip important aspects... right ? blunk.gif Emoticon

Monday 30 April 2012 12:19:08 pm

The only question everybody should be asking is: When are you planning to make the first eZ publish 5.0 code commit on Github?

Monday 30 April 2012 1:42:03 pm

Quote from Thiago Campos Viana :

The only question everybody should be asking is: When are you planning to make the first eZ publish 5.0 code commit on Github?

More information will come, don't worry blunk.gif Emoticon

Monday 30 April 2012 6:01:39 pm

Quote from Jérôme Vieilledent :
Quote from Juan Pablo Stumpf :

wow. it seems like a lot of changes. great work!!

what's the plan for the admin-interface? it's going to be also updated? i heard something about getting some html5 awesomeness ^^

and can the community help with this changes?

Thanks Juan Pablo happy.gif Emoticon.

We'll indeed redesign the admin interface with all nice HTML5 stuffs.

We'd be very pleased if you want to lend a hand ! We'll let you know on the right time, don't worry happy.gif Emoticon

 

A clarification; what we have on our roadmap is a new editorial interface as part of eZ Publish 5, not a new admin interface.

But that does not mean 5.x will not have admin interface, as Bertrand mentions we intend to keep full BC by bundling eZ Publish Etna+ (current 4.x stack) and Kilimanjaro (new stack) together in 5.x, so current admin interface will be available as is just like your existing sites will just continue to work. We'll come with some more info soon, but right now a bit busy on getting Etna out.

Modified on Monday 30 April 2012 8:46:15 pm by André R

Monday 30 April 2012 6:21:18 pm

Quote from Thiago Campos Viana :

The only question everybody should be asking is: When are you planning to make the first eZ publish 5.0 code commit on Github?

We have already been committing stuff for a year now to: https://github.com/ezsystems/ezp-next

But this repository is currently only dealing with the Model in the MVC stack, there will be some prototypes available for the rest of the architecture (View layer including twig use, Controllers, + lost of attention on dealing with migrations scenarios) soon when we are able to switch focus away from Etna (4.7).

Early prototyping for use of Public API (ezp-next) including Twig use can be found here: https://github.com/andrerom/HiMVC

(page)layout.twig example: https://github.com/andrerom/HiMVC.../Content/design/standard/layout.twig

Content\Controller::read example: https://github.com/andrerom/HiMVC...iMVC/Core/Content/Controller.php#L55 

Modified on Monday 30 April 2012 8:47:53 pm by André R

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from