*.ini priority vs. extension settings

Tuesday 19 February 2008 9:33:47 am

Just looking at the priority that the settings files follow:

Gunnstein wrote at http://ez.no/doc/ez_publish/technical_manual/4_0/concepts_and_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?

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu

Wednesday 20 February 2008 10:50:48 am

Hi,

The order is borderline blackmagic, and that's an ongoing topic of discussion.

My experience is that most of the times you can override the extension (eg the standard templates) with your custom ( eg /yourdesign templates).

Try (and do the clear cache), to see what works for you.

X+

http://www.sydesy.com

Monday 07 April 2008 6:16:17 am

Cool Felix,

this is a long, long time needed enhancement for multiple sites or customers on one installation. If we had this in former times, it would have been more fast and easy to develop clean installation with all the settings in extensions. I saw in your screenshot http://issues.ez.no/AttachmentItemDownload.php?Id=5757 that you have multiple site_extensions for multiple users.

eZ core developers, can you please integrate these big enhancements

http://issues.ez.no/IssueView.php?Id=12747
http://issues.ez.no/IssueView.php?Id=12519

into the core? So we spare a lot of time in development and with patching eZ Publish 4 ourself.

Thanks and greetings, ekke

http://www.coolscreen.de - Over 40 years of certified eZ Publish know-how: http://www.cjw-network.com
CJW Newsletter: http://projects.ez.no/cjw_newsletter - http://cjw-network.com/en/ez-publ...w-newsletter-multi-channel-marketing

Monday 23 June 2008 6:19:34 pm

Now, that we know the way things are likely to happen (no matter how quickly) to eZ Publish with releases 4.2, 4.x, 5.0... maybe it would be possible to plan an unpgrade for the configuration files for one of those coming versions?

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu

Monday 07 July 2008 10:07:25 pm

Since this topic was just brought back, let's revitalize it ;)

<i>Don't want to comment this further, as I gave up hope years ago that this stupid thing will ever be fixed by eZ. But I really whish you GOOD LUCK !!!</i>

;( not sure if this gives me strength to struggle, or the opposite...

<i>BTW: If anyone is interested in just an other solution for this, just write me some lines... </i>

Daniel, sure, what's your suggestion?

Felix, I haven't checked your suggestions out yet, but that's mostly because it will be hard for us to rely on direct kernel/lib modifications, especially if they are not planned be supported in the future. That's actually the only problem, because otherwise I would have probably invented our custom extension tool ;)

While we also have problems with ini order, the biggest one right now seems lack of 3-level ini setting system for extensions, just like the one for global settings. It seems like the ini system for extensions was created before... the system of extensions was introduced ;)))
If I want to have a base setting file for my extension, I would have to manually copy it into /settings directory ;( It is all possible, but only if we break the rules and ideas behind physically independent extensions ;)

What would be required to get this thing changed? Anyone from eZ?

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu

Tuesday 08 July 2008 4:21:19 am

So, would it be acceptable to break this behavior to fix it in a 4.x version?

As I mentioned in Felix's issue, I would personally prefer this order(included siteaccess activated extensions):

0 settings/
1 extension/*/settings
2 extension/*/settings (ActiveAccessExtension)
3 settings/siteaccess
4 extension/*/settings/siteaccess
5 extension/*/settings/siteaccess (ActiveAccessExtension)
6 extension/*/settings/override
7 extension/*/settings/override (ActiveAccessExtension)
8 settings/override

To be able to do this, a lot of ini loading related code needs to change. Currently override dirs are prepended as they load: override, extensions, siteaccess, siteaccess extensions. So to be able to accomplish the above order, eZINI->prependOverrideDir (and eZINI->appendOverrideDir) needs to be a bit more smart based on the $identifier flag, or the whole way of prepending override dirs need to change ( prependSiteAccessDirs + prependExtensionDirs ?? ).

What do you think? (About how this should be solved, when and what order it should have)

eZ Online Editor 5: http://projects.ez.no/ezoe || eZJSCore (Ajax): http://projects.ez.no/ezjscore || eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription
@: http://twitter.com/andrerom

Wednesday 09 July 2008 2:11:30 am

Hi,

our approach of course cares about the order extensions are activated. Actually this is a pretty simple task:

As our loader is able to activate any other extension from an extension which has just been activated think about the following scenario:

1. You have an extension called <b>mybase</b> which is activated in one of the "core"-settings files (which can be /settings/site.ini or /settings/override/site.ini or even /settings/siteaccessXYZ/site.ini). This extension then will be the first one loaded.

