Trouble overriding "Access Denied" template

Friday 01 September 2006 6:11:49 am

I've just bumped into this same issue, and, looking in the forums,
I see that the question has been posed several times but never once
answered.
So here is another attempt:

Dear gurus,
how do you override an error template?

Yes, it's easy to customise the error templates within a siteaccess, and
we're all pretty clear on making that function. But how do you override
the templates in the override.ini file, based on match conditions?
<b>Following does not work</b>

Source=error/kernel/1.tpl
MatchFile=some_folder/some_file.tpl
Subdir=templates
Match[section]=8

But what will?
Anybody?
Kristof?

Andy

Friday 01 September 2006 6:35:52 am

Hi Norman,

thanks, but that's what I meant by allready being clear how to do things
in a customised siteaccess.

I would like to have several version of error/kernel/1.tpl which can be displayed
based on various different match conditions.

Andy

Friday 01 September 2006 7:13:05 am

Norman,

I think we'll need another 20 posts for every scenario to be tested, so
let's try it this way:

Customise your own settings/siteaccess/<whatever>/override.ini.append.php
so that error/kernel/1.tpl can be overridden, and then tell me how you did it.
I'll need to know values for
Source=
MatchFile=
Match[]=

As the original poster and I have both written, the seemingly obvious
configuration does not work and we would like to be shown the
correct configuration.
All we are trying to do is to display a different version of error/kernel/1.tpl for
each section of our sites, and we're not having any luck.

Really appreciate the help.

Andy

Friday 01 September 2006 9:28:20 am

@Norman:

We generally recommend the following structure:

If you have an overriderule in override.ini:
put the template in override/templates/..

If you do not have a rule in override.ini
put the template in templates/..

This was the intention of the system (as far as i know). This makes it easier to find destinguish between templates that are always used (fallbacks) and templates that are used sometimes (overrides). Both will however work.

If you don't have any override-rules

@Andrew:

The templates which support override conditions, and which conditions are available are listed here:

http://ez.no/doc/ez_publish/technical_manual/3_8/reference/template_override_conditions

If you run:

grep -i "setvariable" kernel/error/view.php

You will see all the variables that are passed to the templates. (Look in the code, there are some if statements there)

Kristian

http://ez.no/ez_publish/documenta...tricks/show_which_templates_are_used
http://ez.no/doc/ez_publish/techn...te_operators/miscellaneous/attribute

Monday 04 September 2006 1:45:52 am

The templates fetched by the kernel/error view will have these design keys for usage in override.ini.append:

error_type (I think this is always <i>kernel</i> for the standard modules)
error_number

independent eZ Publish developer and service provider | http://blog.coomanskristof.be | http://ezpedia.org

Monday 04 September 2006 6:24:26 am

Kristian, Kristof, Norman,

thank you all for your assistance in this, and for your helpful comments.
I'd like to sumarize what I've learned/discoverd, please one of you jump in
if I'm mistaken about something.

---Templates used/called by the kernel/error view do indeed have a couple
design keys that could be used for override via override.ini(.append.php).
For all intents and purposes, however, this is not a viable method of displaying
custom error templates because there are no usable match conditions available
in/for that particular view.

---kernel/error/view.php passes very (very) little useful information to the various
error_code templates, so there is nothing natively available in these templates to
use for doing things like -for example- a switch/case on section.

--If, for example, our goal is to provide a custom login page for each defined section
of our public site, our most (only?) useful tack is to modify/override error/kernel/1.tpl
and to use our own control structures to provide alternate displays. From within this template there is no direct access to the section being called. Instead, we must fetch the node and get the section_id with $node.object.section_id|int().
A little dance is required, though, to fetch the node, because the only apparent information
on the node being accessed is at the end of the string in the variable $redirect_uri.

Of course, it would be much cleaner and easier to alter kernel/error/view.php to pass the
section_id to the error template, but then this code would have to be protected to survive version upgrades.

Andy