eZ Community » Forums » Setup & design » Confusing Override System
expandshrink

Confusing Override System

Confusing Override System

Friday 31 August 2007 11:16:18 pm - 14 replies

Okay I'm having troubles understanding the specifics of exactly how to override a template for a specific section. And the documentation as usual seems to just talk in general terms not specifics or examples.

So here's what I am trying to do.

I have a folder called Glossary, under that folder are several articles the title of which is the term the description or body of the article is the definition.

When I user visits the Glossary section I want all the child objects to display but I want them to display differently than child objects in other sections.

After searching for a while I found that the template that decides how these child objects displays is at /design/base/override/templates/line/article.tpl

Okay so I created a new file called
/design/base/override/templates/line/glossary.tpl

And then put the following in my override.ini.append.php file:
[glossary]
Source=line/article.tpl
MatchFile=glossary.tpl
Subdir=templates
Match[node]=345
Match[class]=folder

The node of 345 is the node id of the Glossary Folder. This doesn't work. I've read tons of documentation, trying a plethora of different combinations but nothing works. No where in the documentation does it talk about the fact that I have 4 folders just under design by itself (standard, base, shop_site, admin). And never does it discuss where to put the new template or exact specifics on how to define the override in the append file. Since this is a line item for displaying something on a folder page, do I define the node id of the folder? What about the class?

Why is it the documentation has to be so vague and confusing?

Thanks,
Jason

Saturday 01 September 2007 1:54:31 pm

Hi Jason,

If I understand that you want, you have to override the view full of folder "Glossary"

You create into "full" folder in your design/override/template/, the file folder_glossary.tpl and into "line" folder the file glossary.tpl

and use this role of override :

[glossary_full]
Source=node/view/full.tpl
MatchFile=full/glossary.tpl
Subdir=templates
Match[class_identifier]=folder
Match[section]=<id_of your_section>
[glossary_line]
Source=node/view/line.tpl
MatchFile=line/glossary.tpl
Subdir=templates
Match[class_identifier]=article
Match[section]=<id_of your_section>

You have to clear the cache before see the change.

Cli command line :
php bin/php/ezcache.php --clear-id=override-template

You can find good example here :
http://ez.no/ezpublish/documentation/building_an_ez_publish_site
Good luck.

Modified on Saturday 01 September 2007 2:06:28 pm by St├ęphane Bullier

Wednesday 05 September 2007 1:32:27 am

Finally figured it out. Stephane your assistance helped lead me on the path to figuring it out so thanks,

So the problem was that after reading the article Stephane pointed me to that there are a series of Override templates listed in the EzPublish system itself. Including one for the article line which was more global then the specific one I was creating. What I did was delete the article line override in the system and recreated it inside the override.ini.append.php file along with my specific override listed first naturally. So now I could set the priority properly.

The reason I couldn't get mine listed into the main system and had to do it manually in the override.ini file is because I wanted to use a different set of match criteria and the admin only lets you do a few. So here's my new file:

[glossary_line]
Source=node/view/line.tpl
MatchFile=glossary_line.tpl
Subdir=templates
Match[class_identifier]=article
Match[parent_node]=345

[article_line]
Source=node/view/line.tpl
MatchFile=line/article.tpl
Subdir=templates
Match[class_identifier]=article

As you can see the second listing normally is just listed it in the admin section of templates, but I had to remove it from there and list it here so that I could list it behind my custom one using the "Match[parent_node]" thus allowing me to redesign the article list for all articles under a specific folder.

Whew, the sheer amount of documentation for this system is what seems to be the most confusing of all. Thanks to Stephane and thanks to all members of the forums.

Wednesday 05 September 2007 10:22:19 am

I think you just missed some powerfull features of eZ...

First, you should create your own design rather that complete the "base" one.
eZ use a "fallback" system, that search for a called template in each design of its stack.
This system allow you to just bring your custom templates in a specific design.

Another intersting features is the "sections" one. You can "specialize" a whole subtree by setting a custom section to it.
You just have to go to your admin interface in the "Setup" sheet, to click on "sections" in the left menu, and declare a new one for the "content part".
You can now edit your "Glossary" folder in the content tree, and assign this new section to it using the box in the left bottom section of the edit view.

You can now declare an override that won't depend on a node ID (such an override will be broken if the node change).

