This site has been archived. To learn more about our current products Ibexa Content, Ibexa Experience, Ibexa Commerce head over to the Ibexa Developer Portal

eZ Community » Forums » eZ Publish 5 Platform » include old templates, from where ?
expandshrink

include old templates, from where ?

include old templates, from where ?

Tuesday 23 July 2013 11:02:26 am - 18 replies

Hi, this should be easy but I can't figure it out:

I would like to include a legacy template with

 {% include "designomg.gif Emoticonld_template.tpl" with {"someVar": "someValue"} %}

what is the full path of old_template.tpl  (assuming the whole installation is in '/var/www/ezp', for instance) ?

I ran "find -type d -exec bash -c "echo This is \'{}\' > {}/old_template.tpl" \;" to create a file in every directory but still got nothing.

The fact that it silently fails without outputting or logging anything when it does not find the file is not helping.

Tuesday 23 July 2013 11:13:13 am

When you do a legacy include, it boils down to the legacy kernel and entirely delegates the loading to it. Hence the legacy kernel will try to load old_template.tpl from all available locations in ezpublish_legacy/:

  • design/<some_design>/templates/old_template.tpl
  • extension/<some_extension>/design/<some_design>/templates/old_template.tpl

It of course depends on how the legacy kernel is configured, in particular regarding the fallback design list...

Hope this helps

Tuesday 23 July 2013 12:14:49 pm

Quote from Jérôme Vieilledent :

...

It of course depends on how the legacy kernel is configured, in particular regarding the fallback design list...

Hope this helps

 thank you for the quick reply Jerome, is there some documentation on how the fallback design list works ?

 I created a 'notes.tpl' file in every directory and found that:

  • {% include 'notes.tpl' %} uses ./vendor/symfony/symfony/src/Symfony/Bridge/Twig/Resources/views/Form/notes.tpl (!!) as a TWIG template
  • {% include 'design:notes.tpl' %} does not include anything

maybe I am missing some directory. What is the meaning of the "design:" token ? Can something else be used there ?

I am working on a fresh 2013.5 installation with ezdemo_site_clean.

 

Thanks

Thursday 25 July 2013 1:56:25 pm

The "template fallback system" of yore is documented at http://doc.ez.no/eZ-Publish/Technical-manual/4.x/Templates/Template-basics/System-templates and neighboring pages. One of the bright ideas of eZ4 which we will in the future port to eZ5, as far as I wish.

As for usage of "design:" it is mandatory for ez4 code, and really has little value (there is only one alternative token you can youse instead of it, and it never is unless by some crazy code). So for ez5 it was removed.

Of course it would be nice if both ez4 would work without the "design:" prefix and eZ5 would work with it, but it's just a minor nuisance

Friday 13 September 2013 1:46:31 pm

I still do not understand:

suppose I have, amongst others, the two templates

  • extensions/myext/design/user/templates/info.tpl
  • extensions/myext/design/product/templates/info.tpl

how can I include the info.tpl for the user ?

how can I include the info.tpl for the product ?

Friday 13 September 2013 2:36:56 pm

Hi Francesco

I think you have an issue in your folder structure here... You should probably have:

  • extensions/myext/design/<my_main_design>/templates/user/info.tpl
  • extensions/myext/design/<my_main_desing>/templates/product/info.tpl

Then, in your Twig template:

{% include "design:user/info.tpl" %}
 
{% include "design:product/info.tpl" %} 

Friday 13 September 2013 3:24:20 pm

Quote from Jérôme Vieilledent :

Hi Francesco

I think you have an issue in your folder structure here... You should probably have:

  • extensions/myext/design/<my_main_design>/templates/user/info.tpl
  • extensions/myext/design/<my_main_desing>/templates/product/info.tpl

Then, in your Twig template:

{% include "design:user/info.tpl" %}
 
{% include "design:product/info.tpl" %} 

Sorry about the confusion, in my example "user" and "product" were meant to be two different (fictitious) extensions. It should have been:

  1. extensions/user/design/user/templates/info.tpl
  2. extensions/product/design/product/templates/info.tpl

I am calling the {%include ...%} from a template in an EZ5 bundle. I would like to include an arbitrary EZ4 template belonging to one of our EZ4 extensions. Is that possible ? How ?

