This site has been archived and you can no longer log in or post new messages. For up-to-date community resources please visit ezplatform.com

eZ Community » Forums » Discussions » An explosive cocktail : Symfony and...
expandshrink

Monday 02 July 2012 12:05:25 pm - 68 replies

» Read full blog post

Introduction

Ever dreamt of an even more powerful eZ Publish?
Ever dreamt of an even more flexible eZ Publish?
Ever dreamt of an even easier to learn eZ Publish?

 
Well...you’d better read on.

 

Monday 02 July 2012 2:16:55 pm

Such a major change should be introduced with more info than just a short blog post. And what exactly does "best-of-breed content and customer experience management" involve from a technical point of view?

Monday 02 July 2012 3:04:09 pm

Hi Sebastiaan, 

We just wanted to share this wonderful news with the rest of the eZ Publish Community, and fellow Symfony and PHP community members, since we are extremely enthusiastic about this. 

This is a developer preview of eZ Publish 5, currently under development, aimed at being released in November under the Kilimanjaro name. It will also become the main development cradle for all of us in the eZ Community, as well as for eZ's Engineering team. 

What's more, this news is not coming out of the blue, the eZ Publish 5 topic has been addressed already here and there thus far : 

I am sure you are already acquainted with the content listed above, but just wanted to point to them for potential new comers.

Atop, we did not fail mentioning that more content will follow, more information, and in a couple of weeks or months from now, more business insight on what eZ Publish 5 will provide from a pure business standpoint. A bit of moderate suspense does not hurt, specially given that we have cracked open much already : a working proof of concept. But today, the scope is what is in the guts of the technology, how we plugged-in Symfony at the heart of eZ Publish, and our joy to crack it open and have the communities make it their own, test it, tweak it, and feed-back through comments, blog posts, or pull-requests (my preferred type of feedback, I must confide).

Cheers,

Monday 02 July 2012 3:27:49 pm

Sure, there is been enough talk about eZ Publish 5, but the decision to run eZ Publish on Symfony is new to me. Or did I miss something: http://share.ez.no/content/search?SubTreeArray=1&SearchText=Symfony? With regards to your comment "A bit of moderate suspense does not hurt" - well, this kind of suspense does indeed hurt business. Existing clients, potential clients and partners like transparency, and a clear story. So looking forward to hear more about this soon.

Monday 02 July 2012 3:38:36 pm

 

Existing clients, potential clients and partners like transparency, and a clear story. So looking forward to hear more about this soon.

That's precisely why we focused a LOT on backwards compatibility. More technical info will come out very soon, but in the meantime, feel free to clone eZ Publish 5 repository, following the installation instructions, and get started ! happy.gif Emoticon

Monday 02 July 2012 3:50:16 pm

Quote from S V :

With regards to your comment "A bit of moderate suspense does not hurt" - well, this kind of suspense does indeed hurt business. Existing clients, potential clients and partners like transparency, and a clear story. 

Hi again Sebastiaan, 

Precisely, that is the reason for opening-up wide today, while we still are in an extremely early phase of the product cycle : we thus set technological expectations, and empower everyone to anticipate. 

And as Jérôme pointed out, one of the main concerns in conceiving the architecture for eZ Publish 5 was the smooth transition from eZ Publish 4.

Cheers,

Monday 02 July 2012 3:52:02 pm

Hi Nicolas, Jérôme,

I may miss some information, but what about Zeta Components?

Thanks,

Best regards,

Jean-Luc.

Modified on Monday 02 July 2012 3:58:35 pm by Jean-Luc Nguyen

Monday 02 July 2012 3:59:29 pm

Quote from Jean-Luc Nguyen :

I may miss some information, but what about eZ Components?

Hi Jean-Luc,

The Zeta Components have recently moved to Github, you might have seen this : http://share.ez.no/blogs/ez/apache-zeta-components-moving-to-github-welcome-zeta-components 

