eZ Community » Forums » Developer » The top 3 "Don'ts" of eZ Publish?...

The top 3 "Don'ts" of eZ Publish? Any concepts eZ should let go?

The top 3 "Don'ts" of eZ Publish? Any concepts eZ should let go?

Wednesday 09 February 2011 11:04:50 am - 26 replies


This is the forum part of a discussion started on Twitter.

It started with this question from @andrerom :

"Whats the top 3 "Don'ts" of #ezpublish ? Any concepts we should let go?"

I feel it deserves more than 140 char. So here is the topic.


What i think :

  1. ezxml has too many limitation. We should be able to freely build our pages. Limitation should be an option.
  2. template language : i do not understand why we use this layer. I guess pure php could do the same. No ?
  3. Information collection attributes : i dont know why but i feel it could be better.

Modified on Wednesday 09 February 2011 11:37:12 am by Paul Etienney

Wednesday 09 February 2011 11:22:13 am

Hum troll detected with the point 2. As you're french, you can read these two blog posts and the associated comments :

  1. http://truffo.fr/2010/04/template-ez-publish-en-php/
  2. http://truffo.fr/2009/06/utilite-des-langages-de-templates-en-php/

For the point 1, perhaps you need an HTML datatype instead of eZXML. It's not that complicated to be done. In the past, there have been some contribution when eZOE was not free...

Wednesday 09 February 2011 11:27:54 am

  1. as Damien said, this is quite easy to workaround, but maybe HTML support should exist by default, with a list of allowed/disallowed tags. But overall, ezxml is considered one of ezpublish's strength rather than a limitation, as it makes real multi-channel publishing.
  2. Troll spotted blunk.gif Emoticon But yes, there is a point here, and that point is that in some cases, you don't want the template engine, be it for performances reasons or to reduce the learning curve. On the other hand, our template language is really aging, and if it was more modern, we wouldn't have so many complains about it
  3. yeah, it might be a bit too limited, and not easy enough to use.

Wednesday 09 February 2011 11:45:18 am

About ezxml

You are right, my problem is not really ezxml. It is the html limitation. As Damien said i could use an html datatype but with his solution i loose ezoe.

About template language

I guess it is a multi-thread troll war subject. I am just thinking that the template execution should be lighter. Maybe it just need an upgrade.

Wednesday 09 February 2011 11:48:57 am

By @masev "an advanced role/policy settings (per attribute)".

And create the option to group extensions by folder.

Wednesday 09 February 2011 11:52:37 am

As said on twitter. Note : the order is not really relevant, I want all happy.gif Emoticon

  1. true OOP (Interface / abstract class, ...) for Datatype, template Operators, the front controller, workflow... In fact for every part of the system. For instance, defining a true well documented interface for Datatype would make easier to write a new one. And while at it, totally refactor the way to create template operator, it's currently very painful due to the need to declare it in several places. Don't Repeat Yourself !
  2. an unified cache layer and even an unified file storage system. The idea is to make the system consistent and to be able to use different storage system for different kind of data (memcache, redis, database, filer, hard drive, ...)
  3. a reliable and efficient template engine : this one comes again and again over the years. The current one is buggy, unconsistent, slow and very frustrating to use.

A lots of work happy.gif Emoticon and probably a lots of BC break...


Wednesday 09 February 2011 12:00:59 pm


  1. Module/views: most views end up being spagetti code. As an example, look at the ~1500 lines of mess that is kernel/content/action.php. There needs to be a better concept that allows cleaner code and better code reuse. The MVC framework would probably help a lot.
  2. Information collection: Need a more flexible approach to forms and one which is not tied directly to content classes. Sometimes you want to turn the result of a form into an object, sometimes you want to just send an email. Sometimes you need to do more complicated things like creating multiple objects, custom validation, multi-page forms, etc. Django has a really nice approach to forms: http://docs.djangoproject.com/en/1.2/topics/forms/
  3. Data types: Needlessly time consuming to write, even simple ones. Case in point, ezstring, ~400 lines for a datatype that does nothing but store a single text value + validation. Datatypes also hard codes things like post variable names which makes them very inflexible and they can't be easily tested or reused in other situations where the data might not come from POST.
  4. Bonus #1: Package system: Need a much, much, much better and unified way of getting content in and out of eZ Publish.
  5. Bonus #2: Getting rid of node, section and object ids. Working on bigger sites that typically has at least dev, testing and production environments using auto increment ids is a real pain as they are often not the same on all environments.

