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 » Suggestions » Roadmap for 4.4. Any Ideas?
expandshrink

Roadmap for 4.4. Any Ideas?

Roadmap for 4.4. Any Ideas?

Tuesday 23 February 2010 8:19:52 pm - 41 replies

With 4.3 pretty close to its stabilization deadline, it's time to start the drums rolling for the roadmap that will lead to the next version. Much in the same vein as the open discussion that took place on this forum about the improved admin interface for 4.3, I think the community can contribute in shaping the greatest version-to-be ever.

My own ideas wishes: make 4.4 a developer's best friend - keep improving the new interface introduced in 4.3, but focus on simplifying the developer's job.

  • move the webshop completely out of the kernel into a new extension - a leaner, meaner base install is a boon
  • move all code for displaying/editing templates and the RAD page out of the kernel AND start developing it with: a rad wizard for every feature commonly found in extensions: datatypes, fetch functions, functions, workflow events, cronjobs, etc... merge code from ezgeshi for syntax hilite and from ezcodesniffer for compliance checking
  • set up a proper dependency management framework for extensions
  • allow extensions to install/deinstall tables and data when enabled/disabled
  • improve the interface used for creating and installing packages, making more apparent the distinction from downloaded packages and packages locally created; allowing to create new version of local packages; allowing to pick remote package repos via gui
  • rebase the ez package format on pecl

Wednesday 24 February 2010 8:48:06 am

Few simple ones happy.gif Emoticon

  • include script for adding attributes on classes with many objects (already exists, you just need to put it in bin/php folder)
  • export to csv functions for objects, collections,shop,...
  • pdf export that works good with utf-8 (e.g. paradoxpdf extension)
  • owner changing in admin (owner extension)

Wednesday 24 February 2010 9:25:27 am

Few simple ones happy.gif Emoticon

  • include script for adding attributes on classes with many objects (already exists, you just need to put it in bin/php folder)
  • export to csv functions for objects, collections,shop,...
  • pdf export that works good with utf-8 (e.g. paradoxpdf extension)
  • owner changing in admin (owner extension)

For export, you may take a look at eZXMLExport blunk.gif Emoticon.

About PDF, if 4.3 roadmap has been respected, this will be packaged with eZ Publish 4.3 (based on eZComponent Document).

Here are my votes :

  • Content class inheritance
  • Package system that really works (eg: problems while packaging content objects)
  • Overridable kernel datatypes (datatypes that uses class autoloading system)
  • Idem for event types

Maybe other stuffs that I'll add later happy.gif Emoticon

Wednesday 24 February 2010 9:30:38 am

This probably doesn't sound very inspired, but I'd like to see a cleanup of the default templates to get rid of all that deprecated code. Maybe support for <section> and the like should be dropped completely in 4.5.

I'd also like to see the ability to hide content classes and image aliases from editors.

And, I'd like a new, stripped down, version of ezwebin. Lose all those extra divs which were added to allow rounded corners - there are better ways to do this now - rationalise the DOM

I'd also like to see some work done on images - make all the indexed images in ezwebin CSS sprites (a default ezwebin install has something like 60 images referenced in the stylesheets, and gets dismal scores in yslow).

Maybe something like this http://jaredhirsch.com/coolrunnings/about/ would be in order.

Wednesday 24 February 2010 10:13:46 am

For my part a real dream would be to get the possibility to manage many languages by siteaccess.
So, in a mutlisite/multilanguages configuration, we actually configure siteaccesses like this :

site1_fr
site1_en
site1_it
site1_admin
site2_en
site2_it
site2_admin

It would be nice to manage all languages into one public siteaccess to get this configuration :

site1_public (in many languages)
site1_admin
site2_public (in many languages)
site2_admin

Also, I'm OK with Paul to clean and purify the DOM and if possible reorganize, minimalize and merge the stylesheets provided by default.

Modified on Wednesday 24 February 2010 10:17:47 am by Sébastien Antoniotti

Wednesday 24 February 2010 11:27:54 am

Hi all,
As announced in Geneva, i will try to update very quickly the roadmap from eZ in order to share and give more visibility on what we have been thinking at eZ, as of course, many things are already baking.In the mean time, i'll share some of my/our thoughts in this forum.

Without being too long for now, i can say that we definitely want to continue the good work done with the administration interface rewamp, and willing to involve even more users and all the community in that process (the 1st phase being a bit short for that).

