eZ Community » Forums » Setup & design » Ini settings override order
expandshrink

Ini settings override order

Ini settings override order

Saturday 02 January 2010 10:07:27 pm - 13 replies

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/suggest....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!

Sunday 03 January 2010 7:54:38 pm

Hi Sander,

I wnt through some forum topics including http://share.ez.no/forums/suggest....-extension-settings/%28offset%29/20 but could not find a final statement to conclude any clear order for the setting files. I also went through the release notes back to 4.0.1. but there is no mention about the patch Andre worked on in 2008.

I'll ask someone else from the eZ Share team about this, he might know more. This will hopefully get you an answer fast.

Regards Robin

Monday 04 January 2010 2:37:35 am

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/in.../Advanced/eZ-override-which-settings

Monday 04 January 2010 11:12:08 am

Thanks Robin, I think this is an important issue to clarify, saving hours of frustration for developers maintaining complicated sites with many extensions. For now I've put the settings in a global extension (placed in ActiveExtensions[]) instead.

Doug: thanks for your reply, but this overview is incomplete since it does not take extensions into account. Clean separation of functionality (and it's settings) by using extensions is vital for maintaining complicated sites.

Tuesday 05 January 2010 11: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/techn...mplates/the_template_override_system
http://ez.no/doc/ez_publish/techn...ide_system/template_override_example
http://ez.no/doc/ez_publish/techn...ference/template_override_conditions

Cheers
Russ

Friday 08 January 2010 9:31:31 am

Hi all,

Nicolas, who is both part of the eZ Crew and Community Manager, is following up on this so hopefully the issue with the ini order will be clarified with regards to it's current state.

Regards Robin

Monday 11 January 2010 6:24:45 pm

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!

Sunday 17 January 2010 11:12:18 am

Just got back from the snow. Thanks for sorting this out guys!

Monday 26 April 2010 12:19:09 pm

  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

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 1:46:01 pm

Hi Peter

Your reply surprises me... Can you please give us your test procedure and your version of PHP please ?

Monday 26 April 2010 2:36:41 pm

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

Modified on Monday 26 April 2010 2:37:59 pm by Peter Rudolfsen

Monday 26 April 2010 6:14:35 pm

It's nothing wrong with his setup, ini override directories are prepended as eZ Publish is loaded, and it loads it in that order, extensions (ActiveExtensions) -> siteacess -> extensions (ActiveAccessExtensions).

See this comment for full example: http://share.ez.no/forums/suggestions/.ini-priority-vs.-extension-settings#comment53542

Modified on Monday 26 April 2010 6:24:08 pm by André R

Thursday 09 September 2010 6:51:16 pm

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

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

Thursday 09 September 2010 7:16:17 pm

Hi Richard,

You are right, with the load-order proposed above, the described example can not function. This means that, should we want to follow the all-in-extension-as-long-as-we-can paradigm, if we want to override ezjscore's settings (placed in extension/ezjscore/settings/blah.ini), we will have to do it from a global setting override in our project extension, eg : extension/my_project/settings/blah.ini.append.php. However, the extension load order matters here, and will fortunately be tweakable from Fuji on ( http://github.com/ezsystems/ezpub.../features/4.4/extension_ordering.txt ).

If we continue exploring the case, you may object that this solution can not be applied to one given siteaccess. How about using the ActiveAccessExtension directive ? We can imagine building almost-dummy extensions which only override settings (hence only contain the settings directory), which we'd enable only for a specific siteaccess. This somehow upgrades rank 2 (in the order quoted in your post) to rank 4.5.

Looking forward to reading thoughts on this,
Cheers !

Modified on Thursday 09 September 2010 7:17:40 pm by Nicolas Pastorino

expandshrink

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

36 542 Users on board!

Forums menu

Proudly Developed with from