As said above, the view you have to override for the folder is the full view.
You should have something like this in your settings/siteacess/xxxxx/over[glossary]

[glossary_full_folder]
Source=node/view/full.tpl
MatchFile=full_folder_glossary.tpl # or rather full/article_glossary.tpl, if you create a full subdirectory in /design/xxxxx/override/templates
Subdir=templates
Match[section]=7 # ID of the section
Match[class]=folder

You can now write your specific glossary templates listing articles childrens.
It means that you should at least have :

...
specific display code
...
{* list all children article nodes *}
{def $children=fetch(content, list, hash ('parent_node_id', $node.node_id,
                                                           'class_filter_type','include',
                                                           'class_filter_array', array('article')  ) ) }

{* loop on children and call for their "line" view *}
{foreach $children as $child}
    {node_view_gui content_node=$child view="line"}
{/foreach}

...
specific display code
...

Now you should override the "line" view for the class article and for your custom section (when you assign a section to a node, all its child will inherit of it)

[glossary_line_article]
Source=node/view/line.tpl
MatchFile=line_article_glossary.tpl # or rather line/article_glossary.tpl, if you create a line subdirectory in /design/xxxxx/override/templates
Subdir=templates
Match[section]=7 # ID of the section
Match[class]=article

Your override work for all articles under your glossary folder, and only for them.

You can also imagine to call for a "custom" view by changing :
{node_view_gui content_node=$child view="line"}
by something like
{node_view_gui content_node=$child view="glossary_line"}

