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?

Tuesday 19 February 2008 10:29:27 pm

I 100% agree that extensions settings that are set per siteaccess should be of higher priority than extension settings that are part of the default extension distribution.

(if I got it right, ie. priority of settings in extension being dependent on the current subfolder rather than the fact that extension is loaded by siteaccess or by override).

One other facet that I find little documented and would benefit of a little love is the order in which the settings set by the various extensions take precedence one over the other:
- I generally have new settings file created for a given extension named .ini (since they're created locally to the extension)
- if an extension is a general purpose one, one other extension that implements site-specific functionality (eg a desigfn extension) and depends on it will include inside its own settings dir the same settings file, named .ini.append.php
- for this to work, the second extension must be loaded BEFORE the first one, or the parameters will not be overridden
- otoh I am under the impression that site designs are loaded in the reverse order, starting from the last extension loaded and ending with the first.
This makes it a little problematic to find a correct loading order for eg. a design extension, that takes advantage of general-purpose extensions and adds the finishing touches to the settings, ie. just before the global override...

Wednesday 20 February 2008 7:50:48 pm


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.


Thursday 20 March 2008 4:25:59 pm

<b>This thread is updated on 24.6.2008</b>

This is an interesting topic.
I post today an enhancement with patch for ez4

Another patch for display the ini parsing order in admin interface
Screenshot of in ordner

That define a new ini setting

/extension/ site_extension/ settings/ siteaccess/ override/ *.ini.append.php

This setting is only active if a extension siteaccess is active and overrides extensionsiteaccesse ini settings.

So you have a global extension siteaccess ini.

This is realy usefull if you have a 'site_extension' for each project where you put all siteaccesses and designs. With the new ini location you have a seperate overrride for each site project.

+ extension
  + site_test
    + settings
         + override 
            - site.ini.append.php (2)
         + siteaccess
           + test_user (access1)
              - site.ini.append.php (1)
           + test_admin (access2)
              - site.ini.append.php (1)
      - site.ini.append.php (3)

+ settings
  + override
    - site.ini.append.php (4)

(0) here will be ini settings of extension, which are activate in extension siteaccess

(1) ezroot/extension/site_test/settings/siteaccess/ test_user / site.ini.append.php
(2) ezroot/extension/site_test/settings/siteaccess/override / site.ini.append.php 
(3) ezroot/extension/site_test/settings/ site.ini.append.php 
(4) ezroot/settings/override/ site.ini.append.php 

Hope other people find this usefull, too.

Modified on Tuesday 24 June 2008 9:21:48 am by Felix Woldt

Monday 07 April 2008 3:16:17 pm

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


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

Thanks and greetings, ekke

Monday 07 April 2008 5:38:17 pm

Hi there,

if you thought this is a long time demand than you are terribly wrong as this actually is kind of an "ancient" issue - frist seen in the early '04 of this century blunk.gif Emoticon

But see for yourself: http://issues.ez.no/IssueView.php?Id=2709

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 !!!

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

Tuesday 24 June 2008 3:19:34 am

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?

Tuesday 24 June 2008 9:32:54 am

I hope so, that we will get the new ini override setting for extensions.
The patch is very simple.


Index: lib/ezutils/classes/ezextension.php
--- lib/ezutils/classes/ezextension.php (revision 21575)
+++ lib/ezutils/classes/ezextension.php (working copy)
@@ -169,7 +169,11 @@
$ini = eZINI::instance();
- $ini->prependOverrideDir( $extensionSettingsPath . '/settings/siteaccess/' . $accessName, $globalDir );
+ // define new ini location which is enabled if a extension siteaccess is active - overrides extension siteaccess settings
+ // extension/$ext_name/settings/override/ *.ini.append.php
+ $ini->prependOverrideDir( $extensionSettingsPath . '/settings/override/' , $globalDir, 'ext-siteaccess-override' );
+ // extension/$ext_name/settings/siteaccess/$siteaccess_name/ *.ini.append.php
+ $ini->prependOverrideDir( $extensionSettingsPath . '/settings/siteaccess/' . $accessName, $globalDir, $identifier );

We use this patch in our ez environment, because we are running multiple different sites ( located in extensions ( design + siteaccess + separate db ) on <b>one</b> ez installation.

Tuesday 08 July 2008 7:07:25 am

Since this topic was just brought back, let's revitalize it blunk.gif Emoticon

<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 blunk.gif Emoticon

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 blunk.gif Emoticon))
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 blunk.gif Emoticon

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

