Bug #22412

cache_treelist is out of date

Added by Steffen Gebert over 9 years ago. Updated about 9 years ago.

Status:
Closed
Priority:
Should have
Category:
Caching
Target version:
-
Start date:
2010-04-10
Due date:
% Done:

0%

TYPO3 Version:
4.3
PHP Version:
5.2
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

I just noticed the following weirdness and I think I already had this 1-2 times:

cache_treelist contains an entry for one pid and its subpages, which is out of date, as it doesn't contain one subpage, which is visible, thus has to be included.

Maybe the cache is not correctly updated when changing <i>hidden</i> state of pages. User did the following:
1 Insert
2 Hide page: No
3Editing
4 Hide page: Yes
5 Editing
6 Hide page: No

The cache_treelist entry has the timestamp (and state before step 6).

So when changing <i>hidden</i> state, cache_treelist of the complete rootline must be outdated.

I hope I find the time to check this, soon.
(issue imported from #M14052)

T3X_bug_14052-0_0_0-z-201004101621.t3x (6.03 KB) Administrator Admin, 2010-04-30 11:47

14052_v2.diff View (1.65 KB) Administrator Admin, 2010-04-30 11:50


Related issues

Related to TYPO3 Core - Bug #19621: getTreeList causes duplicate entry sql error Closed 2008-11-18
Related to TYPO3 Core - Feature #18852: Speed up tslib_cObj->getTreeList by caching its results Closed 2008-05-26
Related to TYPO3 Core - Bug #22236: cache_treelist does not take FE users into account Closed 2010-03-04
Related to TYPO3 Core - Bug #22552: No cache entry in cache_treelist after endtime arrived Closed 2010-04-30
Related to TYPO3 Core - Bug #26161: cache_treelist is out of date when using starttime New 2011-04-21

History

#1 Updated by Steffen Gebert over 9 years ago

I'm NOT using the caching framework...

#2 Updated by Christian Kuhn over 9 years ago

cache_treelist is not implemented in the caching framework, so this doesn't make a difference. There is a second bug with cache_treelist, I related it.

#3 Updated by Steffen Gebert over 9 years ago

Thanks for enlightenement, Christian!

The problem lies in the following code in <i>tx_cmstreelistCacheUpdate::determineClearCacheActions</i>:

switch ($updatedFieldName) {
  case 'pid':
    // page moved
    $actions['allParents']    = true;
    $actions['uidInTreelist'] = true;
  break;
  case $GLOBALS['TCA']['pages']['ctrl']['enablecolumns']['disabled']:
  case $GLOBALS['TCA']['pages']['ctrl']['enablecolumns']['fe_group']:
  case $GLOBALS['TCA']['pages']['ctrl']['delete']:
  case 'extendToSubpages':
  case 'php_tree_stop':
    // page hidden / unhidden / deleted / extendToSubpages set
    // php_tree_stop and/or FE groups set
    $actions['uidInTreelist'] = true;
  break;
...

uidInTreeList can only work, when the currently processed uid IS in the tree list of the cache entry. But when unhiding a page, it is NOT inside, so we can't find the corresponding record and delete it. Instead we have to set action to allParents to remove all the cache entries for parent pages.

Patch will come soon, I'm a bit undecided on the other options, yet. Maybe some are affected by the same bug?!?

fe_group: Page was access restricted (-> not in the cache?) and restriction is removed (-> we can't find the cache entry?)
extendToSubpages: apply access restrictions also to subpages.. have to think about this
php_tree_stop: what's that?

#4 Updated by Dmitry Dulepov over 9 years ago

4.4 and 4.3 (revisions 7579 & 7580)

Also available in: Atom PDF