|
Author
|
Message
|
|
Marko Žmak
|
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
|
|
Marko Žmak
|
Monday 03 July 2006 9:30:25 am
P.S. I'm using eZ 3.8.1
--
Nothing is impossible. Not if you can imagine it!
Hubert Farnsworth
|
|
Vitaly Puzrin
|
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?
|
|
Marko Žmak
|
Wednesday 05 July 2006 7:11:18 am
Just to verify, this problem didn't occur for you with eZ 3.8.0?
--
Nothing is impossible. Not if you can imagine it!
Hubert Farnsworth
|
|
Marko Žmak
|
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
|
|
Marko Žmak
|
Wednesday 05 July 2006 7:52:49 am
Further investigation leads to this... In eZ 3.7.3 AvailableSiteDesignList is used in "ezcontentcache.php" in function: cleanup( $nodeList ) but in eZ 3.8.1 there's no such function and AvailableSiteDesignList is used only in scipts I mentioned above and not in "ezcontentcache.php". Is this a bug or this change was made on purpose? If it was on purpose, what's the reason?
--
Nothing is impossible. Not if you can imagine it!
Hubert Farnsworth
|
|
Pawel Orzechowski
|
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.
|
|
Marko Žmak
|
Wednesday 05 July 2006 8:41:50 am
RelatedSiteAccessList works like a charm :) As for PreViewCache I was never found of it. It produces a big processor load when publishing an object.
--
Nothing is impossible. Not if you can imagine it!
Hubert Farnsworth
|
|
Vitaly Puzrin
|
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.
|
|
Łukasz Serwatka
|
Wednesday 05 July 2006 2:33:22 pm
Hi Guys,
if ( $ini->hasVariable( 'SiteAccessSettings', 'RelatedSiteAccessList' ) )
{
$relatedSiteAccessList = $ini->variable( 'SiteAccessSettings', 'RelatedSiteAccessList' );
if ( !is_array( $relatedSiteAccessList ) )
{
$relatedSiteAccessList = array( $relatedSiteAccessList );
}
$relatedSiteAccessList[] = $GLOBALS['eZCurrentAccess']['name'];
$siteAccesses = array_unique( $relatedSiteAccessList );
}
else
{
$siteAccesses = $ini->variable( 'SiteAccessSettings', 'AvailableSiteAccessList' );
}
Problem is with this code. "Else" is never executed that's why SiteAccessSettings[] is not used when RelatedSiteAccessList[] is empty. When update from 3.6/3.7 is done, site.ini is overwrite with 3.8.x which contains empty RelatedSiteAccessList, so the condition is true because variable exists but only current siteaccess is used in the $siteAccesses, not all. I will post bug report about this.
Personal website -> http://serwatka.net
Blog (about eZ Publish) -> http://serwatka.net/blog
|
|
Marko Žmak
|
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
|
|
Łukasz Serwatka
|
Thursday 06 July 2006 1:00:31 am
No, Marko. You have miss my point. That is true that AvailableSiteDesignList is no longer used by cache system in 3.8. But code which I paste should work as backward compatibility If I understand correct. So after upgrade instead of RelatedSiteAccessList which is empty (not defined by you) system should use AvailableSiteAccessList which aleardy defined in your site.
Personal website -> http://serwatka.net
Blog (about eZ Publish) -> http://serwatka.net/blog
|
|
Łukasz Serwatka
|
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
|
|
Marko Žmak
|
Thursday 06 July 2006 2:23:15 am
Yes Lukasz you're right. But it seems to me that the code that you pasted doesn't provide real backward compability, since AvailableSiteDesignList was based on site design, and this code uses site acces. So if users that had their designs listed in AvailableSiteDesignList, liste thoose designs in AvailableSiteAccessList or RelatedSiteAccessList will have problems since they listed design directories and not siteaccess directories. Is that correct?
--
Nothing is impossible. Not if you can imagine it!
Hubert Farnsworth
|
|
Łukasz Serwatka
|
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
|
|
Marko Žmak
|
Thursday 06 July 2006 4:46:15 am
Yes, you're right again. So the propper behaviour would be to use AvailableSiteAccessList even when RelatedSiteAccessList is defined but has 0 elements, right?
--
Nothing is impossible. Not if you can imagine it!
Hubert Farnsworth
|
|
Łukasz Serwatka
|
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
|
|
Andrew Kelly
|
Friday 18 August 2006 5:37:42 am
Sorry, all this back and forth is not helping me I'm afraid.
When my site was 3.7.6, publishing content in the admin interfaces deleted the view caches on the public side of my site.
Now my site is 3.8.3 and this no longer works.
I have only one language, eng-GB.
What must I do so that when I publish content in the admin siteaccess, view caches are cleared in the public siteaccess? A good later discussion is "why are fundamental changes like this undocumented?", but for the time being my only interest is how go I get my site to work correctly, the way it did before upgrading to 3.8.x? Andy
|
|
Marko Žmak
|
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
|
|
Andrew Kelly
|
Friday 18 August 2006 6:34:58 am
Thanks for the tip, Marko.
Unfortunately, it doesn't work. Any other ideas? Andy
|
