Tuesday 01 March 2011 2:26:08 am

Hi Marko,

With regards to your comment (http://share.ez.no/forums/discussions/ez-publish-community-project-matterhorn-4.5-beta-1#comment66204) above about creating new objects/content and the current issues: eZ Engineering said they'll try to tackle it before the final release.

-- Robin

Board member, eZ Publish Community Project Board - Member of the share.ez.no team - Key values: Openness and Innovation.

LinkedIn: http://nl.linkedin.com/in/robinmuilwijk // Twitter: http://twitter.com/i_robin // Skype: robin.muilwijk

Thursday 10 March 2011 5:07:10 am

Hi,

Does anyone have a full changelist of what made it into 4.5

I know in the roadmap there were lots of things not listed here.

• Mobile application for editors
• Improved workflow and refined Object State systems
• Redesigned eZ Flow and Front End editing User Interfaces
• Redesigned sample sites and themes

• Targeted content publishing
• API for mobile applications and toolkits
• User subscription management
• Semantic Web support
• Improved User Generated Content management

• Improved eZ Network with improved deployment capabilities
• Improved Service Portal
• Archive add-on
• Cloud support

• eZ Publish APIs
• Improved Metadata management
• Performances and scalability of the Content Engine
• Content Import

Did any of the above get moved into 4.6?

Please let me know

Tony

Tony Wood : twitter.com/tonywood
Vision with Technology
Experts in eZ Publish consulting & development

Power to the Editor!

Free eZ Training : http://www.VisionWT.com/training
eZ Future Podcast : http://www.VisionWT.com/eZ-Future

Wednesday 23 March 2011 6:48:12 am

I do not think so.

Cheers,

--
Nicolas Pastorino
Director Community - eZ
Member of the Community Project Board

eZ Publish Community on twitter: http://twitter.com/ezcommunity

t : http://twitter.com/jeanvoye
G+ : http://plus.tl/jeanvoye

Wednesday 23 March 2011 7:17:40 am

Hello again Eirik,

Indeed, i can see that Beta 1 was referred to as the first one, letting expect more. Our Alpha-Beta-RC countdown usually depends on the amount of issues precisely found along this countdown. It appears that neither a Beta 2 nor RCs were required based on the feedback on Beta1. Atop, from Matterhorn and on, we are likely to provide builds of the Community Project, regular ones, rather than Alpha-Betas-RCs of Enterprise Edition every 6 months. This will streamline feedback, better fitting the idea of continuous innovation embedded in the Community Project.

Cheers !

--
Nicolas Pastorino
Director Community - eZ
Member of the Community Project Board

eZ Publish Community on twitter: http://twitter.com/ezcommunity

t : http://twitter.com/jeanvoye
G+ : http://plus.tl/jeanvoye

Friday 29 April 2011 1:02:30 pm

Hi Marko,

I'll try to check with Engineering what happened with this issue. I'll report back when I know more.

Regards Robin

Board member, eZ Publish Community Project Board - Member of the share.ez.no team - Key values: Openness and Innovation.

LinkedIn: http://nl.linkedin.com/in/robinmuilwijk // Twitter: http://twitter.com/i_robin // Skype: robin.muilwijk

Thursday 19 May 2011 12:03:33 am

Hi Marko,

This was not pushed in 2011.5. Do you have a work-around on your side ? (trying to get that fixed as soon as possible)

Cheers !

--
Nicolas Pastorino
Director Community - eZ
Member of the Community Project Board

eZ Publish Community on twitter: http://twitter.com/ezcommunity

t : http://twitter.com/jeanvoye
G+ : http://plus.tl/jeanvoye

Thursday 23 June 2011 1:32:24 pm

Is this going to be fixed soon?

I don't see it in 2011.6...

--
Nothing is impossible. Not if you can imagine it!

Hubert Farnsworth

Thursday 23 June 2011 2:29:01 pm

Wow, that's great, I havent seen such an inovative idea since 1995... :)

--
Nothing is impossible. Not if you can imagine it!

Hubert Farnsworth

Thursday 23 June 2011 3:03:08 pm

It's not about someone creating a pull request, but about eZP crew having trouble understanding the basics of UX (this is not the only case). So my points are...

• a quickfix workaround is not difficult to implement (like it's done in 2011.6), but it's still a quickfix and not a real solution
• several ideas were proposed on the issue tracker, but none from the eZ crew even bothered to comment on the issue
• this was reported 9 months ago
• why was this unusable menu even created in the firstplace?
• this is something eZ crew should discuss about and not leave it just to the comunity (remember that there are many customers that don't upgrade because of this problem)
• I could create dozens of pull requests but if they were all rejected I'd be just wasting my time (even you have second toughts about proposed solution)
• I did propose a solution that extends the google translate selector to the case where there's an unknown number of items, but noone bothered to discuss about it

--
Nothing is impossible. Not if you can imagine it!

Hubert Farnsworth

Friday 24 June 2011 12:17:02 am

Hi,

I don't want my messages to be misunderstood, so let me precise a bit how things work regarding the development of eZ because this issue is a good example.

We have a lots of feedback on the current state of the product through Partners (Community and Business), the community with this forum, the bug tracker or direct contact and don't get me wrong, this is GREAT! We also have in mind some features (a lot in fact!) we want to implement. These points give us a HUGE todo list. Obviously, we are not able to address all entries in the todo list (even if we were 10 times bigger I'm not sure if we can...) so we have to make choices. Choices are hard, we are probably wrong sometimes but it's the only way to move forward. Even if a new feature or an enhancement is not taken into account, it does not mean that if someone provides a patch it won't be integrated, it just means that we are focusing on others points.

A good example for this, is a pull request regarding the configuration of a proxy in the setup of eZ Publish, IMHO, this is a cool enhancement that some eZ Publish users need, we don't have time to develop it on our own, so the user decides to do it and it's about to be integrated (after some minor fixes).

To talk about the menu, it's a bit bigger than the previous example, but it can follow the same path. As I already said, I agree that the menu is not perfect but except you and Carlos in this thread we don't have so much feedback on this (really!) and that's probably why it is not prioritized yet (nevertheless, we tried to improve it a bit). By the way, refusing to upgrade just because of this is weird to me, if you look at the others improvements the upgrade may bring... but anyway. As I previously said, eZ is open source, we provide a way to contribute on it and we're always happy to see external contributions so if the issue is important enough for you (and it seems), you can try contribute a working solution.

I understand you don't want to waste your time, so can I propose you a workflow to move forward and to not waste too much time ? You can for instance make a prototype, it does not need to be fancy so it won't take so much time, it is just here to give the idea and experiment it, then you can post the code and a demo (a screencast in this case) in the forum or (better IMHO) on sdk-public@lists.ez.no. it's a kind of RFC and posting it here in the forum and/or on sdk-public will give it more visibility than in comments of the issue tracker. After this, two solutions :

1. we find it interesting, we may help you and if you're doing a good pull requests based on it with the full solution, it will be integrated. And someone else may find it interesting, you can even get help on it from the community
2. we don't find it interesting (too complicated, difficult to maintain, ...), you have the choice to give up, find another solution or to package your idea in an extension that one can deploy to fix the issue when he feels it's necessary (in this case it's just a matter of overriding a template and/or a JS file).

the waste of time would be minimum, and things will progress in the right direction.

You also talk about others UX issues, the very basic thing to do is to create issues about each of them. Again, it does not mean we're going to fix them (choices...), but at least we can discuss on them.

Cheers

Damien
Planet eZ Publish.fr : http://www.planet-ezpublish.fr
Certification : http://auth.ez.no/certification/verify/372448
Publications about eZ Publish : http://pwet.fr/tags/keywords/weblog/ez_publish