Project

General

Profile

Actions

Bug #19507

closed

getCompressedTCarray hangs if no cache_hash exists

Added by Franz Holzinger about 16 years ago. Updated over 14 years ago.

Status:
Closed
Priority:
Should have
Assignee:
Category:
-
Target version:
-
Start date:
2008-10-27
Due date:
% Done:

0%

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

Description

When you call
$TSFE->getCompressedTCarray();
in a FE extension, e.g. after an Ajax call with eID parameter, then this ends up in an error message.

t3lib_cache_exception_NoSuchCache: A cache with identifier "cache_hash" does not exist. in /var/www/html/trunk/t3lib/cache/class.t3lib_cache_manager.php on line 77

It should continue instead, if no cache_hash has been found.

(issue imported from #M9648)


Files

error.html (3.76 KB) error.html Administrator Admin, 2008-10-27 13:37
0009648.patch (4.38 KB) 0009648.patch Administrator Admin, 2008-11-22 12:05

Related issues 2 (0 open2 closed)

Related to TYPO3 Core - Bug #19802: eID Ajax results in Fatal errorClosedOliver Hader2009-01-12

Actions
Is duplicate of TYPO3 Core - Bug #19694: Initialization of new caching framework breaks some eID scriptsClosedDmitry Dulepov2008-12-12

Actions
Actions #1

Updated by Dmitry Dulepov about 16 years ago

Have you tried using install tool to check/update databases? It appears that your cache_hash has old format and therefore it is failing.

Actions #2

Updated by Franz Holzinger about 16 years ago

This happens under the most current 4.3-dev.

The DB 'Update required tables COMPARE' has been done successfully.

Actions #3

Updated by Dmitry Dulepov about 16 years ago

This was described in the mailing lists. Current database analyzer cannot change cache table as necessary but there is a separate bug report and RFC about it. cache_hash must exist on the system, just like pages or tt_content. It is required. If it does not exist, the system will not work and it is not a bug.

The best thing that you can do right now is to drop this table and let Install tool recreate it later.

This bug report can be closed.

Actions #4

Updated by Oliver Hader almost 16 years ago

This specific issue is not related to the database changes. When calling an eid script the cache handlers/managers are not yet registered and thus the cache is not found.

I attached a patch that does the following:
  • move initialization of caches to t3lib_cache::initialize()
  • add new method to eidtools to initialize all caches (cache_pages, cache_hash, cache_pagesection)

@Franz Koch: Please test this patch and before calling "$TSFE->getCompressedTCarray()", please make sure that "tslib_eidtools::initCaches()" was called

Actions #5

Updated by Dmitry Dulepov almost 16 years ago

I think it will be better if cache initialization is moved to TSFE. Currently many existing extensions are borken when they try to instantiate TSFE. 4.3 is not compatible in this way.

Actions #6

Updated by Stig Nørgaard Færch almost 16 years ago

Seems like this is related to our mysql-server crashing with this error message:
InnoDB: Unable to assign a new identifier to table `kk3s/cache_pages`.

Actions #7

Updated by Franz Holzinger almost 16 years ago

@Oliver:
I have added these lines at the beginning of my eid script. And this fixes the problem.

-------------
$typoVersion = t3lib_div::int_from_ver($GLOBALS['TYPO_VERSION']);
if ($typoVersion >= 4003000) {
require_once(PATH_tslib.'class.tslib_eidtools.php');

// ***************************
// Initializing the Caching System
// ***************************
$TT->push('Initializing the Caching System','');
tslib_eidtools::initCaches();
$TT->pull();
}
Actions

Also available in: Atom PDF