Also, they are not disappearing at all from eZ Publish, they are in use in some places where they best do the job. We are planning on bringing more details on the architecture and usage of Symfony, so stay tuned. In the meantime, I invite you to discover it : https://github.com/ezsystems/ezpublish5

Cheers !

Monday 02 July 2012 5:48:33 pm

This is really great news! Could not think of a better foundation I would like my projects to be build upon!

Monday 02 July 2012 5:56:56 pm

Quote from Patrick Kaiser :

This is really great news! Could not think of a better foundation I would like my projects to be build upon!

Nice !

Monday 02 July 2012 6:14:07 pm

+1 this is indeed great news to have such a powerful framework as a basis for eZ Publish !

As I'm concerned ,I was more scared about the compatibility with the legacy, but I'm happy to see that it's compatible and in a very smart way ! That's a big +1 for eZ in comparaison with others CMS. 

 

Now there is jobs for the community to develop eZ Publish 5 bundles (not sure migration is possible from 4.x extension ...), will we keep the existing forge the community bundles or something else is planned ?

Monday 02 July 2012 6:20:09 pm

Quote from Matthieu Sévère :

+1 this is indeed great news to have such a powerful framework as a basis for eZ Publish !

As I'm concerned ,I was more scared about the compatibility with the legacy, but I'm happy to see that it's compatible and in a very smart way ! That's a big +1 for eZ in comparaison with others CMS. 

Absolutely !

Glad you like it Matthieu.

Quote from Matthieu Sévère :

 Now there is jobs for the community to develop eZ Publish 5 bundles (not sure migration is possible from 4.x extension ...), will we keep the existing forge the community bundles or something else is planned ?

projects.ez.no will continue its life, but one of the big plans for this year is to revamp it entirely, so it becomes more usable, and more fun.

Cheers !

Monday 02 July 2012 6:36:21 pm

Great step towards the future of eZ Publish! Can you explain (or point me to where you have explained) why you decided to put the eZ code into the "vendor" folder instead of the "src" folder? What do you expect to be stored in the "src" folder then?

Monday 02 July 2012 6:40:38 pm

Heads-up : You may want to join Jérôme, featured in the eZ Publish Show #6 tomorrow (google hangout), who will explain all of this.

Cheers,

Monday 02 July 2012 6:44:44 pm

This is huge and great news! Selecting a stable and mature PHP framework allows for increased focus on CMS-specific functionality.

Eager to try it out I've tried the installation instructions (https://github.com/ezsystems/ezpublish5/blob/master/INSTALL.md), but I get stuck at the second step of the eZP5 installation - installing dependencies with Composer. According to the documentation composer.phar should be inclued in the distro, but that does not appear to be the case (that is, unless I'm missing something). 

EDIT: Never mind. I see noe that the installation docs have been updated regarding this point.

Modified on Monday 02 July 2012 6:49:36 pm by Eirik Alfstad Johansen

Monday 02 July 2012 9:53:46 pm

Quote from Mr Bean :

Can you explain (or point me to where you have explained) why you decided to put the eZ code into the "vendor" folder instead of the "src" folder? What do you expect to be stored in the "src" folder then?

This is actually a convention. The vendor/ directory is meant to contain all the code/libs you rely on for your project (like the eZ Publish code or the Symfony components). On the other side, the src/ directory is supposed to contain your project code, specific to your site(s).

Monday 02 July 2012 10:06:44 pm

This is a major leap for eZ and the eZ Community.

There are so many advantages to moving to Symphony. For one it is a really stable framework, which has a good architecture. Another benefit is the the fact that lots of php developers out there are already familiar with Symphonyhappy.gif Emoticon eZ Publish is a great piece of open source software , but we all know that the architecture has been somewhat "old" style. 

Deciding to go for Symphony means eZ Systems has recognized the need to find more standardized libraries and framwork, especially because Zeta components never manged to make it as a huge set of libraries which php developers knew.

I am really looking forward to see the continued work and v5!

Cloning the repository is great to get more hands one experience with this.

