ViewCaching makes problems when changing priority

«

Previous topic

|

|

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

Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2014 eZ Systems AS (except where otherwise noted). All rights reserved.

eZ debug

Timing:	Jan 31 2025 06:26:48
Script start
Timing:	Jan 31 2025 06:26:48
Module start 'layout'
Timing:	Jan 31 2025 06:26:48
Module start 'content'
Timing:	Jan 31 2025 06:26:48
Module end 'content'
Timing:	Jan 31 2025 06:26:48
Script end

Main resources:

Total runtime	0.0148 sec
Peak memory usage	2,048.0000 KB
Database Queries	3

Timing points:

Checkpoint	Start (sec)	Duration (sec)	Memory at start (KB)	Memory used (KB)
Script start	0.0000	0.0057	588.8047	151.2266
Module start 'layout'	0.0057	0.0025	740.0313	37.1406
Module start 'content'	0.0082	0.0050	777.1719	98.6953
Module end 'content'	0.0132	0.0015	875.8672	41.9922
Script end	0.0147		917.8594

Time accumulators:

Accumulator	Duration (sec)	Duration (%)	Count	Average (sec)
Ini load
Load cache	0.0024	16.5614	14	0.0002
Check MTime	0.0012	7.8671	14	0.0001
Mysql Total
Database connection	0.0011	7.4421	1	0.0011
Mysqli_queries	0.0025	16.7246	3	0.0008
Looping result	0.0000	0.0824	1	0.0000
Template Total	0.0011	7.7	1	0.0011
Template load	0.0009	6.2142	1	0.0009
Template processing	0.0002	1.4849	1	0.0002
Override
Cache load	0.0007	4.4853	1	0.0007
General
dbfile	0.0002	1.6658	8	0.0000
String conversion	0.0000	0.0614	4	0.0000
Note: percentages do not add up to 100% because some accumulators overlap

Templates used to render the page:

Usage	Requested template	Template	Template loaded	Edit	Override
1	print_pagelayout.tpl	<No override>	extension/community/design/community/templates/print_pagelayout.tpl
Number of times templates used: 1 Number of unique templates used: 1

Time used to render debug report: 0.0001 secs