Project

General

Profile

Actions

Bug #22412

closed

cache_treelist is out of date

Added by Steffen Gebert about 14 years ago. Updated over 13 years ago.

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

0%

Estimated time:
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)


Files

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

Related issues 5 (0 open5 closed)

Related to TYPO3 Core - Bug #19621: getTreeList causes duplicate entry sql errorClosedRupert Germann2008-11-18

Actions
Related to TYPO3 Core - Feature #18852: Speed up tslib_cObj->getTreeList by caching its resultsClosedIngo Renner2008-05-26

Actions
Related to TYPO3 Core - Bug #22236: cache_treelist does not take FE users into accountClosedDmitry Dulepov2010-03-04

Actions
Related to TYPO3 Core - Bug #22552: No cache entry in cache_treelist after endtime arrivedClosed2010-04-30

Actions
Related to TYPO3 Core - Bug #26161: cache_treelist is out of date when using starttimeResolved2011-04-21

Actions
Actions #1

Updated by Steffen Gebert about 14 years ago

I'm NOT using the caching framework...

Actions #2

Updated by Christian Kuhn about 14 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.

Actions #3

Updated by Steffen Gebert about 14 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?

Actions #4

Updated by Dmitry Dulepov almost 14 years ago

4.4 and 4.3 (revisions 7579 & 7580)

Actions

Also available in: Atom PDF