Project

General

Profile

Actions

Bug #27677

closed

Caching Framework: use t3lib_cache_frontend_VariableFrontend as fallback frontend

Added by Xavier Perseguers over 13 years ago. Updated over 11 years ago.

Status:
Closed
Priority:
Should have
Category:
Caching
Target version:
-
Start date:
2011-06-24
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
4.6
PHP Version:
5.3
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

The wiki tells us to define a 'frontend' in our caching framework configuration:

$TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_myext_mycache'] = array(
    'frontend' => 't3lib_cache_frontend_StringFrontend',
    'backend' => 't3lib_cache_backend_DbBackend',
    'options' => array(
        'cacheTable' => 'tx_myext_mycache',
        'tagsTable' => 'tx_myext_mycache_tags',
    ),
);

And an article by Dmitry does not:

$TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_myext_mycache'] = array(
    'backend' => 't3lib_cache_backend_DbBackend',
    'options' => array(
        'cacheTable' => 'tx_myext_mycache',
        'tagsTable' => 'tx_myext_mycache_tags',
    ),
);

Dmitry is right here and here is why:

An integrator is asked to configure the caching framework of an extension s/he installs. S/he has to know the backend s/he wants to use, it may be DB, memcached, ... and as such defining the 'backend' is correct. BUT the frontend defines what is stored within the cache backend, the "format" of the input that will be cached. The integrator should not have to dig into the code to know the format, this is the responsibility of the developer that should simply instantiate the frontend with the format he needs. It could be clever and still let the integrator choose another frontend (for whatever reason) but forcing the integrator to define the frontend (even if it's copy/paste from the extension documentation how to activate/configure the caching framework), does not make sense.

Problem is shown, e.g., when invoking scheduler task "Caching framework garbage collection (scheduler)". If a caching configuration is incomplete for a given extension (missing 'frontend'), the task will crash with:

Execution of task "Caching framework garbage collection (scheduler)" failed with the following message: Class does not exist

as an empty class name is passed to t3lib_div::makeInstance() and this throws an error when trying to instantiate this "class" by reflection.


Related issues 2 (0 open2 closed)

Related to TYPO3 Core - Bug #27675: Execution of task fails with "Class does not exist"Closed2011-06-24

Actions
Has duplicate TYPO3 Core - Bug #23694: [Caching framework] Improve error message if no frontend was defined for core cachesClosedChristian Kuhn2010-10-08

Actions
Actions #1

Updated by Mr. Hudson over 13 years ago

Patch set 1 of change Iaf59864d86483e2d0a08b92c54dad579e2f81347 has been pushed to the review server.
It is available at http://review.typo3.org/2905

Actions #2

Updated by Xavier Perseguers over 13 years ago

  • Status changed from New to Resolved
  • Assignee set to Xavier Perseguers
  • Target version set to 1281
  • % Done changed from 0 to 100
Actions #3

Updated by Xavier Perseguers over 12 years ago

  • Status changed from Resolved to Closed
Actions #4

Updated by Ernesto Baschny over 11 years ago

  • Target version deleted (1281)
Actions

Also available in: Atom PDF