2. Inside the extension <b>mybase</b> you have defined to load two other extensions called <b>one</b> and <b>two</b>, which can be done in /extension/mybase/settings/site.ini or in /extension/mybase/settings/siteaccess/XYZ/site.ini. These two extension are loaded now.

3. This can be repeated as long as you have loaded all extensions. After this has been done once the order of all loaded extensions will be cached for future calls to keep the overhead of finding the correct load order as small as possible.

This has been a really stripped down example to get the concepts of what we have done. If you think about siteaccesses, it is slightly more complex.

We handle loading of extensions in two stages. The first stage is called <b>Pre siteaccess</b> the second is called <b>After siteaccess</b>. Both stages are following the same principles (as described above) of how to load extensions and both are able to activate any additional extension after an loaded extension (as described above).

The <b>Pre siteaccess</b> stage is the same for every siteaccess and therefore is cached globally for all siteaccesses after the first call to eZ publish. To load an extension in this stage you can use the following config-files:

a) /settings/site.ini
b) /settings/override/site.ini
c) /extension/volano_basic_settings/settings
d) /extension/MYLOADEDEXTENSION/settings/site.ini

Note that our loader is not a magic one. So it respects for d) only those extensions which have been already loaded. So you need to activate at least one extension in a) or b) or c). The c) is a special extension which always is loaded as the first extension by our loader. This is something we've done, as we didn't wanted to touch the core-settings any longer at all.

<b>So here is an example for loading the first stage:</b>
Assume you have defined to load the following extensions in either a), b) or c):

[ExtensionSettings]
ActiveExtensions[]=simpledatatypes
ActiveExtensions[]=operators
ActiveExtensions[]=complexdatatypes

This will result to activate the following additional extensions in exactly this order:
<b>volano_basic_settings</b>, <b>simpledatatypes</b>, <b>operators</b>, <b>complexdatatypes</b>

Now assume that in /extension/simpledatatypes/settings/site.ini is the following code:

[ExtensionSettings]
ActiveExtensions[]=defaultdesigns
ActiveExtensions[]=moredesigns

And assume that in /extension/complexdatatypes/settings/site.ini is the following code:

[ExtensionSettings]
ActiveExtensions[]=defaultdesigns
ActiveExtensions[]=andevenmoredesigns
ActiveExtensions[]=moredesigns

This will result in the following load order of extensions:
<b>volano_basic_settings</b>,, <b>simpledatatypes</b>, <b>operators</b>, <b>complexdatatypes</b>, <b>defaultdesigns</b>, <b>moredesigns</b>, <b>andevenmoredesigns</b>

Not that the alternate order in the site.ini of <b>complexdatatypes</b> is ignored and only the additional extension <b>andevenmoredesigns</b> is loaded. The order would be the other way arround, if <b>complexdatatypes</b> would have been loaded before <b>simpledatatypes</b>.

You could continue this thing for as long as you want to, as the <b>Pre siteaccess</b> stage is able to activate any extension from a just loaded extension and then load yet an other extension from that loaded extension - but I think anybody should have get that now...

<b>To sum this up:</b>
The first stage loads any defined extensions and after those are loaded it takes a look to all of those loaded extension if they define more extensions to load. And after that it does that , till there are no more additional extensions to load.

<b>Now to the siteaccess thing:</b>
We now have a set of extension, which have to be loaded for any siteaccess. Any of these loaded extension is able to hold an settings/siteaccess/XYZ directory, in which we can have a site.ini just for the siteaccess we are currently using. So let's assume we're using the siteaccess "XYZ", then the following possible site.ini-files are relevant to look for us in order to find more extensions to load:

1. /extension/volano_basic_settings/settings/siteaccess/XYZ/site.ini
2. /extension/simpledatatypes/settings/siteaccess/XYZ/site.ini
3. /extension/operators/settings/siteaccess/XYZ/site.ini
4. /extension/complexdatatypes/settings/siteaccess/XYZ/site.ini
5. /extension/defaultdesigns/settings/siteaccess/XYZ/site.ini
6. /extension/moredesigns/settings/siteaccess/XYZ/site.ini
7. /extension/andevenmoredesigns/settings/siteaccess/XYZ/site.ini
8. /settings/siteaccess/XYZ/site.ini

Now assume inside /extension/volano_basic_settings/settings/siteaccess/XYZ/site.ini is the following code:

