Bug #19757
closed
t3lib_cache_exception_NoSuchCache: A cache with identifier "cache_pages" does not exist
Added by Ingo Schmitt almost 16 years ago.
Updated about 6 years ago.
Description
I've done a upgrad (4.2 -> 4.3.dev) based on the current SVN Branch. After the update I get in the FE the above written Error message.
Debugging this issue, in tslib_fe it seams, that the exception t3lib_cache_exception_NoSuchCache could not be catched and the default cache could not be created, therfore no cache init could be done.
When putting t3lib_cache::initPageCache(); to line 625, everything works fine.
(issue imported from #M10044)
i read 3 times after i got it :D
should read:
that the exception t3lib_cache_exception_NoSuchCache could not be "catched" and the default cache could not be created, therfor no cache init could be done.
it's in tslib_fe::initCaches
try {
$this->pageCache = $GLOBALS['typo3CacheManager']->getCache(
'cache_pages'
);
} catch(t3lib_cache_exception_NoSuchCache $e) {
t3lib_cache::initPageCache();
$this->pageCache = $GLOBALS['typo3CacheManager']->getCache(
'cache_pages'
);
}
where catch doesn't work for your case.
I ask myself why t3lib_cache::initPageCache(); isn't called anyway, as there is also a try/catch for it. May be this is the reason that we have encapsulated try/catch
This error will happen if database tables have old (4.2) format. So this error is expected in Ingo's case. He should have updated database tables using Install tool.
...and he should have asked in the mailing lists before writing a bug reported because it is not really a bug...
Hi Dmitry,
no, he did that all. He even deleted the cache tables before doing the COMPARE. So tables are correct.
Hi,
After doing an upgrade from 4.2.6 to current trunk (5364) I have a similar symptom. I cannot access any backend module. e.g., page module. I see the tree but when I click on a node, the right pane shows nothing.
My php logs are full of
PHP Fatal error: Call to a member function getCache() on a non-object in /data/www/data/share/typo3_src-trunk/t3lib/class.t3lib_befunc.php on line 1232
Compatibility is set to 4.3, DB is 100% OK (compare shows nothing left to do). FE rendering is OK but I must admit that I have caching issues with EXT:felogin which I have not on my development environment (same trunk revision).
I found the problem using debug_backtrace(). This was a weird configuration problem with a mix-up from 4.2.6 and trunk: my local directory of extension I used for the website on trunk was symlinked to another location where the BACK_PATH pointed to a 4.2.6 TYPO3. This lead to some files being included from trunk, other from 4.2.6
Ingo, as Xavier's problem was due to some inconsistent setup, you are the only person with this issue.
Is this still reproducible for you in current 4.3-alpha3? Might this eaccelerator bug mentioned by Steffen be the culprit?
Hi, I can confirm this to happen with a clean trunk install (rev. 5586) using eAccelerator. Switching to xCache (or using no cache at all) made the problem go away.
Hi, I've no this issue on last trunk (5586) and eAccelerator 0.9.5.3
Resolved, no change required.
This was very likely a problem with old eaccelerator versions (below 0.9.5.2), see http://eaccelerator.net/ticket/242
Please reopen if this issue still exists with new eaccelerator / php versions.
- Status changed from Resolved to Closed
Also available in: Atom
PDF