ViewCaching makes problems when changing priority

Next topic

Author	Message
Marko Žmak	Friday 18 August 2006 6:53:28 am I forgot to mention that you have to put: RelatedSiteAccessList[]=user_siteacces in site.ini of your admin siteacces, not in user. And clear all the caches after this. -- Nothing is impossible. Not if you can imagine it! Hubert Farnsworth
Andrew Kelly	Friday 18 August 2006 7:22:24 am Nope, still no change. And the patch from Jan K. was already in my version (3.8.3 rev. 16460). So, where do we go from here? ViewCaching worked brilliantly last week. Since I've upgraded from 3.7.x to 3.8.3 it doesn't. Publishing content in the admin siteaccess does not delete any caches at all. Anybody?
Marko Žmak	Monday 21 August 2006 12:47:59 am Have you by any chance change the CacheDir in site.ini? I know I had some problems when I change it. I don't know anything else that I could suggest you. You could try to inspect the eZ code. It helped me to find bugs several times. -- Nothing is impossible. Not if you can imagine it! Hubert Farnsworth
Andrew Kelly	Monday 21 August 2006 2:16:54 am I did a standard upgrade, namely: - unpack 3.8.3 - copy from my site to 3.8.3 - - design/public_access - - design/admin_access - - settings/override/* - - settings/siteaccess/public_access - - settings/siteaccess/admin_access - - var/* Nothing has changed in var, nor in any of my ini files. This thread has taught me that the clearing of view caches has changed from 3.7.x to 3.8.x, with site.ini->SiteAccessSettings->RelatedSiteAccessList being used instead of content.ini->VersionView->AvailableSiteDesignList. I understand, however, that for the sake of backwards compatibility, AvailableSiteDesignList is still functional in the cascading ini overwrites. I have altered my site to use BOTH RelatedSiteAccessList AND AvailableSiteDesignList, so that if, for whatever reason, the array isn't properly filled with the information in RelatedSiteAccessList, at least correct and usefull config data will be available. I have also verified that all folders in var/public_access/cache/content are mod 777 and that all files within are 666. Everything I am reading and understanding is telling me that when I publish content in the admin interface, at the same time all content view caches should be deleted. This is still not happening. If I now have to read source code to find out why... par for the course, I guess. Could you (or anybody who knows) please tell me where I should start reading and/or the specific chain of method calls that lead from content publishing to view cache deletion? Andy
Kristof Coomans	Monday 21 August 2006 2:43:01 am Hello Andy The cache clearing process starts in the content/publish operation, more specific eZContentOperationCollection::clearObjectViewCache (<i>kernel/content/ezcontentoperationcollection.php</i>). It calls eZContentCacheManager::clearContentCacheIfNeeded (<i>kernel/classes/ezcontentcachemanager.php</i>). Finally you will end up with eZContentCache::cleanup ((<i>kernel/classes/ezcontentcache.php</i>) where the cache files will be cleared by calling eZFSFileHandler::fileDeleteByWildcard (<i>kernel/classes/clusterfilehandlers/ezfsfilehandler.php</i>). I would turn on debug output and debug redirection and conditional debug for the clustering feature: debug.ini[GeneralCondition]kernel-clustering=enabled. Then put debug statements where needed and publish/modify a test object. Good luck! independent eZ Publish developer and service provider \| http://blog.coomanskristof.be \| http://ezpedia.org
Marko Žmak	Monday 21 August 2006 3:18:06 am Maybe this helps: I DIDN'T change my eZ version, I left it 3.8.1 and I added the RelatedSiteAccessList[] setting and it now works for me. Maybe the patch isn't working as it should? Try isnpecting this file: kernel/classes/ezcontentcache.php at the place where the patch is applied. But DON'T do this if you're not familiar enough with PHP. -- Nothing is impossible. Not if you can imagine it! Hubert Farnsworth