Ole M.

Wednesday 09 February 2011 12:02:26 pm

By @masev "an advanced role/policy settings (per attribute)".

And create the option to group extensions by folder.

policy: Discussed before, should be connected to attribute groups so it doesn't get to complex.

extension groups: namespaces could be a soulution, by default use something like ext or ezpxt as namespace an allow additional namespaces with config.php settings.

@damien / @Paul

Template: and thats why ezctemplate was created, its way faster and more consistent. We are aiming at allowing php templates as well, but we don't believe it should be the default as it is not a good thing in large projects with many people with different skill levels involved.. The hurdle is of course to migrate to the new template language. Deprecating (trowing strict errors) on using array sytax for objects and opposite in current engine right now would help, but there are still some other issues like custom operators/functions and so on.

eZXML: Yes it's to limiting, but it does provide extension points and features not available in html. So might be that a strict xhtml5 format with support for custom and embed tags is a way to go. But some wants to move toward docBook which might make it more difficult. Anyway, we want separation of design and content by default to be the case in the future as well, but maybe allow this to be configurable to some extent (pr class attribute preferably).

@Ole Morten:

object/node/section Id's: As of 4.4 you have working remote id's in nodes / objects and section identifier, so not so much of an issue anymore. But please expand if you think it still is.

Modified on Wednesday 09 February 2011 12:13:13 pm by André R

Wednesday 09 February 2011 12:07:04 pm

My 2 pences :

  • We should allow dependencies between content types. For example, if you have an article content type, you should be able to decline it under several kind of content : article about cars and article about boats. It will be more simple to manage, all the common attributes will be in the article class and all the others in their respective class. It surely can be done with what Thiago mentionned.
  • We should allow dependencies between siteaccess. For example, you have your website in english and you create a new siteaccess in french, you have to copy all the siteaccess settings and just change the regional settings. It would be easier just to add the delta between the siteaccess french and english and mentionned that the reference siteaccess is the english one.
  • The override system must be clearer. I cannot count the times I have lost my mind about knowing why settings were not applied... Maybe it can be flexible and you may choose the mecanism to apply regarding to your siteaccess. For example, you may want extension /override settings to be applied for one siteaccess but not for another one.

Good initiative elsewhere.

Wednesday 09 February 2011 12:25:39 pm


Content class inheritance: Yes, the issue would be potential implementation complexity, but it is a good thing to have in this thread

Siteaccess: Easy, add a site concept so siteaccess just contains things specific to the interface settings. Bonus: detach them from siteaccess so you can have generic frontend/backend/mobile siteaccesses and site specific setting in the site concept.

overrride sytem: yes, good point. On this one we lack suggestions on what could be better though. There was one in the past about writing override rules in the top of your override templates, what you lose with that is that you need to add another level of parsing and caching and no single place to see all rules (beside potential gui).

Wednesday 09 February 2011 12:44:20 pm

A big +1 to the form approach Ole described.

Wednesday 09 February 2011 12:57:28 pm

Oh my, yet again one of those "waht's your most wanted feature?" topics.

This is very nice for everybody to let off a bit of steam, but it has been done many times in the past (iirc I started a similar thread in the 4.4-roadmap timeframe), and it can degenerate quickly into an unusable mess.

What we need 1st is a nice tracking system for new features, where users can vote single features up/down, add user stories, cost estimates and so on.