Modified on Tuesday 08 July 2008 7:09:21 am by Piotr Karaś

Tuesday 08 July 2008 9:26:04 am

Hi Piotrek,

we using a completely rewritten extension loader which overrides the one coming with the eZ publish 4 core. I think the most easy thing for me right now is to post PHPDocumentor-entry in our source, which should describe the hole thing pretty clear:

     * Activate extensions "in the OpenVolano-way".
     * OpenVolano introduces a new order how to load ini-settings in eZ
     * publish. This has been a long time demand as you might see here:
     * http://issues.ez.no/IssueView.php?Id=2709
     * Besides a more consistent load-hierarchy OpenVolano adds support to
     * global override settings for a specific siteaccess which is useful
     * for local development.
     * 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).
     * ------------------------------------
     * Here is an example:
     * ------------------------------------
     * Assume there are four extensions called "FIRST", "SECOND", "THIRD", and
     * "FOURTH". The extension "FIRST" is activated in "settings/site.ini" (or
     * in "settings/override/site.ini" if you e.g. just want to try out a new
     * extension), whether as "ActiveExtension" or "ActiveAccessExtension"
     * (which doesn't matter much, see above).  Inside the extension "FIRST"
     * (which now is active), the extension "SECOND" is activated in
     * "extension/FIRST/settings/site.ini" (again: it doesn't matter whether
     * as "ActiveExtension" or as "ActiveAccessExtension" - I won't repeat
     * this fact anymore!). This make OpenVolano load the extension "SECOND"
     * now.
     * Now we assume that the extension "SECOND" has the extension "THIRD"
     * referenced in its "extension/SECOND/settings/site.ini" which makes
     * OpenVolano to load "THIRD" now. I assume you got it now and can imaging
     * what will happen if "FOURTH" is referenced in "THIRD"...
     * ----------------------------------------
     * This is the hierarchy used to load settings in OpenVolano - note that
     * higher numbers are searched for settings first (first look/load in 8.
     * then in 7. then in ... 1.):
     * 1. Default Settings (/settings)
     * 2. In ActiveExtensions (extension/EXTENSION/settings)
     * 3. In ActiveAccessExtensions (/extension/EXTENSION/settings)
     * 4. Default Siteaccess-Settings (/settings/siteaccess)
     * 5. Siteaccess in ActiveExtensions
     *                  (/extension/EXTENSION/settings/siteaccess/SITEACCESS)
     * 6. Siteaccess in ActiveAccessExtensions
     *                  (/extension/EXTENSION/settings/siteaccess/SITEACCESS)
     * 7. Globale Overrides (/settings/override)
     * 8. Globale Siteaccess-Overrides (/settings/override/sitaccess/SITEACCESS)
     * Note that it is even possible to load an additional extension in the
     * siteaccess-settings of an already activated extension.
     * ----------- Here is an example: ------------------
     * It's possible to activate the extension "FIFTH" for the siteaccess
     * "SITEACCESS" which has a site.ini in the already active extension
     * "FOURTH" (so we talking about this site.ini:
     * "extension/FOURTH/settings/siteacces/SITEACCESS/site.ini"). If you now
     * accesses "SITEACCESS" the extension "FOURTH" will be active. And if
     * "FOURTH" activate the extension "SIX" this one will be active, too.
     * -------------------------------------------------------------
     * @author ymc-dabe
     * @see    eZExtension::activateExtensions()
     * @return void

When we wrote this new loader, we took especially care about the speed and profiled it down with the following results:

---- SNIP ----
OpenVolano: Enhanced Extension Loader
Pre siteaccess initialised 0.0075 sec 0.6919% 1 0.0075 sec
After siteaccess 'volano_admin' initialised 0.0030 sec 0.2742% 1 0.0030 sec
---- SNIP ----

This is the result with loading 16 different extension. I doubt the extension loader coming with eZ 4 is faster than the one we have now. If you have any questions left, just ask... blunk.gif Emoticon

Tuesday 08 July 2008 1:21:19 pm

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)

Modified on Tuesday 08 July 2008 1:39:22 pm by André R

Wednesday 09 July 2008 6:34:44 am


Thanks for sharing that doc, interesting concept. One question: does that approach solve anything about extension loading order?


Thanks for the response. So you're suggesting that it would actually be possible to fix this in 4.x series? blunk.gif Emoticon That would be really great.

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

I think it should be done as soon as possible, with next 4.X.0 version of course, but I believe more people have to air their views here.

Here's my criteria in some detail:

New extension ini system should (at least) make it possible to follow the well known pattern: BASE->SITEACCESS->OVERRIDE (at least 3-level standard).

We need BASE for files that:
a) secure availability of all required variables
b) keep all the ini documentation, explanations, examples, complete set of variables etc.
We need SITEACCESS for siteaccess-based settings.
We need OVERRIDE for easier both development and production management.

And I think we have that for standard settings today. This should stay the way it is.

However, this isn't very much true for the extensions. Although it is possible to realize this approach, it would require mixing extension resources with general settings. And I believe one of the base concepts behind extensions is that they are as independent as possible. Therefore, this 3-level standard should be possible for extensions themselves. This would not be as important for overriding general eZ Publish settings, but critical for newly introduced variables or ini files.

To wrap up, BASE->SITEACCESS->OVERRIDE model should be possible <b>within</b> an extension. This postulate seems to be met in André's order (I temporarily removed ActiveAccessExtension's doubles):

0 settings/ [general base]
1 extension/*/settings [ext base]
2 settings/siteaccess [general siteaccess]
3 extension/*/settings/siteaccess [ext siteaccess]
4 extension/*/settings/override [ext override]
5 settings/override [general override]

The only question that remains for me here is: if extension overrides are weaker than global overrides, shouldn't that be the same for siteaccess-dedicated settings (switching 2 and 3):

0 settings/ [general base]
1 extension/*/settings [ext base]
2 extension/*/settings/siteaccess [ext siteaccess]
3 settings/siteaccess [general siteaccess]
4 extension/*/settings/override [ext override]
5 settings/override [general override]

Both ways will probably have some benefits. Maybe we should try to weigh those.

The other thing would be the order in which extensions are activated (Gaetano's post above). As I wrote, I'm not sure if Daniel's approach tackles that (but maybe that's because I hardly slept tonite...).

Wednesday 09 July 2008 11:11:30 am


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):


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:


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


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:


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


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:


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


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...

Modified on Wednesday 09 July 2008 11:13:51 am by Daniel Beyer

Wednesday 09 July 2008 11:28:59 am

Daniel: Why did you decide to allow extension loading from extensions? Do you do this in a loop? (multi pass loading) or keep it to a simple double pass (just look for more extensions once after the first extensions are loaded).

I'am unsure this is actually needed, since in the ini order I suggest, you could use ActiveAccessExtension inside the globally loaded extensions (even for all siteaccesses in extension/*/settings/) to load second pass extensions.

>Thanks for the response.
>So you're suggesting that it would actually be possible to fix this in 4.x series? blunk.gif Emoticon

