Symlink to the eZ Publish var directory, a good idea?

On most of my sites, I tend to adopt the following folder layout:

/web/sites/$ find . -maxdepth 2 -name www\* -o -name var -ls | tr -s ' ' | cut -d ' ' -f 11-14
./wwwnewdesign/var -> ../var/
./www44/var -> ../var
./www2012.5/var -> ../var
./www -> wwwnewdesign

As you can see, www (the Apache document root) and www<version>/var are symlinks. The main idea behind this organization is to ease upgrades from an eZ Publish version to another, after upgrading on my developer machine and uploading the code to /web/sites/<version> , I just have to change the symlinks on the disk and I'm done!

Cache issues

I know that some others are using a quite similar setup but Nicolas and Arnaud seem to encounter caching issues with it. At first, I answered that this is working as expected for me, but a while after, I discovered that I also have some cache issues on Planet eZ (mainly cache-block not being expired) while the same setup on does not seem to be affected.

Actually, this comes from the configured file handler. eZ Publish instance is configured with the eZFS2FileHandler while Planet eZ was configured with eZFSFileHandler . And there is a big difference between those file handlers: when a cache file is outdated, eZFSFileHandler will try to remove it while eZFS2FileHandler just sets a specific last modified time to mark it as expired (this is the base of the stale cache mechanism). In addition, a protection had been added in eZ Publish (and it's enabled by default) to not let it remove files that are outside of the eZ Publish directory, and of course, this is the case with the symlink layout above. So the cache issue is not a bug, it's a feature ;-)

So if you want to use this kind of setup, you have to configure your eZ Publish instance with the eZFS2FileHandler . But keep in mind, that eZFS2FileHandler is still a bit experimental and that 2012.4 and 2012.5 community releases were affected by this bug, so you'd better apply this patch to keep your images!