This site has been archived and you can no longer log in or post new messages. For up-to-date community resources please visit

eZ Community » Forums » Setup & design » Using different VarDir settings on...

Using different VarDir settings on different siteaccesses

Using different VarDir settings on different siteaccesses

Tuesday 22 November 2011 10:50:55 pm - 1 reply

A follow-up to this topic:

Is there ever a good reason to specify different values for [FileSettings] -> VarDir in site.ini.append.php for different siteaccesses?  Or is it standard practice to have a single value for VarDir in the global override of site.ini?

I tried to do this, and it seems eZ Publish is working fine with regard to using the different VarDir values for storing cached information specific to each siteaccess (such as compiled templates, cached ini settings, and so on).  But it seems to want to share the images from their old location under their original VarDir.

Specifically, all the stored images were originally under var/ezwebin_site/storage/.  After changing the VarDir on one siteaccess to var/siteaccess/mobile, I see files under var/siteaccess/mobile/cache and var/siteaccess/mobile/log, but nothing is ever apparently stored under var/siteaccess/mobile/storage, unless you create a new image using the mobile siteaccess.  All pre-existing images and image alias files previously stored under var/ezwebin_site/storage continue to be serve from there.  New images uploaded from the new siteaccess go into var/siteaccess/mobile, and their aliases are served from there, even on the non-mobile siteaccess.

I understand there is a table in the database, ezimagefile, to track the locations of these images.  Since the paths get saved in the table, they don't get updated when the siteaccess's VarDir gets changed.

However, to repeat the question, in general, 1) is it ever useful to have different VarDir directories for different siteacccesses, and 2) to connect with my earlier forum post, could it be made to work such that the generated image aliases could live under the VarDir corresponding to the siteaccess, so that different sizes could exist for the same image alias name, based on the siteaccess?

Modified on Tuesday 22 November 2011 10:52:50 pm by A Fowler

Wednesday 23 November 2011 5:48:46 am

Hello A Fowler,

I can confirm at least one of your findings. When you change the site.ini:[FileSettings] VarDir setting all original content remains in the original VarDir.


Regarding #1

Some folks customize their installation's site.ini:[FileSettings] VarDir to match a specific siteaccess naming convention. (I know cause I've had to re-add symlinks to the original var dir to restore file downloads for a site which switched site.ini:[FileSettings] VarDir settings in the middle of the site's lifespan.


Many more folks who run multiple instances of eZ Publish within a single installation (I assume) make heavy use of site.ini:[FileSettings] VarDir setting to allow for many unique databases to also store binary file content uniquely (per database) within the single installation of eZ Publish.


Also I'd like to point out a related growing effort which is to allow eZ Pubilsh to "Added possibility to store log files into subfolders".


Regarding #2

In summary I think you would have to change your image datatype (variation based on default) to provide the feature your thinking of ... as image aliases as stored per content object tree node attribute datatype handler content which stores an array of aliases, key is name of alias and value is an array of image alias image variation image file meta data (binding alias name (from settings) to a specific image variation file (for that datatype > object attribute image content, ezimagetype).


Update: Apologies, I forgot to focus on the storage in the db of this data within xml. The array I spoke of is used internally and is based on / generated from (when instantiated) the xml data fetched from the db. I got caught up in my mind thinking about another related issue I'm working on which focuses on the array I described which was why I misspoke.




You can validate this yourself by debugging  the ezimagealiashandler execution to see this (or dump and inspect the contents of an ezimage object attribute).


I hope this helps ...




Modified on Wednesday 23 November 2011 11:13:57 pm by // Heath


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

36 542 Users on board!

Forums menu

Proudly Developed with from