I can also say that, if i agree with Gaetano, the 4.4 should be somehow the developers' best friend, we think it should be the editors' best friend as well (may be even more ?) ! This will remain a very important direction. Bruce and Damien came with some nice suggestions about that, for instance like splitting technical admin role and functionnal admin role, i definitely think we should explore that.

We will also go in the direction of the features discussed in Geneva, where workflow, metadata management, loading tools, user subscriptions and other great ideas where discussed (see http://share.ez.no/blogs/ez/speed...g-with-15-candidates-for-ez-publish).

On going work on scalability will be done as ever, as we will always try to improve that side of the product !

And finally, no doubt mobile publishing is definitelly growing fast now, we might work on making our platform even more "mobile-friendly" !

Stay tuned and lets try to improve this community platform. A forum is great but we should bring may be new interactive tools like polls or rating.

I'm looking forward to read many other ideas and wishes here !

Roland

Wednesday 24 February 2010 11:36:45 am

Thanks Roland

I add my vote on another one :

  • Improve the installation wizard in order to put newly created siteaccesses in a dedicated extension (should be optional I guess)

Wednesday 24 February 2010 11:49:48 am

Hi all,

Here are some ideas

  • Getting ride of the spam comments on share.ez.no blunk.gif Emoticon
  • Online documentation update
  • +1 for cleaning html of the default designs
  • +1 for minimalizing css
  • +1 for a dedicated shop extension ( and why not, turning it into a community project )
  • Cache block expiry by multiple sub-trees
  • Api or Interface for content sharing between multiple eZPublish instances
  • Fixing settings files override order (i have to test for each new version if the order have changed or not, as there are a lot of different point of view concerning this)
  • Creating a dedicated (section/ tab / subtree) for custom settings and utility content objects in eZ Pulbish Admin interface
  • Per environment settings management (nice to have)
  • For all Content Packages use the same langage ( English UK or English USA but not the 2)
  • Per Content Class/Subtree State Groups(permit to assign a Specific object states group to a class or subtree, to simplify default states assignment)

[Update]

A great addition would be to permit override native module view and adding custom views to this ones (clean way to prevent hacks).

Big thanks to eZ crew for their efforts to make eZ Publish stronger faster and better !

Modified on Wednesday 24 February 2010 6:08:44 pm by Karnichi Mohamed

Wednesday 24 February 2010 11:58:54 am

  • Getting rid of the spam comments on share.ez.no blunk.gif Emoticon

Hehe, yes, it is planned to address this, definitely happy.gif Emoticon
Sorry about the pollution.
Cheers !

Wednesday 24 February 2010 12:18:42 pm

  • Per environment settings management (nice to have)

Check out NovenINIUpdate blunk.gif Emoticon !

Wednesday 24 February 2010 1:22:44 pm

@ Jérôme I know about this extension : the matter here is to simplifiy developpers work, so it would be better if it was native happy.gif Emoticon .

Wednesday 24 February 2010 2:19:48 pm

I can only agree with that happy.gif Emoticon

Wednesday 24 February 2010 3:33:53 pm

Gaetano, thank you. 5 stars is highest rating, yours deserves 10, can we vote twice? Hits every nail squarely on the head for my wishes from dev side.

Only addition is some where, some how, some time, clear documentation for newcomers. My preference, make the installation choices ezwebin, ezflow, learners. Within learners provide a self-contained, no linking out, no references to past versions, 10 step tutorial to cover care and feeding of eZ for user with assumption user has no html-php-database knowledge. Only that they can read, basically.

Simple is the key. Sooner comes simple, sooner get newbies valuable insights and convert them to project members.

Cheers!

Wednesday 24 February 2010 3:56:00 pm

Only addition is some where, some how, some time, clear documentation for newcomers. My preference, make the installation choices ezwebin, ezflow, learners. Within learners provide a self-contained, no linking out, no references to past versions, 10 step tutorial to cover care and feeding of eZ for user with assumption user has no html-php-database knowledge. Only that they can read, basically.

Hi Doug,

I support this approach, driven by the will to have great and simple educational content for beginners. This was already detailed by yourself there, in a great way : http://share.ez.no/forums/general...ng-time-required-to-grasp-ez-publish.

These "step-by-step-for-beginners-concrete-tutorials" should also make their way in share.ez.no's tutorials database. They could be linked from the "learners" package you are evoking, but need to be present here as well.

Keep up the good momentum,
Cheers !

Wednesday 24 February 2010 6:38:12 pm

Hello,

 

It’s sometimes hard, even for older developers to grab ideas scattered all over forums and comments on how to do simple and complex tasks, even more tedious is dealing with information for different ez versions, projects already published (extensions) and the ones that are being developed at a current stage.

 

I think there could be a new forum (or similar way) of knowing “How to’s” that will lead us to know simple and complex tasks.

 

There are so many features in ez that trying to understand all is impossible so when a new challenge is faced in a new project that involves an ez site you end up with a headache just searching and joining all pieces of information together (and sometimes we end up with a not so good solution at all)

 

It will help the newbies and older users to know the possibilities that ez could add to their projects and ease the information flow of discovering things that we could do that goes beyond our current knowledge, it could help newbies to get ideas on how ez can solve problems and thus compare the advantages and disadvantages of ez with other open source CMS’s.

 

A topic in a forum (or else) of “How to’s” could have links to extensions, new projects arising, pieces of code… and if moderated have their own roadmap to follow and contribution by the audience.

 

thank, keep it running ez

Wednesday 24 February 2010 11:37:24 pm

I'd like :

  1. Workflow improvement : more native workflows, more triggers, user friendly interface for managing drafts/waiting contents/validations
  2. An easy way to manage staging (no more buggy packages please)
  3. Improve & debug ezsurvey
  4. Policies on attributes

Thanks happy.gif Emoticon

Thursday 25 February 2010 12:34:28 am

Yes::: Policies on attributes, How could I forget that...

Thursday 25 February 2010 8:27:57 am

Policies on attributes : +1

Thursday 25 February 2010 10:15:13 am

@all: per-environment settings management

This is imho already possible: when there are not many siteaccesses in use, you can create a version of the siteaccesses per environemnt (eg. front_dev, front_test, front_prod, admin_dev, admin_test, admin_prod). It is true that it forces to have a lot of duplicate files and not to put stuff in settings/override that really belongs there, but I found it a simpler alternative to set up than cretating ad-hoc deployment scripts every time. But in the end what i think we need here is a settings system based on tags: for every setting it's not the file where you read it that decides the weight it has but a tag, eg. Dbname\override=thisandthat. But this is a topic that has already been discussed for a while (here and in the issue tracker), and it deserves a thread of its own. Maybe staring with writing down all the use-cases for the revamped ini system?

+1 for autoloading datatype php classes - also keep removing all the manual inclusions of php files everywhere (eg. for template operators/functions too)

+1 for allowing setup wizard to create a new extension with the siteaccesses if user desires so. More important: let the setup wizard ask if there needs to be user-login and user-registration to public siteaccess and disable it otherwise

+1 for cacheblock expiry by multiple subtree, but also by single node

@paul bolger: "hide content classes and image aliases from editors" - can't you just hide content classes via the roles & perms system? what do you want exactly here?

+10 for creating a new top-level node where content-related objects are put. It might be the design, after all (hey, it already exists!). Give it a tab on its own, just like media, maybe rename the tab to 'structure', show treemenu on the left and start using it. The great advantage being of course that all stuff put in there has no url_alias direct access and resides by default in a section of its own: extra bonus for security

extra workflow events: easily doable, in fact I've been thinking about grouping the existing ones in different public extensions in a single new extension

better management of staging/prod sync: improving the package system goes a long way towards that goal (eg. allow class definition to be upgraded without loosing existing content; allow package wizard to create new versions of existing packages, etc...)

Modified on Thursday 25 February 2010 10:16:05 am by Gaetano Giunta

Thursday 25 February 2010 10:26:21 am

My 2 cent:

  1. Support for data migrations (allow data to move from development -> staging -> production)
  2. See #1

Currently deploying changes to existing classes, new objects, etc is a major PITA. The goal should be to allow for 100% automated deployments with support for rolling back changes.

We currently use Capistrano + Git to deploy websites, however changes to the DB have to be manually carried across. Not to mention the hassle of node and object ids and the fun of them being different on production vs staging vs development and the headaches that causes.

In some of our bigger enterprise sites it takes almost more time deploying new features than we spent developing them.

Ole

Modified on Thursday 25 February 2010 10:29:29 am by Ole Morten Halvorsen

Thursday 25 February 2010 10:36:16 am

I also had the wish for a simplified default website interface... so I have already started building one. If there's any interest to pick this up as a community project let me know. It still needs a lot of work on optimizing but slowly it's getting somewhere!

For a quick demo of the website interface take a look here: http://eng.cmandev000.com.

For two examples what's been build with this interface take a look here:

- http://www.boekpakket.nl

- http://www.oorschothovenier.nl (to be updated next week!)

expandshrink

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

36 542 Users on board!

Forums menu

Proudly Developed with from