In no particular order I'd want: more interfaces and better inheritance everywhere in php code; complete removal of the leftover include/require calls; a better crud system; moving shop and rss to extensions; a depth limitation in cache block expiry params; cleanup of existing datatypes; better and more pervasive info collectors; many more operations; permissions assigned to operations and not to views (the last two to move existing functionality to json/xml/rest apis); many more workflow events and triggers; simpler workflow event and datatype api; datatypes disconnected from http form fields; content/edit where the object_attribute_id is not needed anymore; ini system where the ordering is default,global,extension,siteaccess; merging the override folder in standard templates folder; remove override.ini altogether and only allow simple override rules (class, section, node_id); a much more complete and resilient packaging system; one-click install of extensions from external repositories with dependency checking; remove class id in favor of identifier; better translation interfaces for both ts files and content in the db (classes, states, etc); cleanup of all kernel views to remove business logic from templates and allow xml/json output; rename things here and there where they make little sense, and many, many more...

Modified on Wednesday 09 February 2011 12:58:37 pm by Gaetano Giunta

Wednesday 09 February 2011 1:05:23 pm

What we need 1st is a nice tracking system for new features, where users can vote single features up/down, add user stories, cost estimates and so on.

+1, this topic can be endless dependig on everybody needs but most needed points need to pointed out !

I think there is lots of existing services that can handle that, for example : http://uservoice.com

Modified on Wednesday 09 February 2011 1:06:43 pm by Matthieu Sévère

Wednesday 09 February 2011 1:15:26 pm

A huge +1 to Gaetano. This site needs a feature voting system.

I am sure this "Here is what i dream about" topic is over discussed. How ever the initial question was more about big concepts and less about features ...

Wednesday 09 February 2011 1:32:06 pm

Well, maybe this did end up as a "wishlist" topic, but if you read the first post, the question was about "don'ts", not wishes blunk.gif Emoticon

Wednesday 09 February 2011 1:33:02 pm

Correct Paul, and the original twitter questions was original about what concepts to remove in favor of something else. A lot of suggestions so far are feature enhancements, not feature kill suggestions.

aka: what Bertrand said happy.gif Emoticon

Modified on Wednesday 09 February 2011 1:33:40 pm by André R

Wednesday 09 February 2011 1:45:15 pm

To stick to the topic.. remove the packaging and go for some type of xml scheme when it comes to deploy. Other large enterprise cms systems make it possible to synch between installations making sure that classes are kept intact. Today it is extremely tedious and not to say at least error prone to have to keep different environments identifical.

Fixing deploy scenario and synch between different installations is something which is important to make sure that ezpublish can truely deserve the title enterprise system.

One way to solve this would be to make sure that a framework runs a set of required implemented methods for each datatype. This would allow both custom as well as ez built datatypes to conform to a deploy scheme which would be extendible as well as reliable.

PS: I am aware that some of you guys have heard this from me before...

Wednesday 09 February 2011 2:11:35 pm

To remove/replace top 3:

1) shop/e-commerce, should be in its own optional extension

2) packaging system (split into a data part and a general application package system)

3) index.php with a hierarchical MVC, possibly calling back to the old one (as in my original projectV idea)


Wednesday 09 February 2011 2:31:12 pm

@Ole Morten:

object/node/section Id's: As of 4.4 you have working remote id's in nodes / objects and section identifier, so not so much of an issue anymore. But please expand if you think it still is.

Can you override templates on remote id? If you can then yes, that does help, although the creating two identical objects in two systems will result in different remote ids so you'd need to mess around in the db to set them to the same. Not optimal, but better than nothing.

Ole M.

Wednesday 09 February 2011 2:49:49 pm

IMO there is no feature which should be removed, but lots of them could be better happy.gif Emoticon

And those are many more then 3.

Modified on Wednesday 09 February 2011 2:50:58 pm by Ivo Lukač

Wednesday 09 February 2011 2:56:06 pm

override using remote_id's; yes. Usefull in cases where you export content from one install and import in another one.

Modified on Wednesday 09 February 2011 3:02:30 pm by André R


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

36 542 Users on board!

Forums menu

Proudly Developed with from