Roadmap for 4.4. Any Ideas?

Tuesday 23 February 2010 11:19:52 am

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

Principal Consultant International Business
Member of the Community Project Board

Wednesday 24 February 2010 12:25:27 am

For export, you may take a look at eZXMLExport ;).

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 :)

Wednesday 24 February 2010 1: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.

eZ Publish Freelance
web : http://www.webaxis.fr

Wednesday 24 February 2010 2: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 2:58:54 am

Hehe, yes, it is planned to address this, definitely :)
Sorry about the pollution.
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 24 February 2010 4:22:44 am

@ 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 :) .

http://www.amiralweb.com Certified eZPublish Expert

Wednesday 24 February 2010 6:33:53 am

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!

Doug Brethower
Apple Certified Technical Consultant, Southwest, MO USA
http://share.ez.no/directory/companies/lakedata.net

Wednesday 24 February 2010 9:38:12 am

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

Diseño Web Cuba
Web Design Cuba
www.elfosdesign.com

Wednesday 24 February 2010 3:34:28 pm

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

Diseño Web Cuba
Web Design Cuba
www.elfosdesign.com

Thursday 25 February 2010 1: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...)

Principal Consultant International Business
Member of the Community Project Board