eZ Community » Forums » Discussions » Is there a need for one more eZ...
expandshrink

Wednesday 23 March 2016 11:13:17 pm - 19 replies

» Read full blog post

Introduction

Dear eZ Community,

I would like to use this opportunity and start a discussion about an important topic to get valuable feedback for the community board of which I recently became a member of.

Please take some time and read my long post from few weeks ago to get some context to the topic. Last week I took part in my first community board meeting together with the old members of the board where we discussed the topic too. After that I decided to start the discussion to see what the community thinks.

The main question is on what should community board and community as a whole focus on when it comes to eZ Publish community releases for supporting existing projects.

Wednesday 23 March 2016 11:21:15 pm

Thank you for writing this, Ivo !

If a need there is (I won't be the judge of that), then my preference as the lead developer in charge of platform releases is clearly #2: an ezplatform community edition, based on our ezsystems/ezplatform, with the legacy bridge pre-bundled / configured (what Carlos Revillo did, unless I am mistaken).

In my vision of things, that is what the ezcommunity organisation is about.

Thursday 24 March 2016 2:45:19 am

I prefer #2 also.  This allows me to be as close to eZ Platform as possible in the hope that at one point I can drop all legacy dependencies.  This should also help eZ Platform move forward and narrow the gap between what features legacy had as long as the community participates and helps bring those features to eZ Platform.  I don't know how many others there are, but once the new platform ui supports a few more features that legacy had, I will be able to abandon legacy.

Thursday 24 March 2016 3:11:21 am

Similar to Douglas as a long term eZ developer I primarily need a vehicle that allows gradual transition to eZ Platform. There are may clients with limited annual budgets who have invested heavily in gradual development on eZ Publish over many years.  Even if/when eZ Platform can finally provide all the eZ Publish functions these clients still need gradual conversion to spread costs. So to be clear;

I don't care about back porting eZ Platform features. I do care about having a bug / security maintained legacy bridge as close to eZ Platform as possible.  So it seems #2 would best deliver this.

Thursday 24 March 2016 9:31:28 am

Hi Ivo,

thanks for your thougts and your post "eZ Platform is out! Community, full throttle now!" in the netgen blog.

Currently our admin are not able to fully migrate to ezplattform. Even if they have not a admin-interface supporting all the necessary features and former build in functions it is impossible to use the new one.

It might be simple to migrate an existing lagacy design extension to the new stack twig format, but there are many more extensions on the market ore from the community or even customer build who are currently not available for ezplattform. This ist a blocker for many project to migrate.

Many customers do not have the annual budget to pay for migration existing extensions. They do not care about back porting extensions and new features. They only need bug and securticy maintenance.

I think most of the projects released thelast years are build in front of ezflow extension. This will become a blocker while migrating to ezplatform since this features are now part of ezstudio which is only available to enterprise customers.

There must be an easy and gradual way to migrate to ezplatform for all projects. This is the reason why many project took ez publish in the past an not one of the competitors.

We would prefer #2 ist there is an option for the legacy bridge.

Thursday 24 March 2016 11:50:16 am

I'd go for #2 too. In some way, thats the approach followed with all ez5 projects i have tried.

But still i believe our main efforts should be focused on new stack. We  could of course do bugfixin/maintaince/backportin from platform, but i don't think we should think in add more legacy features. At least not big ones

Thursday 24 March 2016 11:57:50 am

Quote from Bertrand Dunogier :

an ezplatform community edition, based on our ezsystems/ezplatform, with the legacy bridge pre-bundled / configured (what Carlos Revillo did, unless I am mistaken).

Yep. I started with that. I was trying to add a ezplatform-legacy installer now. That's it, not only generating parametera.yml but also all the needed legacy settings file to make it work without the need of legacy install process.

 

But yeas, my idea was exactly that. Provide something to use bock stacks but having both as close as possible to ezsystems ones.

Modified on Thursday 24 March 2016 12:01:08 pm by Carlos Revillo

Thursday 24 March 2016 12:25:32 pm

Quote from Carlos Revillo :

But still i believe our main efforts should be focused on new stack. We  could of course do bugfixin/maintaince/backportin from platform, but i don't think we should think in add more legacy features. At least not big ones

Of course, it is not about coding in legacy any more. It is about using all the new features from ez platform and migrating (coding existing features in new stack)

Thursday 24 March 2016 4:56:38 pm

Thanks Ivo for yet a great open blog post.I’m not a community user and I’m not a developer, so I am probably the wrong person to answer but I still thought about chiming in happy.gif Emoticon

I just wanted to say that both #1 and #2 are areas where indeed eZ Systems has decided not to devote energy on, and I think we’ve been clear on that. The reason is we want to focus on developing eZ Platform and eZ Studio as fast as possible hence dedicating our resources. This said, we at eZ would be really happy if #1 and #2 community effort lead to simplify the life of 5.x community users, and we are willing to help as long as it doesn’t eat our resources devoted to the new generation development - as you say Ivo, they are scarce and we are no Google.

3 years of 5.x dual kernel was a great learning, we made it work and learned it was working not only for us but for most developers in the community (kudos Engineering, what an amazing journey, we should speak more about it, nobody did that afaik happy.gif Emoticon ), we also learned it was hmmm... a bit complex. Actually very complex for newcomers (remember http://www.sitepoint.com/13-steps-get-ez-publish-5-x-homestead/ ? hopefully Bruno changed his mind thanks a lot to Ivo helping there…). That is why, end of 2013, we decided for a clear cut, and executed on this in 2015 -  to make a simple platform that newcomers could embrace easily in the future.

My opinion on #1 and #2: we are not talking about the same effort, and probably indeed, everybody would say #2. #2 brings a lot more complexity (not necessarily much more work), and we know that there will be more changes in the kernel that will probably break compatibility, as well as other things moving so there is a real risk short term too. We also clearly would not like to slow down eZ Platform development for that and community should be really aware. There will be a dead-end at some point.

So, I'm thinking #1 is probably a safer option for the ones who first and foremost are looking for a stable and community supported way to run existing sites, which seems to be the case for a good share of the people out there. And in parallel of #1, help us improve eZ Platform, which should soon be a viable replacement for a majority of cases.

In parallel, we are working on tools to migrate from 5.x to eZ Platform, including here a script moving the good old ezxml to the new rich text. Any effort to help us here would be more than welcome and would hugely facilitate the jump to eZ Platform for community users. 

Just an outsider opinion happy.gif Emoticon
Cheers,Roland

Thursday 24 March 2016 11:39:49 pm

Another vote here for #2 "create a new community edition which will use eZ Platform with legacy bridge and the old administration". Is this controversially and possibly also an option for enterprise aka non-community customers as well? Currently they're in the same boat if Platform UI is not an option for them yet, since they're technically "stuck" on 5.4.6.

Friday 25 March 2016 12:10:58 am

Quote from Peter Keung :

Another vote here for #2 "create a new community edition which will use eZ Platform with legacy bridge and the old administration". Is this controversially and possibly also an option for enterprise aka non-community customers as well? Currently they're in the same boat if Platform UI is not an option for them yet, since they're technically "stuck" on 5.4.6.

Not exactly in the same boat, as they have support and maintenance for the 5.x stack with bug fixies and etc... (5.4.6 is just out) which community lost as eZ is now not focusing on backporting to the community project. It's actually a substantial difference. Hence the value in #1 for the community too. This said, you do raise a good point Peter. 

Friday 25 March 2016 9:42:00 am

Quote from Roland Benedetti :

So, I'm thinking #1 is probably a safer option for the ones who first and foremost are looking for a stable and community supported way to run existing sites, which seems to be the case for a good share of the people out there. And in parallel of #1, help us improve eZ Platform, which should soon be a viable replacement for a majority of cases.

Hi Roland,

The problem with the option #1 is that it will limit community improvements of eZ Platform. If you are working with a release that does not have all new features and you are limited with eZ 5 new stack features with maybe just couple of things back-ported, this will limit usage and contribution of eZ Platform. 

That is why, I think, many community members would be more for option #2, because they want to use all new features but they are bound to existing projects and can not start from scratch.

Friday 25 March 2016 12:30:34 pm

Also I vote for "create a new community edition which will use eZ Platform with legacy bridge and the old administration". I think this is a good chice!

Thursday 31 March 2016 4:34:04 pm

TL,DR:

Voting for "create a new community edition (might be e.g. version 2016.02) which will use eZ Platform with legacy bridge and the old administration"

 

The long version:

We are a small agency with me being the sole developer for most projects, and we are also in the "fight with WordPress" boat. Our standard projects typically range from 2000-3000 € including content transcription. When we started with eZ v3.x several years ago, we have chosen it because it had a technically excellent core, almost everything we needed was doable out of the box without a plethora of plugins. 99% of our use cases were fulfilled by creating content classes (or content types as they are called now) and writing project specific templates.

I have to admit that for ez System and the community we haven't been a help at all. We never had an enterprise grade project or customer spilling back money to eZ. We have not created a single extension because everything we developed was done with configuration, templates, content classes or template operators based on the "OW Simple Operators" extension. We have contributed a little into Jira and some small pull requests to extensions on Github, but overall I have to admit that it is clear that eZ Systems cannot make a living of agencies like ours. My only defense is that we never needed to code something worth sharing, because eZ's core features and content repository made everything we did project specific configuration and design. We didn't start every project from scratch, quite the contrary, but we heavily reused content classes and line view templates.

(Sidenote: I want to give a big shoutout to the guys from CJW Network for their excellent newsletter tool, which is not part of core, but which we use very often!)

Going over to eZ v6 (we never used eZ v5 for real projects, our internal production master is based on pure legacy v2014.11), and Ivo's netgen blog post:

From a technical/integrators point of view, I'm not worried about doing the content fetches in the controller. After reading the docs I'm confident that the way we structured content before most of our controllers won't change at all across different projects. I think we still will be able heavily reuse content classes and templates. Yes, there will be some overhead, but I think it will be insignificant.

We also have few worries on upgrading or breaking changes... first we almost don't have any features that could break, as I said we mostly get along using templates and the content repository. Secondly we often don't even have the need to upgrade: The good thing of low budget projects is that their lifecycle is shorter than enterprise projects, and - as long as there are no security issues - (major) upgrades usually come along with a complete new design, which leads to a completly new project.

This leads to the bad point of eZ v6, the new admin and stripped features: Instead of repeating everything I better refer to the transitioning page and the Ivo's blog post. But currently we are missing so many absolutely vital features that it is out of discussion to use eZ v6. We try to avoid major upgrades on existing projects, learning new stuff is fun, but the missing features are a show stopper for us, and we currently can't get around them.

So our biggest concern with eZ v6 is not maintaining existing projects. We are really concerned that features we have used on every project no longer have eZ's corporate patronage and quality. Even if the community - including myself happy.gif Emoticon big promise - steps in and recreates most of them, I don't want to end up in the plugin cancer of WordPress or Drupal (Is plugin A working with plugin B? Am I forced to check/upgrade all my sites every week because all the 3rd party plugins generate more security advisories than visitors?)

 

Greetings,
Reinhard 

Modified on Thursday 31 March 2016 4:37:08 pm by Reinhard Hutter

Thursday 31 March 2016 5:39:29 pm

Thanks Reinhard for the warm words for our CJW Newsletter there are some new features coming soon.

We switched from our patched cjwpublish1411 to the netgen kernel to put the community efford together and we'll adjust our mutli site / mutli repository bundle to it, so we have a stable, secure and bug fixed base for our legacy business.

So two things are important:

having a stable, secure and bug fixed 2014.12, ... version for the current old installations, like a community medium long term release, so everybody can update to this version from 4.7/2012.6 on the first step, may be legacy only or mixed or pure.

and

2. create a new community edition (might be e.g. version 2016.02) which will use eZ Platform with legacy bridge and the old administration. The main effort for the community would be to solve the breaking changes on the legacy kernel side so that the old admin is usable.

so everybody can update to this version on the second step or go directly to eZ Platform if there is sometimes an ezxmltext field blunk.gif Emoticon

Greetings, ekke

 

 

 

Friday 01 April 2016 2:16:22 pm

I think that option #2 is the only viable option. As Ivo said, problem with #1 is that it can receive only bug and security fixes and most simple features, which is not enough in the long run and does not benefit adoption of eZ Platform.

I am, for one, willing to devote some personal free time (and probably some company time blunk.gif Emoticon to develop eZ Publish 4 and legacy bridge when breaking changes occur. First example of this is my patch for normalized usernames which is waiting for a decision and merge happy.gif Emoticon

Monday 04 April 2016 11:20:23 am

I agree with Ivo and Edi. For anyone who is interested in eZ Platform in the long run,option #2 is the only viable option.

Although being far from complete or ideal, the current state of v2014.12 allows for a smooth migration of existing projects, allowing new features to be built with the new stack. It should therefore nevertheless receive a minimum of maintenance as Edi suggests.

Monday 04 April 2016 5:58:52 pm

Also my vote is for option #2!

(Thanks Ivo for your commitment to the community!)

Wednesday 06 April 2016 11:14:19 am

Hi Ivo,

yes, there is a strong need for more community releases.

For the most of our clients it's too expensive to switch to platform / studio in the near future.

We can offer developments / reviews / bug fixes for such community releases.

Such a community release should be maintained by trusted ez partners and/or people who have a long experience with the system.

Best wishes,

Georg.

Thursday 26 May 2016 12:13:24 pm

my vote goes for option #2

expandshrink

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

36 542 Users on board!

Forums menu

Proudly Developed with from