This site has been archived and you can no longer log in or post new messages. For up-to-date community resources please visit

eZ Community » Forums » Extensions » eZ Flow » why ? and how ?

why ? and how ?

why ? and how ?

Saturday 21 August 2010 5:24:31 pm - 3 replies


I'm working on the second site that contains a layout datatype already, and I still dont get it. I dont get why its usefull. and I dont get how to use it properly. Any tips are welcome. It could also be I missed very important documentation (i feel as if i did - but really, i couldnt find much).

Both these sites had a custom layout, made by a designer. When the user goes to the backend, f.e. to change a 'featured' node on the homepage, the first thing they see is "change layout". They should never change the layout, because the template code would break, because of missing zones. So we'll have to tell them "dont touch that button". Is there any way we can disable / hide the option ?

It would already help if we could say some layouts are only available for certain nodes (not classes, but node_id's), so we can limit their options to just one design for a certain page (would still look strange though. imho, changing the layout is not something that should be in a content management system at all, because its not about managing content, but ok).

The second thing they see is "name" [textfield] and then "add block". The user will think this is what he wants - add something - so we'll have to tell them never to click there either - "you see, a block is part of a zone in a layout and contains nodes." happy.gif Emoticon hm .. can we move that option down to the bottom ? which templates would need to be changed for that ?

Actually, more often than not we dont want them to be able to add, delete or move blocks in a zone at all. The blocks are exactly where they are because of the design of the layout. We only want them to manage a block's content. Is there a way to disable add/deleting/moving/renaming blocks for certain users ? Can we manage that through roles & permissions ? Would the interface gracefully adapt to such settings ?

In some other cases however, we would like them to be able to change the type of the block, for example from "most recent events" to "most reviewed events" or whatever. So the limitations requested above should only apply to certain blocks (so its probably not in roles and permissions but in the block.ini. I havent seen such options).

Obviously, users should only be allowed to use certain types of blocks in certain zones. I just found out that can be done, but only through a hack. Is that correct ?

And now for the big "why?". If you have a custom layout, not designed to be so superflexible that it can contain 'every type of block' in 'every type of layout', why would you use ezflow - and teach your clients 'how not to break your homepage' ?

There seem to be two things we'd miss out on:

1 - the nice manual interaction with a block - adding and removing nodes, mainly. ezobjectrelationbrowse would be another way to do that, but not rotation, timing and such. yet.

2 - cool ezflow blocktypes without interaction (like "twitterblock"blunk.gif Emoticon - is there a standard way to use such blocktypes yourself in templates, without having a node with a layout around ? or perhaps I could use a secret 'shadow' node to keep the ezflow goodies in, which only superadmins may edit ? Is anyone doing that ?

all confused,


Modified on Saturday 21 August 2010 5:26:17 pm by *- pike

Sunday 22 August 2010 3:54:16 am

Hi pike

Reading your case I realized that you will have to customize ez flow.

You can change extension/ezflow/design/ezflow/override/templates/edit/frontpage.tpl and add an if statement like "if user is in group x then x can edit it..." or "if user is in group y then x can add blocks..."

Modified on Sunday 22 August 2010 3:55:31 am by Thiago Campos Viana

Monday 23 August 2010 9:59:50 pm

Thanks for your response.

Indeed, maybe I'm not using ezflow as it was intended. I was thinking .. all I really want is the block's functionality. How hard would it be to write a eZFlowBlock datatype, that represents one block as an attribute ? Using the code already in the ezflow extension, the same design, the same ezm_block and ezm_pool tables, using the same cron job, but just as a separate datatype ? eZFlowBlock already is a PersistentObject ..



Tuesday 24 August 2010 10:27:00 am

Mmm, many different things on this post:

  • being able to prevent editors from adding/removing blocks: would be nice, add a feat. request. You could maybe obtain that result via a custom workflow event
  • being able to prevent editors from switching layouts: just define in zone.ini that your frontpage class has only one layout available for it. Being able to specify it by node can be done by using one different fp class per node, which is doable albeit a chore if you have too many fp objects
  • being able to specify which blocks can be added to which zones: would be nice, add a feat. request

And then the last one: being able to use ezflow block code in a simplified "object/attribute" way.

Before ezflow was released, having 'blocks' which linked to content was a common requirement, and it was often implemented with schemas such as the following:

  1. frontpage obj has one (or more) obj-relations attribute that links to block objects
  2. block objects live in a separate content section
  3. block objects are linked to the content they display via aon obj relation attribute (manual block), or have custom templates that do whatever they need (auto/custom block). This means having a couple of different "block" classes with different template override rules
  4. this can be augmented with grouping block objects into "column" containers. Then many fp objects can link to the same 'column'. If the column is displayed on the side of the web page (ie. outside actual content area), the node tpl for fp passes its related column id to the pagelayout tpl via the persistent variable, and the pagelayout tpl is in charge of fetching the column and displaying it. If the column for a node is undefined, the column of its parent is used etc...

This is all fine and dandy. What you miss is the ajax-based 'add node to block' interface, possibly some fine-grained policy on what obj classes to be able to add to obj-relation attributes, timeline preview and of course the "queueing" of content.

Back on topic: if you want to use the templates of custom blocks (that do everything in the template) in your own code, it's going to be pretty easy. Create an obj with an attribute to store eg. the rss feed url or twitter id, and include the desired block template passing those values to it.

Good luck trying to extract a single existing 'zone' or 'block' to put it in an external datatype though - I fear that besides rewriting code that reads stuff from ezm_block and ezm_pool, you will break the existing logic - most of which is coded in ezflowoperations.php, and is brittle and convoluted at times...


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

36 542 Users on board!

Forums menu

Proudly Developed with from