[ExtensionSettings]
ActiveExtensions[]=xyzextension
ActiveExtensions[]=defaultdesigns

And assume inside /extension/operators/settings/siteaccess/XYZ/site.ini is the following code:

[ExtensionSettings]
ActiveExtensions[]=xyzoperators
ActiveExtensions[]=defaultdesigns

This will result in this load order:
<b>volano_basic_settings</b>, <b>simpledatatypes</b>, <b>operators</b>, <b>complexdatatypes</b>, <b>defaultdesigns</b>, <b>moredesigns</b>, <b>andevenmoredesigns</b>, <b>xyzextension</b>, <b>xyzoperators</b>

Note that <b>defaultdesigns</b> is ignored, as it has been already loaded!

As you might know the <b>After siteaccess</b> stage is able to load an extension from inside a loaded extension, so we can have even more extensions activated:
Code in /extension/xyzextension/settings/site.ini:

[ExtensionSettings]
ActiveExtensions[]=xyzextension2
ActiveExtensions[]=defaultdesigns

Code in /extension/xyzextension/settings/siteaccess/XYZ/site.ini:

[ExtensionSettings]
ActiveExtensions[]=xyzextensionjustformysiteaccessxyz
ActiveExtensions[]=defaultdesigns

Once more: <b>defaultdesigns</b> is ignored, as it has already been activated. But we now have two more extensions to load, resulting in this order:
<b>volano_basic_settings</b>, <b>simpledatatypes</b>, <b>operators</b>, <b>complexdatatypes</b>, <b>defaultdesigns</b>, <b>moredesigns</b>, <b>andevenmoredesigns</b>, <b>xyzextension</b>, <b>xyzoperators</b>, <b>xyzextensionjustformysiteaccessxyz</b>, <b>xyzextension2</b>

Why <b>xyzextensionjustformysiteaccessxyz</b> is loaded before <b>xyzextension2</b> ???
This is because of the ini-load-order, which chooses siteaccess-settings above normal settings.

I just stop here with the extension load order, and hope you get this thing. <b>Please drop a note if something is unclear with that!</b>

Now let's have a finaly look to the ini load order (first i write here will be loaded first, higher number overrides lower numbers):

26. /settings/override/siteaccess/XYZ
25. /settings/override

24. /extension/xyzextension2/settings/siteaccess/XYZ
23. /extension/xyzextensionjustformysiteaccessxyz/settings/siteaccess/XYZ
22. /extension/xyzoperators/settings/siteaccess/XYZ
21. /extension/xyzextension/settings/siteaccess/XYZ
20. /extension/andevenmoredesigns/settings/siteaccess/XYZ
19. /extension/moredesigns/settings/siteaccess/XYZ
18. /extension/defaultdesigns/settings/siteaccess/XYZ
17. /extension/complexdatatypes/settings/siteaccess/XYZ
16. /extension/operators/settings/siteaccess/XYZ
15. /extension/simpledatatypes/settings/siteaccess/XYZ
14. /extension/volano_basic_settings/settings/siteaccess/XYZ

13. /settings/siteaccess/XYZ

12. /extension/xyzextension2/settings
11. /extension/xyzextensionjustformysiteaccessxyz
10. /extension/xyzoperators/settings
9.  /extension/xyzextension/settings
8.  /extension/andevenmoredesigns/settings
7.  /extension/moredesigns/settings
6.  /extension/defaultdesigns/settings
5.  /extension/complexdatatypes/settings
4.  /extension/operators/settings
3.  /extension/simpledatatypes/settings
2.  /extension/volano_basic_settings/settings

1.  /settings

Finally I'm really sorry this isn't a real world example - I just tried to catch every possible scenario.

Gone catch some coffee, now...

Daniel Beyer
_________________________________
YMC AG
Kreuzlingen, Switzerland
web: www.ymc.ch
____________________________________

Wednesday 09 July 2008 11:41:39 am

Hi André,

we load that in a loop-manner (yes, "multi pass loading" - like that name ;). This is only overhead for the first time accessing the site, as we cache the results. Once we have a cache, we need only a single run to load the extensions (no more looping, no more "multi pass loading"). I think this is okay, since the order is unlikely to change often and if it does just flush the cache (as it is with compiled templates on a productive site).

I personally prefer to have only a single setting to switch on extensions and didn't understand ever, why the current eZ publish needs two for that task. Let me quote my own phpDocumentor-Comment I posted above:

Note that OpenVolano does not care much whether an extension is loaded
as "ActiveExtension" or "ActiveAccessExtension". The only thing is,
that an "ActiveExtension" is _tried_ to be loaded before an
"ActiveAccessExtension". It is recommended that you only use the
setting "ActiveExtension" to load an extensions as long as you don't
experience problems with that.

Additionally OpenVolano allows loading of extensions inside any other
extension (so there is in fact no more need to use the
"ActiveAccessExtension"-setting which most likely has been
introduced in eZ publish to workaround this missing feature).

So the other way around: Why should we need two settings to approach one task? I think things should be as simple as possible and even my last post might be quite confusing, I think it's what a developer will most likely expect to happen without thinking further about the hole ini and extension thing.

BTW.: For us it doesn't matter if the current behavior of loading extensions and the ini-order changes. In fact we broke with this years ago...

Oh, forgot about your real question:

Daniel: Why did you decide to allow extension loading from extensions?

<b>If you think of the following scenario</b>
1. You have a set of extension, which you are using very often
2. You have a major website with lot's of siteaccesses and different set of features
3. You have this thing running on a cluster of just* 3 Webservers and need real high availability
4, You do not want to touch a single code line delivered with eZ publish in order to keep upwards compatibility and easy upgrades.
5. You don't want to touch a single code line inside your often used extensions in order to maintain them for ALL your projects (and not just for this project) in a central place
6.You can't have your sources on a shared storage (think about HA!)

<b>Then</b>
You want to do everything in custom (coded for this one project only) extensions and have the need to activate a set of extensions by default, then have the projects main extension loaded which then might loads additional extensions (e.g. when accessing siteaccess XYZ).

<b>Finally</b>
There is our need for loading extensions inside extensions which then loads other extensions which are able to load an extension and probably activate some - you know... ;)

Cheers!

----------------
* Trust me: Even 6 Blades isn't that much in the Web 2.0 world. Actually our largest eZ publish installation is currently running with the power of 48 Cores. <i>Okay, 16 are dedicated to mysql and 8 to our completely oversized load balancers.and the rest isn't rellly dedicated to just that single installation - but it's still kind of impressive (for 2008).</b>

Daniel Beyer
_________________________________
YMC AG
Kreuzlingen, Switzerland
web: www.ymc.ch
____________________________________

Monday 21 July 2008 8:59:07 am

Incoming patch, please test....:
http://issues.ez.no/IssueView.php?Id=13382&activeItem=1

Before patch:

0 	string 	'settings'
1 	string 	'extension-siteaccess ezsearchpro'
2 	string 	'extension-siteaccess ezwebin'
3 	string 	'extension-siteaccess test(ActiveAccessExtensions)'
4 	string 	'extension-siteaccess test(ActiveAccessExtensions)'
5 	string 	'extension test(ActiveAccessExtensions)'
6 	string 	'extension-siteaccess ezwebin'
7 	string 	'extension-siteaccess ezsearchpro'
8 	string 	'siteaccess'
9 	string 	'extension ezwebin'
10 	string 	'extension ezsearchpro'
11 	string 	'override'

After patch:

0 	string 	'settings'
1 	string 	'extension test(ActiveAccessExtensions)'
2 	string 	'extension ezwebin'
3 	string 	'extension ezsearchpro'
4 	string 	'extension-siteaccess test(ActiveAccessExtensions)'
5 	string 	'extension-siteaccess ezwebin'
6 	string 	'extension-siteaccess ezsearchpro'
7 	string 	'siteaccess'
8 	string 	'extension-override test(ActiveAccessExtensions)'
9 	string 	'extension-override ezwebin'
10 	string 	'extension-override ezsearchpro'
11 	string 	'override'

code for test:

{ezini( 'test', 'test', 'test.ini',,true() )|attribute( 'show',1 )} 

settings/test.ini:

#?ini charset="iso-8859-1"?

[test]
test[]=settings

(and so on..)

As you can see I also fixed some issues with the usage of the $identifier, or I just broke a lot of ini code :)

eZ Online Editor 5: http://projects.ez.no/ezoe || eZJSCore (Ajax): http://projects.ez.no/ezjscore || eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription
@: http://twitter.com/andrerom

Wednesday 23 July 2008 9:57:28 am

Incoming patch, please test....

Great news! So you eventually decided to release it for closest minor version, or is this just for testing?
I'll give it a try ASAP.
Thanks!

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu