|
Author
|
Message
|
|
Daniel Beyer
|
Friday 25 July 2008 2:24:41 am
Hi, about André's question:
One scenario I missed form you list, what if some extension in the middle of all this does:
[ExtensionSettings]
ActiveExtensions[]
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...
Daniel Beyer
_________________________________
YMC AG
Kreuzlingen, Switzerland
web: www.ymc.ch
____________________________________
|
|
André R.
|
Friday 25 July 2008 4:03:59 am
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?
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
|
|
Felix Woldt
|
Friday 25 July 2008 4:58:21 am
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?
extension
- ezwebin
-- settings/override
- site_project1
-- settings/siteaccess-override
- site_project2
-- settings/siteaccess-override
- site_project3
Thank's
http://www.jac-systeme.de - Developers united in eZ Publish: http://www.cjw-network.com
CJW Newsletter 1.0.0 released: http://projects.ez.no/cjw_newsletter
|
|
André R.
|
Friday 25 July 2008 5:30:56 am
No, I'm afraid I don't.
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
|
|
Felix Woldt
|
Friday 25 July 2008 6:23:30 am
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?
extension
- 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
http://www.jac-systeme.de - Developers united in eZ Publish: http://www.cjw-network.com
CJW Newsletter 1.0.0 released: http://projects.ez.no/cjw_newsletter
|
|
André R.
|
Friday 25 July 2008 7:08:01 am
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).
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
|
|
Felix Woldt
|
Friday 25 July 2008 7:26:41 am
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. Thank's
http://www.jac-systeme.de - Developers united in eZ Publish: http://www.cjw-network.com
CJW Newsletter 1.0.0 released: http://projects.ez.no/cjw_newsletter
|
|
Donat Fritschy
|
Friday 25 July 2008 9:15:58 am
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
Donat
http://www.webmanufaktur.ch - Developers united in eZ Publish: http://www.cjw-network.com
|
|
André R.
|
Friday 08 August 2008 12: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.
Felix:
Could you test to see if it works like you suggested?
Ini override order is now:
settings
extension
extension-siteaccess
siteaccess
extension-siteaccess-override
extension-override
override
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
|
|
Piotrek Karaś
|
Saturday 09 August 2008 1:39:28 am
André,
Once again, do we apply all the three patches or just the last one? Got lost ;)
Should they work with 4.0.1RC2? 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
|
|
André R.
|
Saturday 09 August 2008 6:36:02 am
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).
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
|
|
Felix Woldt
|
Monday 11 August 2008 9:03:26 am
Hi André,
can you post the url to the patches?
I want to start testing on ez4.0.1rc2. Thank's
http://www.jac-systeme.de - Developers united in eZ Publish: http://www.cjw-network.com
CJW Newsletter 1.0.0 released: http://projects.ez.no/cjw_newsletter
|
|
Piotrek Karaś
|
Monday 11 August 2008 9:13:30 am
Hi Felix,
I believe it's all here:
http://issues.ez.no/IssueView.php?Id=13382&activeItem=1
--
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
|
|
Felix Woldt
|
Tuesday 12 August 2008 5:53:28 am
Hi André,
you did a good job :-) 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?
Thank's
Felix
http://www.jac-systeme.de - Developers united in eZ Publish: http://www.cjw-network.com
CJW Newsletter 1.0.0 released: http://projects.ez.no/cjw_newsletter
|
|
André R.
|
Wednesday 13 August 2008 7:53:33 am
I'll take a look at it when I have some spare time again, unfortunately not this week.
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
|
|
Geoff Bentley
|
Tuesday 16 September 2008 5:28:02 pm
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?
|
|
André R.
|
Wednesday 29 October 2008 6:45:26 am
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:
settings
siteaccess
extension
extension-siteaccess
extension-siteaccess-override
extension-override
override If we also need to keep complete bc with ActiveAccessExtensions*, then this would work:
settings
access-extension
access-extension-siteaccess
siteaccess
extension
extension-siteaccess
access-extension-siteaccess-override
extension-siteaccess-override
access-extension-override
extension-override
override 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.
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
|
|
Andrew Duck
|
Wednesday 29 October 2008 3: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.
Andrew Duck, Executive Director, Quiqcorp Limited
eZ Certified Developer and Trainer.
Member of the Community Project Board
http://quiqcorp.com | http://twitter.com/andrewduck
|
|
André R.
|
Monday 12 July 2010 1: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).
http://github.com/andrerom/ezpublish/commit/9ecadd8ea7be7ff5bb75c4983dfffc43c82045f6
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).
http://github.com/andrerom/ezpublish/commits/ar.master
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
|
