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 » Developer » Template overriding by location in...

Template overriding by location in legacy stack

Template overriding by location in legacy stack

Thursday 21 November 2013 1:33:48 am - 1 reply

Hi all

I've been using a technique, that enables me to override the template used for a specific view, depending on the subtree location of the content that is being rendered. I really like this solution, therefore I wish to share it with you. Maybe there's a flaw in it that I have not noticed. I'd be glad if you pointed it out.

Picture the following:

On the root of a content structure we have two folders: Location A (node_id:101) and Location B (node_id:102). Below each of these locations we have an extensive net of object containers, and scattered through this net we have several instances of objects of class X.

Our goal is to render lists of class_X objects anywhere in the site (a list of products, at the end of all pages, for instance). But we wish the objects to be rendered one way if we're browsing within Location A, and a different way when the context is Location B.

For the sake of the example, we'll define that creating specific sections for each tree is not feasible, and the content is translated into different languages, therefore none of the template override conditions seem to respond to my needs. There's no condition to override by subtree or path. But after some thinking, I realized there's no need to.

Here's how I end up doing it:

in pagelayout (or wherever I need to display my content), I render them by using a custom named view

{node_view_gui view=cascade_override content_node=$node_item original_node=$node_item}

 The template for node/view/cascade_override.tpl goes like this

{if ne($node.node_id,2)}
  {node_view_gui view=cascade_override content_node=$node.parent original_node=$original_node}

Then I setup my overrides at the top level where I wish


 Then I only need to define each design in location_a.tpl and location_b.tpl

<h1>This is beneath location A</h1>
{* do whatever with $original_node content *}
<h1>This is beneath location B</h1>
{* do whatever with $original_node content *}

The trick here is in default cascade_override.tpl. It will be called recursively (using the current node's parent as reference) until the node_id that actually defines the design is reached.

The test for node_id=2, in order to stop the iteration, might not be needed, but I often ran into maximum nesting being reached (as often as I messed up and failed in the node overriding matchers)

Like I said, I've used this technique often, and so far I have not ran into any constraints with it.

On occasions, I've even combined this with the class_identifier matching of content.

And here went my two cents. Comments are very welcomed




Modified on Thursday 21 November 2013 10:35:11 am by Io Sol Inf

Thursday 21 November 2013 10:55:13 am

I've edited the above to fix some minor errors.

I also like to add that, although I started the cascade overriding by directly referencing the custom view, there's no reason why this cannot be used to override an already existing template.

Say that you wish to override line view for objects of type file, for instance:

Start by creating the line/file.tpl override

 {node_view_gui view=cascade_override content_node=$node_item original_node=$node_item}

 Then include the override in ini


Since we've already implemented the cascade mechanism, the design will fall back naturally.


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

36 542 Users on board!

Forums menu

Proudly Developed with from