and having an override like this :
Source=node/view/glossary_line.tpl
MatchFile=line_article_glossary.tpl
Subdir=templates
Match[class]=article
(you don't need to match on section because your custom template will only be called by your custom folder template).

This system provide a lot of possibilties, you have many solutions to reach your goal.

Just remember a thing :
When you navigate to a node, eZ will call for it's full view.
The standard call of eZ for a full view template of a node is always "node/view/full.tpl" (this template exists, it's the "default" one).
The purpose of override.ini is to define specific templates that eZ should get instead of default one, when given conditions are matched.

When viewing a node, eZ will browse override.ini files until it find a matching rule for it, so it will search in rules about the template it asks : source=node/view/full.tpl.
The first rule with "Match" conditions filled will be used, so eZ will use the template defined in the MatchFile key instead of the asked source (node/view/full.tpl).
It means that order is slighlty important, don't set your "generic purpose" overrides at the top of override.ini, or eZ won't go further.

When asking for another view than the full one using, for exemple, the display template function node_view_gui ..... view="custom_view", the asked template become "node/view/custom_view.tpl", and it will search for such source in your override.ini files.

You have to know that you don't have only templates for nodes. You can have some for objects and attributes. And more, you don't have only the view mode. You have the "edit" mode too, and several other ones.
If you want to call for the standard edit view of a given attribute, you can use the display function attribute_edit_gui attribute=my_textline_attribute
In this case, eZ will ask for a "content/datatype/edit/ezstring.tpl", and you can build an override rule for it using this template as source.

All is working with exactly the same logic than node/view/full, it's quite powerful if you can understand the basics of this mechanism.

I suggest you to activate the debug mode for your site, and display the "List of used templates". It's quite explicit, showing you for each template used in your page, which is the source called, and what template was provided instead of it, according to overrides.

Modified on Wednesday 05 September 2007 11:01:02 am by Olivier Ouin

Wednesday 05 September 2007 5:12:18 pm

Yeah well what I did ended up breaking the admin none of the article titles would show up after the overrides I put into place. Seems the article line override was overriding everything at that point including the admin section.

Everyone keeps telling me to override the Full page. But honestly the Full page is fine the way it is. The ONLY thing I want to change is each article line item.

Also everyone keeps telling me to make a completely new section for the glossary folder instead of having it a folder, except that I want it to be a sub folder of home, not some where else and have to figure out how to provide some link so that visitors can get there.

The debug mode you mention is pretty spiffy sounding. Don't know how to do that though.

I think in a lot of areas this system is just way to over complicated. Primarily just the documentation is. The program itself isn't once you figure it out on your own without documentation. There are a lot of things that could be explained so much better.

So I'm back to the drawing board again. My Fix doesn't work, and none of the fixes provided work either because they all rely on creating a new section which I don't want, and even if I did do that everyone is talking about overriding the full page, not the line items. The full page doesn't display the line items it calls a different template to format and display the line items.

If anyone has any assistance on that, it would be great help.

Thanks,
Jason

Wednesday 05 September 2007 5:37:23 pm

So I gave in and created a new section called glossary and assigned it to the glossary folder. (Still have no clue why I did this because it provides no benefits). Which then opened a can of worms dealing with permissions, once I got all that straightened out I put this into my override file.

[glossary_line]
Source=node/view/line.tpl
MatchFile=glossary_line.tpl
Subdir=templates
Match[class_identifier]=article
Match[section]=7

Still doesn't work Matching based off of section is still no good. I don't know why we went in to create an unnecessary new section just to try and create an override. No benefits and the overrides still don't work.

Is there ANYONE that has a clear understanding of how override templates work?

Thanks,
Jason

Wednesday 05 September 2007 6:18:01 pm

I think I finally got it. The key to the city I found is DO NOT use the override.ini.append.php file.

If I created the template and put in the override file then first it wouldn't show up at all. But if I went to the design section of the admin I could change the priority since everything added into the override file has the very last priority. But after changing the priority it would work, but all the article names disappeared in the folder listing of the admin for the new glossary. So next I deleted what I placed in the Override file, and only entered it into the design section of the admin and placed the priority on number one, and it works without causing the admin to break.

It seems that if you put it in the override.ini.append.php file that causes it to override the admin but you put it the admin of the system under design. and it only affects the customer side.

Weird, oh well.

Wednesday 05 September 2007 6:43:10 pm

No, unfortunately you did not "get it". The key is not modifying the "base" design but rather creating your own. Then override to your heart's content happy.gif Emoticon

Wednesday 05 September 2007 7:26:52 pm

Um, no I am creating my own. I never said I was modifying base template. And I'm not modifying the base template. For some reason everyone keeps assuming I am modifying the base template, maybe from my orginal post where I mentioned the base. Cause that was where the default template for articles was coming from.

But the whole point of this was not to just change the way all articles listings were displayed, but instead to change just the way article listings were displayed for one folder, called glossary.

Everyone keeps saying I don't get it, because I am modifying the base template. Although I am not modifying the base template. And no one provides any information as to how I can do it differently. All I know is so far if I enter the override definition to the override.ini.append.php file it becomes the very last priority level, so all the broader definitions that are defined first happen and it never reaches mine. If I take and also move the priority up to be first then it will override the customer side and the admin side and break the admin side. Thus in the end I have to define it in the admin and change the priority and not use the override.ini.append.php file. This is the only way the admin will not break. And again the modified template is NOT in the base directory.

Thanks,
Jason

Wednesday 05 September 2007 10:24:25 pm

Maybe that's because you wrote <i>"Okay so I created a new file called /design/base/override/templates/line/glossary.tpl"</i>. And you keep saying that there is other stuff in you override.ini.append.php.

Unless you have got other overrides working, there your override.ini.append.php should be empty. Are you using your own siteaccess?

Anyway, sections provide a lot flexibility, but you can use any combination of override conditions from http://ez.no/doc/ez_publish/techn...ference/template_override_conditions .

There are several ways to get what you want, including overriding the full view of the glossary folder and using a custom view mode for the article children. Or you override the line view for all children of the glossary folder. The result is the same. If you don't like sections, <i>Match[url_alias]=/glossary</i> is what you should be looking at.

Thursday 06 September 2007 4:34:22 pm

Okay yeah that was my first post when I was trying everything to get anything to work. That's not what I have set up now, sorry.

Anyway I guess I really only have one issue left. And it is more of something that I would like to understand. This glossary section is now set up and operating the way I want. But through the use of a section and set up in the design templates of the admin as an override. My Override.ini.append.php file is empty.

So here's the last part that I don't understand.

I created my template file that I want to use to override. I enter it into the override.ini.append.php file and nothing changes. I log into the admin and go to design >> templates and go to the appropriate template. And now at the very bottom is the new override that I created in the override.ini.append.php file. So the reason nothing changed is because the override after adding to the append file had a priority of 24 out of a possible 24, and there were several more global overrides with a higher priority that I assume were getting tagged first.

So now I change that priority to number 1. Now it is working properly. The glossary section from the customer side looks just like I programmed it too. BUT now here's the kicker, now the admin side of the glossary section has all the sub items listed with blank lines as the title. If I edit them the title is there, but just not displaying from the folder view, just blank line after blank line.

So to fix it I (based off of previous recommendations) made the glossary section a "Section" and then since the templates section of the admin allows you to specify the override based off of 3 different criteria (class, section, or node id) then I was able to just define it only there, leave the priority as 1, and remove the entry from the override.ini.append.php file. And now it works from both the customer side and the admin side as I expect it too.

So my biggest question is that, even though in this case I got it to work by making it a section. What good are all those template conditions such as url_alias, or parent_id, or all the other ones. When it seems that if you define any of those in the override.ini.append.php file it will end up just breaking your admin anyway? At least only if you like reading the article name without just remembering that the third blank line is the article about such and such. Naturally I guess the only affects if you are working on something such as line items but still, how would you only get it to override based of the customer website and not the admin panel as well?

Thanks,
Jason

Thursday 06 September 2007 5:38:32 pm

OK, now I can guess what you're problem is: Apparently you are using an override in settings/override/override.ini.append.php when you should be using settings/siteaccess/<your_public_siteaccess>/override.ini.append.php. Maybe the admin interface is messing things up, so you are better off doing the overrides manually with a text editor. The syntax isn't that difficult anyway.

Thursday 06 September 2007 6:28:01 pm

Unfortunately if I only manually set the override in the override.ini.append.php file then the priority is set to LAST. As I've said several times before. Last as in behind all the overrides listed in the admin interface that are NOT listed in the override.ini.append.php file so it's not like I can just move them around.

If I alter the priority in the admin interface AND leave the definition in the override.ini.append.php file then the override will affect both the customer view of that directory as will as the admin view of that directory. Keep in mind that I did not type it into the admin interface under overrides, it appeared there after adding it to the override.ini.append.php file and I only modified the priority otherwise it would never occur because of higher priority article line definitions for the site as a whole.

You are right the syntax is not difficult and I have manually edited it every time with a text editor just fine and with no issues except for the fact that it seems you CANNOT have it listed in the override.ini.append.php and then give it a priority of 1 in the admin interface, or it will affect both the customer view and admin view. Entering it only into the admin interface (with its very limited override matching abilities) and then setting the priority of 1, is the only way it seems to affect ONLY the customer view.

Friday 07 September 2007 9:28:36 am

Modifying something in the admin siteaccess and entering it there is basically the same thing. So don't do that. And please tell us exactly what siteaccesses and designs you use (including which directories under settings/ you use for configuration).

There is something fundamentally wrong with your setup, because what you describe (except for using the admin interface for INI stuff) works perfectly well on my site and others.

Monday 17 September 2007 5:06:21 pm

Just a word about overrides and priorities.

First, you have the /settings/override.ini.
It's the default one (and it's just containing an example), and like all others .ini files of /settings, it should never be altered.

After that, you have override.ini.append.php in each siteaccess (I mean, in /settings/siteaccess/mysite, for example).
This override.ini.append.php will contain override rules for this siteaccess and ONLY this one. It allow you to build some rules specific to one siteaccess.

Third, you will find an override.ini.append.php in the /settings/override directory. This one will contain the GLOBAL override rules, working for every siteaccesses, including admin ones.

You can sometimes find override.ini.append.php in extensions, but it's another story.

Now, let's talk about rules order in override.ini.append.php. eZ run it from top to bottom, so the first matching rule is used by it. So, "exception" rules should always be placed in the beginning of the override.ini.append.php file, or eZ will never reach it, because it will find another matching rule before.

I think your problem with override is just that you are working on /settings/override/override.ini.append.php. If you put override rules on the top of this file, you will make an override for every sites, admin included. If you put your rules in the bottom of this file, it won't be reached by eZ.
You just have to put your specific rules in the override.ini.append.php of your frontoffice siteaccess and all will be okay.

A last thing about sections, it's true that you have some "policy" rules to set to give access to it. Sections interests is to allow to easily specialize a whole subtree and assign it custom user policies, and / or custom design. It's a clean way to do because it avoids to set some node id matches, more rigid in term of administration. But it's not the only way to do it.

Modified on Monday 17 September 2007 5:15:05 pm by Olivier Ouin

expandshrink

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

36 542 Users on board!

Forums menu

Proudly Developed with from