Tuesday 03 July 2012 10:34:22 am

This is in many ways a win win situation for both Symphony and eZ publish. Symphony will get a robust App built on it while eZ Publish will finally be a product with a greatly reduced learning curve.
However, I have a few questions - mostly regarding backwards compatibility:

 

  • Are you still planning on keeping the database structure the same?
  • Even with the development speed increase, you have to (A) rebuild much of the existing logic and (B) be mindful of legacy system support for eZ4. With these two tall orders, do you still expect to deliver a stable version by the end of the year?

 

It looks to me that as time goes by, the needs of the new system will start to overpower the idea of also supporting a legacy system at the same time - even more so now with a different framework altogether. Is it possible that at some point during all of this that  the legacy support will be dropped?  Not speculating on this being a good or bad thing - just wondering if the switch to a new framework will really allow legacy support as previously defined.

-David

Tuesday 03 July 2012 11:44:31 am

Hi David

Are you still planning on keeping the database structure the same?

Yes, at least for now. A new performant storage engine will come up in the future with a revamped data model, but for 5.0 it will remain the same as part of Legacy storage engine.

Even with the development speed increase, you have to (A) rebuild much of the existing logic and (B) be mindful of legacy system support for eZ4. With these two tall orders, do you still expect to deliver a stable version by the end of the year?

Yes, the timeframe has not changed. Actually, we won't ship a whole standalone eZ Publish 5. We will still rely on legacy code for a few future versions so that we have time to rebuild the existing logic.

 Is it possible that at some point during all of this that  the legacy support will be dropped?

When we reach the point that we don't need the legacy code any more, yes we will drop the legacy support (we might keep it 1 more year or something though). The legacy code is exposed in a separate bundle, the LegacyBundle. So it's quite easy to get rid of it, but let's do one step after another blunk.gif Emoticon.

Thursday 05 July 2012 9:43:54 am

