Multiple Sites with One eZ installation. ( Potential Problems on the horizon )

Next topic

Author	Message
Chris Williams	Monday 13 September 2010 3:35:28 am Multiple Sites with One eZ installation. ( Potential Problems on the horizon ) Autoload is not site specific. Log files are not written based on individual sites. Autoload is not site specific. Each site may require different classes from different extensions, yet they might be using the same class name or file name. Equally, with the creation of the var directory for each siteaccess. It makes sense that the autoload should be found with in that var directory. Part of the problem is telling the system which autoload to include, due to the siteaccess being discovered in "index.php" after some classes have initially been loaded. Another part of the problem, "ezautoloadgenerator.php" the creation of the mapping array, doesnt have a way to know which siteaccess to use. Equally it doesnt know where to then save the new siteaccess specific "ez_kernel.php". ie within the "VarDir" value in the "site.ini.append.php". The trickiest part will be figuring out how to deal with the "index.php". Log files are not written based on individual sites. The way eZDebug is set up, at present. The paths to the log file locations are hardcoded into the public variable "LogFiles". A hack would be to override this public variable with a SiteAccess specific location for each of the logs. A better solution would be to add another method to eZDebug to do this for us, similar to the eZDebug::updateSettings().
Peter Rudolfsen	Monday 13 September 2010 3:36:51 am Just wanted to say that I'm backing this up, and are potentially big issues with having loads of site in the same installation. I'd really love to see some kind of standalone, pluggable, library version of eZ Publish that you could easily add new sites to without copying all of the needed libraries and such.
Gabriel Finkelstein	Monday 13 September 2010 10:02:16 am I would also add that modifying the template look (Design >> Look) modifies the global settings instead of a specific siteaccess.
Chris Williams	Tuesday 14 September 2010 2:19:44 am Hi Gabriel, Im not entirely sure what you mean. A combination of writing extensions and linking to them in your siteaccess allows you to create designs specific to any siteaccess and not globally. Yet as a fall back if your design is missing a template it will fallback to default eZ templates. If this is not what you mean, please could you explain a little more. A semi example. #in siteaccess settings/site.ini.append.php [DesignSettings] SiteDesign=unique_site_design_extension AdditionalSiteDesignList[] AdditionalSiteDesignList[]=unique_site_design_extension AdditionalSiteDesignList[]=ezwebin AdditionalSiteDesignList[]=base If you create an extension with your design in. Within your extension you need to add the following ini settings to make it work. # in EXT settings/design.ini.append.php [ExtensionSettings] DesignExtensions[]=unique_site_design_extension
SEBBANE Alexandre	Saturday 18 September 2010 8:33:52 pm Hello, when you say "Multiple Sites with One eZ installation. ( Potential Problems on the horizon )" do you mean 1 install of Ez and One database or one install and many database. for both case : as the install of ez is unique, as soon as you have an error in an extension, it will generate logs : so why do you want to separate logs : it is easier to see it and correct ot. for autoloads the autoloads files is hsut an array but it means tahats you have to do good code which take contasnt from your current siteaccess. For me , as i use it evreyday in my intranet websute factory, your two issues are not so potentials problems but goods solutions to have feedback in one file ( as we speak of the logs issues). i hope my point of view will answer your questions Paris, France
Chris Williams	Tuesday 21 September 2010 12:26:11 am Hi Alexandre, I do mean one install of eZ and its extensions and different databases per site. When you have more than one site logging to the same log files, there is no easy way to distinguish which site created that error. Of course this is greatly reduced when your working on a site. Of course what im trying to discuss is not an everyday case, but with the potential push in using eZ to manage multiple sites under the one install, I was just highlighting some of the little things I have been dealing with. Im not 100% sure what you are saying in your response regarding the autoloads. If we have two extensions, but one had to be tweaked. So we either alter the class or create a new extension called before the other to override that class. How does the autoload know which one site "a" needs loaded and which one site "b" needs loaded. Based on how you use eZ on an intranet, I suspect the problems outlined in my first post will ever be an issue for that installation. Thank you for taking time in joining the conversation.
Russell Michell	Monday 04 October 2010 12:01:58 am Hi Chris, You are certainly correct in as far as running multiple "sites" off a single install isn't trivial. I spent months figuring it out and have got it nailed. What's worse is the number of different ways there are of doing it and no authoritative documentation explaining the procedure. One point where you are perhaps not 100% with is with separate logging. If you employ the extension-siteaccess method, where each extension is a new "site", you simply edit the site.ini for each one and ensure you edit the LogDir settings for each, so you have a nice logging dir hierarchy under var/log/<your_site>/error.log (for example) see here: http://doc.ez.no/eZ-Publish/Technical-manual/4.x/Reference/Configuration-files/site.ini/FileSettings There are of course decisions to be made about multiple databases. I went for a single DB and multiple extensions which is working well. I used a single DB because the sites were related and shared the use of the same custom-tags. So changing the value of a setting that a custom-tag in another site relies on, means it is updated everywhere it is used, regardless of which site it's in. I'm not sure what you mean about having to alter a class for an extension. If you're talking simple design extensions, then there is no need for separate classes. If you want to have some specific OO functionality called from each extension, think of the problem differently: Why not create a separate extension soley for this class and in the classes logic, differentiate between siteaccesses on that level instead - if that makes sense? Cheers Russ Russell Michell, Wellington, New Zealand. We're building! http://www.theruss.com/blog/ I'm on Twitter: http://twitter.com/therussdotcom Believe nothing, consider everything.