How does 

{% include "design:user/info.tpl" %}

know to take the template from "myext/design/<main_design>" instead of "my_other_ext/design/<main design>" ?

I tried {% included "design:extensions/user/design/user/templates/info.tpl" %} without any luck.

Tuesday 17 September 2013 2:55:26 pm

I can only confirm Jerôme's statement. Including old templates works fine.

There is no need to give the full path to the extension, as the normal design inheritance from eZ Legacy is used. So you should make sure

  • that your site accesses are correctly listed in ezpublish.yml
  • that you have a ezpublish_legacy/settings/siteaccess/your_siteaccess folder containing a site.ini.append.php (extension/myext/settings/siteaccess/your_siteaccess works as well) for each site access
  • that your site access'  site.ini.append.php contains someting like this:
[DesignSettings]
SiteDesign=your_design
AdditionalSiteDesignList[]
AdditionalSiteDesignList[]=ezdemo

Hope this helps.

Modified on Tuesday 17 September 2013 2:56:31 pm by Donat Fritschy

Tuesday 17 September 2013 3:29:47 pm

Hi

Actually, there is another way of including templates, by directly specifying their path:

{% include "file:extension/my_extension/design/my_design/templates/user/info.tpl" %}

Please note the file: replacing design: blunk.gif Emoticon.

Tuesday 17 September 2013 4:03:58 pm

Quote from Jérôme Vieilledent :

Hi

Actually, there is another way of including templates, by directly specifying their path:

{% include "file:extension/my_extension/design/my_design/templates/user/info.tpl" %}

Please note the file: replacing design: blunk.gif Emoticon.

Thanks! This I understand, and it works too!

Tuesday 17 September 2013 4:24:32 pm

Quote from Donat Fritschy :
Hope this helps.

Hi Donat, thank you very much for taking the time to reply.

The last reply for Jerome solves my problem and I must confess that I still do not understand your answer and all the others:

The {% include ... %} is in a template in an ez5 bundle. Bundles have no notion of ez4 extensions or design. The legacy core has no notion of ez5 bundles. So it seems to me that the legacy inheritance rules have only the name "info.tpl" to go by and that is not enough to decide whether to take the template from an extension rather than another.

Tuesday 17 September 2013 4:43:38 pm

Quote from Francesco Nardone :

The {% include ... %} is in a template in an ez5 bundle. Bundles have no notion of ez4 extensions or design. The legacy core has no notion of ez5 bundles. So it seems to me that the legacy inheritance rules have only the name "info.tpl" to go by and that is not enough to decide whether to take the template from an extension rather than another.

When you include a legacy template, the legacy kernel is booted to render it. Hence legacy template overrides will be applied.

Thursday 19 September 2013 10:46:38 am

Quote from Jérôme Vieilledent :
Quote from Francesco Nardone :

When you include a legacy template, the legacy kernel is booted to render it. Hence legacy template overrides will be applied.

Well, believe or not, I understood that. What I don't get is how.

Here's what (I think) happens in the legacy stack:

  • I have two extensions: car and person
  • From the url "example.com/car/info" ez4 knows to go to the car module which is in the car extension.
  • The car module knows to execute its own info.php script
  • The info.php script does "$Result['content'] = $tpl->fetch('design:info.tpl');" which uses the info.tpl from "extensions/car" etc. 
  • From the url "example.com/person/show" ez4 knows to go to the person module
  • The person module knows to execute its own show.php script
  • The show.php script does "$Result['content'] = $tpl->fetch('design:info.tpl');" which uses the info.tpl from "extensions/person" etc. 

Now, if in a bundle template I do:

{% include "info.tpl" with {name: "Citröen BX"} %}

I cannot see how the legacy kernel can reproduce the logic above without an url and without executing info.php and/or show.php.

Thursday 19 September 2013 10:54:11 am

From the example you're giving, your legacy module actually uses the template override system.

You should maybe read (or re-read) this: http://doc.ez.no/eZ-Publish/Technical-manual/4.x/Concepts-and-basics/Designs/Design-combinations blunk.gif Emoticon

Thursday 19 September 2013 12:26:35 pm