Of course, it only needs a clean and well tested patch that all agrees on..
But the question is more: is it acceptable to break it in a 4.x version?

Modified on Wednesday 09 July 2008 11:31:52 am by André R

Wednesday 09 July 2008 8:41:39 pm

Hi André,

we load that in a loop-manner (yes, "multi pass loading" - like that name blunk.gif Emoticon. 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"blunk.gif Emoticon. 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!)

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).

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... blunk.gif Emoticon


* 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>

Modified on Wednesday 09 July 2008 9:32:57 pm by Daniel Beyer

Tuesday 15 July 2008 12:10:17 pm

About this multi pass loading... I have to leave this to more experienced users, but if that model proves itself to be able to solve some complex scenarios and does not add total overhead, then it may be desired to implement that.

But the question is more: is it acceptable to break it in a 4.x version?

If you ask me, I would accept these changes between major releases, for example with 4.1.0 or 4.2.0. Waiting any longer than that (until 5.x for example) means a very distant future blunk.gif Emoticon

But I am sure this issue will have to be discussed by eZ people internally, and also it would be good to know if we're discussing a realistic plan blunk.gif Emoticon (meaning that it won't be given up before next big release).

Modified on Tuesday 15 July 2008 12:13:07 pm by Piotr Karaś

Monday 21 July 2008 5:59:07 pm

Incoming patch, please test....:

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 )} 


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


(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 happy.gif Emoticon

Wednesday 23 July 2008 12:39:19 am

One scenario I missed form you list, what if some extension in the middle of all this does:


Do you catch that or ignore it?

Wednesday 23 July 2008 6:57:28 pm

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.

Wednesday 23 July 2008 7:15:19 pm

> So you eventually decided to release it for closest minor version, or is this just for testing?

The patch is for trunk, but shouldn't be to hard to make it work on 4.0.x.
Just for testing you can ignore all conflicts but index.php.

Oh and last version of the patch supports "multi pass" extension loading, so here is my current output:

0 	string 	'settings'
1 	string 	'extension test2(ActiveAccessExtensions loaded by test)'
2 	string 	'extension test(ActiveAccessExtensions)'
3 	string 	'extension test3(loaded by ezwebin)'
4 	string 	'extension ezwebin'
5 	string 	'extension ezsearchpro'
6 	string 	'extension-siteaccess test2(ActiveAccessExtensions loaded by test)'
7 	string 	'extension-siteaccess test(ActiveAccessExtensions)'
8 	string 	'extension-siteaccess ezwebin'
9 	string 	'extension-siteaccess ezsearchpro'
10 	string 	'extension-siteaccess test3(loaded by ezwebin)'
11 	string 	'siteaccess'
12 	string 	'extension-override test2(ActiveAccessExtensions loaded by test)'
13 	string 	'extension-override test(ActiveAccessExtensions)'
14 	string 	'extension-override test3(loaded by ezwebin)'
15 	string 	'extension-override ezwebin'
16 	string 	'extension-override ezsearchpro'
17 	string 	'override'

Modified on Wednesday 23 July 2008 7:17:23 pm by André R

Friday 25 July 2008 11:24:41 am


about André's question:

One scenario I missed form you list, what if some extension in the middle of all this does:


Do you catch that or ignore it?

We ignore that, dropping a log-message that unloading extensions isn't supported.

I just took an other look to our code and saw that we're handling autoloads during the extension loading as well. This eliminates the need to create an '/autoload/ezp_extension.php, as our loader just autoloads a '/extension/XYZ/autoload/autoload.php' for each extension that has been loaded. I think this is a great enhancement.

I currently do not have the time to test the current patch, nor I can create a patch of my own using our loader. This might is quite some work, as we put our code in its own class instead of heavily patching the existing loader in eZ publish. If you are interested in how we solved this issue, just drop a note and I'll try to find the time to publish an own patch...


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

36 542 Users on board!

Forums menu

Proudly Developed with from