Ini settings override order

Saturday 02 January 2010 1:07:27 pm

I am confused about the order in which configuration settings are overridden. I know there are many topics on this, i.e. in http://share.ez.no/forums/suggestions/.ini-priority-vs.-extension-settings the following order is mentioned:

settings
siteaccess
extension
extension-siteaccess
extension-siteaccess-override
extension-override
override

This topic still remain unclear, and is not properly covered in the docs. Is this the ini priority eZ 4.2 is using?

I tried to override some ezflow block settings by adding a file ezflow/override/block.ini.append.php. I also tried to add this file to an activeAccessExtension. In both cases, the settings from ezflow (extension) were not overridden (by extension-override and extension-siteaccess-override), but according to above priority, they should.

Could someone clarify this? Thanks!

eZ Publish certified developer
http://auth.ez.no/certification/verify/392313

Sunday 03 January 2010 5:37:35 pm

This is my understanding, somebody please correct me if I am wrong.

Ini settings are applied in this order:

• /settings/ *.ini When applying settings, this is the first place searched, about 50 files, covering about 50 things that eZ Publish does. Specific sitewide settings like where to store files, permissions settings on files, image handlers,so on. If there are no additions or corrections in the next levels, these become the final settings. Setup.ini typically begins and ends here. Site.ini typically begins here and is altered at each new step. Systematically reviewing [SiteAccessSettings] in each site.ini file at each level is educational.
• /settings/siteaccess/<named siteaccess>/ These settings will add to or override the above files, to set more specific site parameters. Usually a site.ini.append.php, and usually a few alterations to the [SiteAccessSettings] configuration.
• /settings/override/ - a final place to potentially make changes sitewide again. Why again, if already set in step one? Applying a universal setting to all the siteaccess settings from step two is one reason. The ability to turn on and off a complete siteaccess is another. Reviewing the [SiteAccessSettings] in the site.ini.append.php file at this level gives some idea of the possibilities.

More at http://www.webportalmaster.com/index.php/eng/eZ/Advanced/eZ-override-which-settings

Doug Brethower
Apple Certified Technical Consultant, Southwest, MO USA
http://share.ez.no/directory/companies/lakedata.net

Tuesday 05 January 2010 2:28:17 pm

Hi everyone, yes this sure is a complex issue and has been brought up (lack of authoratitive docs) many times before. I am currently writing a how-to for ez.no who's aim is to helpfully explain how to get 2 or more custom design-extensions to overrride ezwebin's templates and CSS. Currently, well documented methods only allow you to override one of templates *or* CSS, not *both*.

In the article I list the order of the .ini file "cascade" (robbed from CSS parlance) and .tpl file location "cascade" also.

Through experimentation, the complete order seems to be:

settings/*.ini
settings/<siteaccess>/*.ini.append.php
extension/<design-name>/settings/*.ini.append.php
settings/override/*.ini.append.php
extension/<design-name>/settings/<siteaccess>/<design-name>/*.ini.append.php

However I have not played around with the order of the last two, I took this from an existing article on ez.no (linked below) intuitively you would think it should be the other way around - that-is - settings/override/*.ini.append.php would come after extension/<design-name>/settings/<siteaccess>/<design-name>/*.ini.append.php

See the following for more info

http://issues.ez.no/12939
http://ez.no/doc/ez_publish/technical_manual/4_x/templates/the_template_override_system
http://ez.no/doc/ez_publish/technical_manual/4_x/templates/the_template_override_system/template_override_example
http://ez.no/doc/ez_publish/technical_manual/4_x/reference/template_override_conditions

Cheers
Russ

Russell Michell, Wellington, New Zealand.
We're building! http://www.theruss.com/blog/
I'm on Twitter: http://twitter.com/therussdotcom

Believe nothing, consider everything.

Monday 11 January 2010 9:24:45 am

So,

After a fruitful discussion with Patrick (Allaert) and Bertrand (Dunogier), here is the precedence order of the INI files and their overrides (that means the list above is sorted by increasing precedence capacity) :

1. settings/*.ini
2. extension/<extension_name>/settings/siteaccess/<siteaccess_name>/*.ini.append.php
3. settings/siteaccess/<siteaccess_name>/*.ini.append.php
4. extension/<extension_name>/settings/*.ini.append.php
5. settings/override/*.ini.append.php

Hope it helps!

--
Nicolas Pastorino
Director Community - eZ
Member of the Community Project Board

eZ Publish Community on twitter: http://twitter.com/ezcommunity

t : http://twitter.com/jeanvoye
G+ : http://plus.tl/jeanvoye

Monday 26 April 2010 3:19:09 am

This is correct, ONLY when you load the extension with the ActiveExtensions settings. However, the rules change if you load it with ActiveAccessExtensions.

If the extension is loaded with ActiveAccessExtensions, nr 3. and 4. switch places, and you are able to overwrite extension settings in the siteaccess settings!

I don't know if this is intended, but I've done a lot of testing on this now, as I had some strange results, so I'm pretty sure this is how it works.

Monday 26 April 2010 5:36:41 am

First, I installed the 100% standard ezflow package.

Then I added a custom setting in site.ini.

[TestSettings]
testvar=testval

And put this in both extension / ezflow / settings / site.ini and settings / siteaccess / ezflow_site / site.ini

Then I logged into admin, cleared the cache (the hard way with rm -rf on all cache directories AND through the admin UI) and checked the value. The value was fetched from extension:ezflow.

Then I removed the setting ActiveExtensions[]=ezflow from settings / override / site.ini and put the following in settings / siteaccess / ezflow_site / site.ini

[ExtensionSettings]
ActiveAccessExtensions[]
ActiveAccessExtensions[]=ezflow

Then I cleared the cache again, and checked the value. Now it was fetched from placement siteaccess.

To make sure the value was loaded, I removed the testvar from settings / siteaccess / ezflow_site / site.ini and checked the value again. Voila, the value fell back to placement extension:ezflow.

PHP version:

PHP 5.2.6-1+lenny8 with Suhosin-Patch 0.9.6.2 (cli) (built: Mar 14 2010 08:14:04)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans

Thursday 09 September 2010 9:51:16 am

Hi Nicolas,

Sorry to bring this up, but I'm a bit confused over your answer : to what use can the "extension siteaccess settings" be put to if they have such a low precedence ?

Let's take an exemple : I get a third-party / official extension (for instance : ezjscore) and I activate it via ActiveExtensions in settings/override/site.ini .

There's a good chance that the extension developers didn't know anything about my project and its siteaccess names, right ?
So obviously, the ability to use "extension siteaccess settings" is supposed to be a feature oriented towards the end user / developper, to enable him to override the extension's default settings, for a given siteaccess of its own project.
Obviously, with such a load order / order of precedence, I can't do it there.

Neither can I do it within a siteaccess' settings : either I change directly the extension default settings or I use a global override.
So I can't really change an extension's setting *only* for a given siteaccess, can I ?

PS : all of this is purely theorical