Thank you for your perseverance Jerome, I read that page a couple more times and I feel that I am getting closer to understanding. Unfortunately extensions are not mentioned there.
Should I assume that extensions do not have their own namespace for templates and it would be silly to have two templates

extensions/car/design/mydesign/templates/chief/info.tpl

and

extensions/person/design/mydesign/templates/chief/info.tpl

because, since they are in the same 'mydesign' design, wherever I do "$tpl->fetch('design:chief/info.tpl');" or "{% include 'design:chief/info.tpl' %}" I will always get the same one (which one ?).

Is that correct ?

Thursday 19 September 2013 1:08:46 pm

designs are designs, no matter if they are in extension or not.

Only additional factor extensions make to the equation is that when multiple extensions adds template to same design, like "admin" or "standard", then extension load ordering kicks into relevance.
For your own sanity, it is recommended to add your own design which has higher priority then the designs you extend blunk.gif Emoticon 

There are other threads in this forum which explain template load ordering when using designs in more depth, this concept in legacy has worked more or less the same since it was introduced in eZ Publish 3.x.

Modified on Thursday 19 September 2013 1:10:20 pm by André R

Thursday 19 September 2013 1:09:40 pm

Correct: extensions do not have their own namespaces for templates.

In fact this is by design: from the POV of the CMS, when you specify you want template "xxx.tpl", or "yyy/zzz/www.tpl", the system does not care

- if it is in design A or design B

- if it is in found inside the main /design/ZZZ/templates folder, or inside an exetsnion design folder /extension/WWW/design/ZZZ/templates

There are rules applied to decide which template is used, when many files with the same "logical template name" are found on disk. For extension, this depends on ext. ordering, which is decided by extensions declaring their extensions in the extension.xml file. For designs, it depends on the settings in site.ini[DesignSettings]

What this system gives you is:

- great power and flexibility: extension B can change a template which is originally provided by ext. A just by knowing its name and making sure it is loaded first (something I miss in Sf).

Also you can have different siteaccess using the same design as base, and an extra design on top, which differs. You will have 90% of templates in the base design, and 10% in the per-siteaccess ones

- some headaches to find which templates are used to render a page. Debug mode with template list at bottom of your page is your friend

Thursday 19 September 2013 1:14:17 pm

The template override logic (as well as the loading of INI files) is a well kept secret to make sure eZ Publish is mastered only by a few selected gurus who make a lot of money out of it blunk.gif Emoticon

To be serious - the template override mechanism is a very powerful mechanism, especially when dealing with extensions. If for instance you do not like the article template from the ezdemo extension, simply create your own template in your extension with the same name and location in the tree, and it will override the on in the demo design.

But how is decided which template is invoked? The key to this lies in the site.ini.append.php of your site acccess(es). As pointed out earlier:

 [DesignSettings]
SiteDesign=your_design
AdditionalSiteDesignList[]
AdditionalSiteDesignList[]=ezdemo

This means, the system first looks for a template in your_design, and if it doesn't find one, goes through all the designs in the AdditionalDesignList array until it finds one.

To be honest, I can't tell wether it is silly to have the same design name in different extensions (we always create unique design names for our projects) - but as this settings block goes for design and not extension names, there could be a problem.

Modified on Thursday 19 September 2013 1:16:32 pm by Donat Fritschy

Thursday 19 September 2013 1:17:18 pm

And to give some plain-words advice:

- when adding a new module+view, name your template modulename/viewname.tpl. It makes everyone's life much easier

- when adding a new module+view, you usually use a unique module name. This means that the logical template name is also unique without special needs - it will not conflict with other extensions.

- If your view is meant to be used on many sites, it is a good idea to put your new template in extension/myextension/design/standard/modulename/viewname.tpl. Since "standard" design is used by every eZ site, this means your template will be available everywhere

- take care about design-fallback-system and design-override: 2 different concepts are at play here

- if your new templates are meant to be used as part of pagelayout, their name is usually parts/xxx.tpl

- if your new templates are meant to be used for displaying content (not a module-view), then the override system should probably be used, or a custom view-mode for content. In both cases, this dictates where you should put your templates

expandshrink

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

36 542 Users on board!

Forums menu

Proudly Developed with from