Having spent a couple of days reading the Symfony docs, I'm curious as to how ypu plan to mimic the current siteaccess and design override systems. I can see how bundle inheritance might be used for template overriding, but I wonder if you might have a more elegant solution in mind. With regards to siteaccesses, I've been unable to locate something similar in Symfony (that is, unless you plan to use environments for this which doesn't really seem like all that good a fit to me).

Thursday 05 July 2012 10:39:38 am

Quote from Nicolas Pastorino :
Quote from S V :

With regards to your comment "A bit of moderate suspense does not hurt" - well, this kind of suspense does indeed hurt business. Existing clients, potential clients and partners like transparency, and a clear story. 

Hi again Sebastiaan, 

Precisely, that is the reason for opening-up wide today, while we still are in an extremely early phase of the product cycle : we thus set technological expectations, and empower everyone to anticipate. 

And as Jérôme pointed out, one of the main concerns in conceiving the architecture for eZ Publish 5 was the smooth transition from eZ Publish 4.

Cheers,

HI.
I have been following closely discussions regarding all of this.  I try to post neutral comments - even if I include leading questions to pull some definitive committed answers.  Yes, at this stage, it makes sense that 80% of the answers are 'we are unsure'.  This is the responsible and accurate reaction that I understand and appreciate.

With a biased opinion(I love good frameworks and giggle happily inside when people say MVC), I welcome the development of a great CMS API on top of Symphony2 for smaller existing projects and ALL future projects. However, I want to point out that from what I have heard in various information streams that statements regarding "Smooth transition" and "Backward compability" should be used with care until there is a bigger understanding - otherwise, people may make assumptions that thy pass on to their clients that could be grossly inaccurate at this stage.
Even with those enthusiastic and positive words, For large projects with complicated templates and custom extensions, I do not understand to date that there is any 'upgrade path', So my summary to date is:

Moving a large project from eZ4 to eZ5 appears to have some of the following characteristics:
4.X TEMPLATES

  • eZP4 templates will be handed off to the eZP4 core for processing, thus really having ezP4 runnig while wrapped inside of Symphony2 (with probably little, if any speed benefits, for example) - so you are really still running eZP4
  • It will be a daunting task to ensure that custom template operators/fetches continue to work.
  • Nothing has been states to date regarding what will happen to a temlpate instantiated in a custom extension. At best, it will work, but using the ezP4 kernel
  • The template support in this way has a limited lifecycle of probably a few years, so during this transition period, all templates and associated logic will still need to be rewritten/re-factored in terms of Symphony/Twig/ezP5 API.

DATABASE

  • At some point, the schema will change
  • When this happens, custom fetches, etc that consume data from direct database queries to eZP tables will potentially break (although the majority of these queries should already be  going through the API anyway...)

SITEACCESS SOLUTIONS

  • This has been understoof that the final solution is not known yet.  That is ok for now. Symphony has lots of options as it is and any current solution can be extended tot he eZP Api if needed.
  • But since there are soo many ways to set up websites already  in eZ Publish (multiple core, single core separate siteaccess, single database, separate siteaccess, separate database, etc etc etc, there is certainly going to need to be some work in aligning the plethora of ways that people have accomplished this with the options adopted eZP5.

EXTENSIONS

  • Too early to comment

So, there should be no assumption that at some point, all code in templates, custom operators, mudules, settings, etc will simply be dropped in and and 'work' with minimal development time.  In fact, regardless of the task being done sooner rather than later, templates, extensions, modules, custom fetches, custom template operators will ALL have to be re-programmed/re-factored for complete representation in EZP5. Maybe not soon, but certainly something that will require a budget as there is no true upgrade path from eZP4 to eZP5 other than re-write most of what you have. The current offering for upgrading is actually what appears to be a stop-gap solution to buy you some time to accomplish the above.  But I am not complaining about this because I believe the two systems will be soo different that any level of migration options are commendable.
I'm not tryingt o steal any thynder from this as I expect to happily develop in the new eZP5 and contribute enthusiastically over the years, but for EXISTING projects, I am very guarded with my enthusiasm of the idea of "Backwards Compatible  and "Smooth Transition"
Take These two theoretical case studies:

  • Mom-and-pop website - some small website for my dentist or something
    • Total time and cost for the 'transition' is minimal and can be accomplished in a day or two - an easy sell to my client if, in fact I can prove the investment can be recovered with a smaller TCO and better features.
  • A huge website/web application with 15 custom modules and data connections to outside sources, various databases, lots of sections and overrides that would make your brain leak when trying to understand the interaction as well as various siteaccesses - all of which must continue to work with zero or minimal downtime across all of their interconnected domains.
    • With the release of eZP4.4 and beyond, LARGE amounts of time and money have been invested in the development of a highly customized website with bells and whistlles.
    • There is NO foreseeable way that this type of website/web application could be considered 'easily upgradable'. In fact, with the information available to data -and giving the greatest level of confidence in the developers at eZ, I would still have to put an honest and very modest pricetag of  > 300 man hours to consider migrating this website to the new platfiorm.
    • This is no small pricetag to pay by a company that has already been investing heavily in an ezP4 website that more-or-less does what they need.

_________________________________________________________________

There, for larger, complicated existing projects, I cannot start to imaging how I could justify explaining that anlother large investment will be needed. Even trying to do math like" future development will be twice as fast, therefore, you will recover your investment in.... well... 4+ years." seems like a tough sell to me..

For my own sanity, for now, In reference to my larger projects, I will consider eZP5 a separate product altogether and see if there are benefits in attempting a migration. This is no different than what people have had to do with major upgrades of  other open source Apps. So staying on the 4.X branch may be the final solution for the lifecycle of some websites - just like staying on 6x (or even 5X)is a valid option for some Drupal websites instead of upgrading as the customized work can not be justified in being re-written again.

 

However,  for NEW work and smaller projects, I am shivering with excitement about a great CMS API for Symphony2.

expandshrink

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

36 542 Users on board!

Forums menu

Proudly Developed with from