eZ Community » Forums » Suggestions » *.ini priority vs. extension settings

*.ini priority vs. extension settings

*.ini priority vs. extension settings

Tuesday 19 February 2008 6:33:47 pm - 39 replies

Just looking at the priority that the settings files follow:

Gunnstein wrote at http://ez.no/doc/ez_publish/techn...basics/configuration/site_management

1. Default configuration settings (/settings/*.ini)
2. Active extension siteaccesses (/extension/*/settings/siteaccess/[name_of_siteaccess]/*.ini.append.php)
3. Siteaccesses (/settings/siteaccess/[name_of_siteaccess]/*.ini.append.php)
4. Active extensions (/extension/*/settings/*.ini.append.php)
5. Global overrides (/settings/override/*.ini.append.php)

It seems like the main/siteaccess/override model for settings files and its advantages weren't introduced to extensions' engine. Here's some issues I see:

1) Let's call it <b>convenience and flexibility</b>: One great feature of the three-step system (and - as far as I understand - one of its key functions) is that we have untouched original *.ini files with all/default settings present, the rest are siteaccess-dedicated or global overrides. This is a great in case of any upgrades, modifications, or simply for reference. I don't see this possibility for extension settings (unless we move the overrides of custom *ini files to the global overrides, but that isn't that convenient we have 10 or 20 extensions...).

2) <b>Security</b>: This actually results from the above. If there is no general override, all your general custom settings will most probably be kept in the main *.ini file. That may include project-dedicated values, passwords, options, etc. The file should then always be called *.ini.append.php, which is easy to forget about.

3) <b>Rules</b>: While with the general settings siteaccesses overrule general files and global overrides overrule all of them, the rules seem less clear with extension settings... that includes both the priorities and the names (look at the security point).

Here's what it could look like (just a quick idea):

1. Default settings [/settings/*.ini]
2. Default extension settings [/extension/EXT/settings/*.ini] <i>(only for custom *.ini files)</i>
3. Extension siteaccesses [/extension/EXT/settings/siteaccess/SITEACCESS/*.ini.append.php]
4. Siteaccesses [/settings/siteaccess/SITEACCESS/*.ini.append.php]
5. Extension overrides [/extension/EXT/settings/override/*.ini.append.php] <i>(for custom *.ini files as well as other *.ini files)</i>
6. Global overrides [/settings/override/*.ini.append.php]

Any other or similar thoughts?

Friday 25 July 2008 1:03:59 pm

Autoload is a different issue, so I won't do anything about it in this patch.

One more question, do you cache any of the init stuff here? aka:
* finding extension / siteaccess override dirs for ezini
* generating extension autoload classes on page load

If so, how?

Friday 25 July 2008 1:58:21 pm

Hi André,

what is about the extension-override setting which is only activated if a siteaccess of an extension is active?
If i understand it right your patch reads all extension-overrides of all extensions. So i can't have seperate overrides for a extension which includes siteaccesses.
May be we need a different name for this e.g. extension-siteaccess-override.

My goal is to have several site extensions in one ez installation which includes all siteaccesses for a project and have their own override which is only activated if a siteaccess is active.

Do you understand this?

- ezwebin
-- settings/override
- site_project1
-- settings/siteaccess-override
- site_project2
-- settings/siteaccess-override
- site_project3


Friday 25 July 2008 2:30:56 pm

No, I'm afraid I don't.

Friday 25 July 2008 3:23:30 pm

Hi André,

i try to explain it with other words.
We have an ez installation with a lot of different ez projects ( different db ).
Every Project with all related siteaccess + design are located in an extension called 'site_projectname'. These site exensions are activated in the global site.ini with 'ActiveExtensions'.
You have to activate these exensions globaly because they have siteaccesses inside.
If you have a lot of siteaccesses in one of these site_extensions you have to put all the same ini settings like site.ini.appen.php ( db parameters ), image.ini.append.php ... in every siteaccess.
A new ini location which overrides all settings from the extension-siteaccesses of a site_extension is very usefull. So you put all equal settings in the extension-siteaccess-override. This new ini location is only active for one !!!! site_extension. So every site_extension has is own 'override'.

It this better to understand?

- site_project1
- site_project2
- site_project3
-- settings
---- override ( is used if extension is active @patch  André)
---- siteaccess-override ( new ini location only activated if a siteaccess of this extension is active)
---- siteaccess
------- project3_user
------- project3_admin

Modified on Friday 25 July 2008 3:24:08 pm by Felix Woldt

Friday 25 July 2008 4:08:01 pm

You wouldn't need that if you had a simple siteaccess in the settings folder with a site.ini with only a AciveAccessExtension (or ActiveExtension with the patch ) that enabled the extension. So all the accesses within one project activates on specific project extension. (and with the patch, this extension can then load all the other extensions it needs).

One reason I'm (personally) not to open to add another settings layer is that each layer you add will add more overhead, this is especially true on win / os x / nfs / nas / san where stat calls are more expensive (then for instance linux with ext2/3), this is platforms we are currently aiming more at then before.

To fix the overhead problem, one would have to either implement some cache for it (override dirs) or change settings backed from flat files to database (sqlite for instance).

Friday 25 July 2008 4:26:41 pm

Hi André,

i can't agree with you. I only want to have 1 extension with all project settings ( siteaccess / design ). I don't want to have a seperate extension for settings. Remember you have a ez installation with 40 site extensions ( we currently have ).
The overhead is not so big only 1 ini location is parsed more at runtime!!!

We introduce this patch, because it is very usefull for multi site hosting.

Please think about it again.


Friday 25 July 2008 6:15:58 pm

Hi André

I think that in this discussion one major point has been neglected. Many of our sites are multi-lingual, with four or more languages and accordingly at least the same number of site accesses with practically identical settings (e.g. database, mail addresses etc). Even before learning about Felix' multi-site hosting concept I have wished there would be less redundancy in these so tightly coupled INI settings.

As I understand it, neither <i>extension-siteaccess</i> nor <i>extension-override</i> address this aspect. Therefore I would strongly support Felix' demand for a INI location which is <b>only loaded when a site access of this extension is active</b>.

Best regards

Friday 08 August 2008 9:52:34 pm

Ok you two, as I mentioned a cache would need to be implemented first, and so I did.
The last (third) patch attached to the issue ads a extension dirs cache ( settings, modules and handlers dirs in extensions ) and thereby keeps performance up even though support for extension-override and felix's extension-sitaccess-override suggestion is implemented.

Could you test to see if it works like you suggested?
Ini override order is now:

Saturday 09 August 2008 10:39:28 am


Once again, do we apply all the three patches or just the last one? Got lost blunk.gif Emoticon
Should they work with 4.0.1RC2?


Saturday 09 August 2008 3:36:02 pm

They where for trunk, but I have cleaned up the issue and added a patch for 4.0.1rc2 now.
Should work on 4.0.0 as well, but with the amount of files this patch touches now I would bet on a couple of conflicts if you try to apply it there.

EDIT: Oh, and as always if not mentioned, they are stand alone( you only need one of the patches).

Modified on Saturday 09 August 2008 3:37:21 pm by André R

Monday 11 August 2008 6:03:26 pm

Hi André,

can you post the url to the patches?
I want to start testing on ez4.0.1rc2.


Monday 11 August 2008 6:13:30 pm

Hi Felix,

I believe it's all here:

Tuesday 12 August 2008 2:53:28 pm

Hi André,

you did a good job happy.gif Emoticon thank's.
It seems that the extension-siteaccess-override works as i expected.

But i found an error in kernel/settings/view.php.
The $ini->overrideDirs() array is not the same if e.g.
you access the siteaccess example_com_user -> settings/view

1. http://<b>admin.example.com</b>/settings/view/<b>example_com_user</b>/site.ini
2, http://<b>user.example.com</b>/settings/view/<b>example_com_user</b>/site.ini

=> 1. the $ini->overrideDirs() array is showing the order of ini parsing of the example_com_admin siteaccess but should be example_com_user
=> 2. showing the right $ini->overrideDirs() of example_com_user

<b>1. $ini->overrideDirs()</b> should be the same as <b>2. $ini->overrideDirs()</b>

To check this, activate different ActiveExtensions in site.ini of example_com_user and example_com_admin and count the $ini->overrideDirs() in kernel/settings/view.php.

print_r( $ini->overrideDirs() )

or use a templatevariable in kernel/settings/view.tpl for output of the overridedir list

$eZIniOverrideDirList = array();
foreach ( $ini->overrideDirs() as $iniLocation )
        $eZIniOverrideDirList[] = $iniLocation[0];// .' ('. $iniLocation[2] .')' ;

$tpl->setVariable( 'ini_override_dir_list' , $eZIniOverrideDirList );

In 4.0.1rc1 this was fixed but using $GLOBALS['eZINIOverrideDirList']. But this variable you didn't use anymore.
I think that $ini->overrideDirs() have to be correct. Otherwise different settings will be displayed.
Maybe i am wrong.
My goal was to display a list of all ini location which will be parsed for the selected SiteAccess.

André, can you check this?

Wednesday 13 August 2008 4:53:33 pm

I'll take a look at it when I have some spare time again, unfortunately not this week.

Wednesday 17 September 2008 2:28:02 am

We keep all our siteaccesses in extensions, same as Felix, which in turn call on other design extensions. Works well in ezp3.9 & 4.0 but we're having issues with 4.0.1, namely it's ignoring the design extensions which have been added to ActiveAccessExtensions and AdditionalSiteDesignList from within the siteaccess extension.

Is this because the ini priority order has changed?

Wednesday 29 October 2008 2:45:26 pm

Update: The things that are holding this patch back are the bc breaks. So after a chat with andrewd on irc, a change to this override order seems more realistic:


If we also need to keep complete bc with ActiveAccessExtensions*, then this would work:


Geoff: No change to ini order for 4.0, there was a change in design overrides (overrides needs to be in override folder and includes need to be in template folder), but doesn't seems like that is what your struggling with.

*The current patch doesn't distinguish extensions loaded with ActiveAccessExtensions and ActiveExtensions, so some changes would be needed to accomplish this.

Wednesday 29 October 2008 11:03:35 pm

I certainly think it's an improvement on what is currently there and a step in the right direction.

At least throughout these next minor releases it would be nice to have such a change and then if there is a need to break bc to achieve some larger goals then it can be discussed and approached in a more major revision.

Monday 12 July 2010 10:46:18 pm

This ini issue ( http://issues.ez.no/IssueView.php?Id=13382&activeItem=1 ) popped up on the radar again related to cleaning up siteaccess loading ( old access.php change() issue ) and there is therefor a couple of new patches (as separate git branches) available for discussion.

Evolutionary approach (beta quality):
Just changes loading order to become settings > extensions > extension-siteaccess > siteaccess > override.
Does not cause any known regressions in current eZ Publish trunk (incl trunk versions of extensions).

Pretty radical approach (prototype quality):
In addition to fixing loading order, changes parser to ezcIniReader and uses a far more efficient cache strategy (slightly faster then EZP_INI_FILEMTIME_CHECK tweak, and with still some file_exist calls to remove from ini related extension/siteacces code).

Monday 16 August 2010 12:00:49 am

The reply has been removed because of violation of forum rules.


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

36 542 Users on board!

Forums menu

Proudly Developed with from