ViewCaching makes problems when changing priority

Monday 03 July 2006 8:46:39 am

I have VIewCaching enabled on my site end when I change the priority in a folder (form the eZ admin interface) the change is not reflected in the user site. The same thing happens when I change the sort criterium. This is because the view cache isn't cleared for the user site when I change priority or sort criterium. I tried putting this:

[VersionView]
AvailableSiteDesignList[]=user_siteacces

in content.ini.append.php but it doesn't help. Is this a bug or a feature? Is there a way to make eZ clear the cache when priority or sort criterium is changed?

--
Nothing is impossible. Not if you can imagine it!

Hubert Farnsworth

Wednesday 05 July 2006 6:38:36 am

I have exactly the same problem.

I've upgraded EZ 3.8.0 -> 3.8.1. And now, when I publish article from admin interface, usersite viewcache is not updated. So I have to clear all viewcache manually.

Is it a new bug or some mistake in config files?

Wednesday 05 July 2006 7:41:18 am

I did a little research and this is what I found in eZ 3.8.1...

The only place where AvailableSiteDesignList is used is in function fetchSitedesignList() in "ezlayoutfunctioncollection.php" file. And the fetchSitedesignList() function is appears only in this files:

"function_definition.php"
"ezlayoutfunctioncollection.php"

So this is confusing, how can this setting have any effect on caching?

--
Nothing is impossible. Not if you can imagine it!

Hubert Farnsworth

Wednesday 05 July 2006 8:21:03 am

Section in content.ini.append.php:

[VersionView]
AvailableSiteDesignList[]=user_siteacces

no longer working with Smart View Cache. Now you must use in site.ini.append.php:

[SiteAccessSettings]
RelatedSiteAccessList[]=user_siteaccess

Not documented thing, strange....

And again

[ContentSettings]
PreViewCache=enabled

working bad - content cache is generated, but file has no real content, only headers.

Wednesday 05 July 2006 9:02:51 am

@#$%^!!!... It's not good, that new version has too lot of undocumented changes...

Pawel, thank you very much for your help. After I've defined RelatedSiteAccessList array, my problem was solved.

Thursday 06 July 2006 12:28:38 am

No Lukasz, what you mentioned wasn't the problem here. My problem was with AvailableSiteDesignList and not with AvailableSiteAccessList. The problem was that setting AvailableSiteDesignList no longer works with smart cache, and RelatedSiteAccessList should be user like Pawel said.

And this problem that you mentioned maybe isn't a bug, maybe is made on purpose, you could check this before reporting it as a bug.

P.S. Is there any setting like RelatedSiteAccessList that works based on site design and not on site access? Something like AvailableSiteDesignList but that works in newer versions with smart cache? This could be usefull for clearing cache when several siteaccess use the same design so that you don't have to write them all ini ini files, but just the design directory.

--
Nothing is impossible. Not if you can imagine it!

Hubert Farnsworth

Thursday 06 July 2006 1:53:39 am

Some more information, this was change with introduction of new mulitlingual feature:

View-cache
``````````

With the new multi-language feature a view-cache is no longer made for one
specific language but for a prioritized list of languages, this means that the
directory storage must change. We replace the singular language code and
site-designs with the name of the site-access  e.g. if we have the languages
*nor-NO*, *eng-GB* and *ger-DE* in the site-access *no* we get::

  var/cache/no/full/

We also optimize the cleaning code to use the *glob* call with *GLOB_BRACE*
expansion, e.g::

  glob( "var/cache/{admin,mysite}/{full,line}/1/5/15-*.cache",
        GLOB_BRACE );

This change means that it now uses *AvailableSiteAccessList* and
*RelatedSiteAccessList* (*site.ini*) when cleaning up caches.

Code which I paste above it is used by cache mechanism when you update priorities from admin interface. For me this is bug and missing information in update doc. Since users who update from 3.6/3.7 should specify
RelatedSiteAccessList[]=admin
RelatedSiteAccessList[]=mysite

because AvailableSiteAccessList (should be use when RelatedSiteAccessList is not definied) is not used in that code because condition is always true and cache is cleared only for current siteaccess not for all.

Personal website -> http://serwatka.net
Blog (about eZ Publish) -> http://serwatka.net/blog

Thursday 06 July 2006 3:36:10 am

AvailableSiteAccessList is always definied in the override/site.ini.append.php. So even if user did not definie RelatedSiteAccessList then proper code should use AvailableSiteAccessList. Then view cache will be clear.

Personal website -> http://serwatka.net
Blog (about eZ Publish) -> http://serwatka.net/blog

Thursday 06 July 2006 5:16:15 am

Yes Marko and RelatedSiteAccessList is used only by cache mechanism.

Bug was fixed by Jan K.

Index: kernel/classes/ezcontentcache.php
===================================================================
--- kernel/classes/ezcontentcache.php	(revision 16367)
+++ kernel/classes/ezcontentcache.php	(working copy)
@@ -319,9 +319,9 @@
         // Figure out the siteaccess which are related, first using the new
         // INI setting RelatedSiteAccessList then the old existing one
         // AvailableSiteAccessList
-        if ( $ini->hasVariable( 'SiteAccessSettings', 'RelatedSiteAccessList' ) )
+        if ( $ini->hasVariable( 'SiteAccessSettings', 'RelatedSiteAccessList' ) &&
+             $relatedSiteAccessList = $ini->variable( 'SiteAccessSettings', 'RelatedSiteAccessList' ) )
         {
-            $relatedSiteAccessList = $ini->variable( 'SiteAccessSettings', 'RelatedSiteAccessList' );
             if ( !is_array( $relatedSiteAccessList ) )
             {
                 $relatedSiteAccessList = array( $relatedSiteAccessList );

Personal website -> http://serwatka.net
Blog (about eZ Publish) -> http://serwatka.net/blog

Friday 18 August 2006 6:18:25 am

Put this:

RelatedSiteAccessList[]=user_siteacces

in your site.ini under [SiteAccessSettings]. Of course, replace "user_siteacces" with the real name of your user siteacces. And do this for every siteacces you want the cache to be cleared (you don't have to put the admin siteacces here).

Another sollution would be to wait for an eZ publish release that includes this fix made by Jan K. But I doubt you really want to wait for that. :)

--
Nothing is impossible. Not if you can imagine it!

Hubert Farnsworth