Bug #36461
closedNo Caching with Extbase Plugin when "resolving" controller and action with realurl
0%
Description
As soon as I add the controller and action into realurl config, the page is not cached anymore (and therefore not indexed by indexed_search).
It does not matter if I add the controller and action to fixedPostVars, e.g.
'fixedPostVars' => array(
'_DEFAULT' => array (
/*
array(
'GETvar' => 'tx_myext_pi1[controller]',
'valueMap' => array(
'Product' => 'produkt',
),
’noMatch’ => ‘bypass’,
),
array(
'GETvar' => 'tx_toco3myext_pi1[action]',
'valueMap' => array(
'overview' => 'overview',
'detail' => 'detail',
),
’noMatch’ => ‘bypass’,
),
),
or 'postVarSets' - the page is not cached anymore. Other extension Variables I added to the postVarSets work without problems, e.g.
'cat' => array (
array(
'GETvar' => 'tx_myext_pi1[category]',
'lookUpTable' => array(
'table' => 'tx_myext_domain_model_category',
'id_field' => 'uid',
'alias_field' => 'title',
'addWhereClause' => ' AND NOT deleted',
'useUniqueCache' => 1,
'useUniqueCache_conf' => array(
'strtolower' => 1,
'spaceCharacter' => '-',
),
),
),
IMPORTANT: at first glance everythings to be fine. The resolving works and the pages and contents are shown like requested BUT the page is not cached anymore.
Is this a bug or am I doing something completely wrong?
To clarify: with caching I mean the standard TYPO3 page caching - not the realurl caching!
I thought this is an realurl issue and added the following bug: http://bugs.typo3.org/view.php?id=18481 which also was confirmed by one user. As you can see in the Bugtracker, Dmitry asked me to resolve this on extbase side, that's why I post it here again.
Updated by Jan Kiesewetter over 12 years ago
I can confirm this issue.
The admin-panel reports an cHash problem.
This is the output of the admin-panel if default action (list) is called without extbase parameters (from the menu):
The incoming cHash "ede237831fbbae721d30bffc4e44dcfa" and calculated cHash "ae541f40806fc69f595681cafa31473f" did not match, so caching was disabled. The fieldlist used was "encryptionKey"
If the same action is called within the extension the fieldlist contains all parameters but calculating fails also:
The incoming cHash "8a4628d52782ffecd2be2c0de843b193" and calculated cHash "25e2a1a436ba9e59ee7b05fcada244d3" did not match, so caching was disabled. The fieldlist used was "encryptionKey,tx_extension_plugin[action],tx_extension_plugin[controller],tx_extension_plugin[model]"
I don't know why the model is part of the fieldlist in the list action.
It looks like there goes something wrong with the fields for the calculation.
In my show action the caching works fine.
Updated by Ingo Pfennigstorf over 12 years ago
- Category changed from Extbase: Core to Extbase: Cache
- Status changed from New to Needs Feedback
This may be expected, because if a wrong cHash is provided the plugin is not cached.
Did you try the RealURL cHash parameters?
Updated by Jan Kiesewetter about 12 years ago
What do you mean with "RealURL cHash parameters"?
I have set
'enableCHashCache' => true,
Updated by Jan Kiesewetter about 12 years ago
may it is a problem with the
'defaultToHTMLsuffixOnPrev' => true,
setting
@ Christian Ehret i think this setting is also set in your environment as i can see on your site ;) .
Updated by Norbert Sendetzky over 11 years ago
I can confirm this issue too.
There are two reasons why pages are not cached:
- Setting 'defaultToHTMLsuffixOnPrev' to something else than the default value
- Using optional parameters in the URL
A partly working workaround is to use "fixedPostVars" instead of "postVarSets" like:
$TYPO3_CONF_VARS['EXTCONF']['realurl']['_DEFAULT']['fixedPostVars']['_DEFAULT'][] = array(
'GETvar' => 'arc[f-catalog-id]',
);
instead of
$TYPO3_CONF_VARS['EXTCONF']['realurl']['_DEFAULT']['postVarSets']['_DEFAULT']['arcavias'][] = array(
'GETvar' => 'arc[f-catalog-id]',
);
Using a default parameter with the "valueDefault" option doesn't help.
Updated by Alexander Schnitzler over 11 years ago
- Target version set to Extbase 6.2
Updated by Anja Leichsenring over 11 years ago
- Target version changed from Extbase 6.2 to Extbase 6.3
Updated by Norbert Sendetzky over 11 years ago
Norbert Sendetzky wrote:
There are two reasons why pages are not cached:
- Setting 'defaultToHTMLsuffixOnPrev' to something else than the default value
- Using optional parameters in the URL
There's a workaround available if you are using optional parameters: It only fails if an empty string is used for the optional parameter. If you set "emptySegmentValue" in the RealURL configuration to e.g. a dash (-), it works fine. Maybe the problem is that some code can't distinguish between an empty string and no parameter and generates the wrong cHash.
Norbert
Updated by Peter Niederlag over 11 years ago
Are all of your controller/actions cached(please post your ext_localconf.php)?
One simple case of failure is a "non-cached" extbase action. If you link to it inside extbase a cHash will be appended. However a cHash for a non-cached action is "nonsense" and will confuse realurl.
In case of non-caching actions make sure you use the noCacheHash=1 param in viewHelpers when linking to them.
Updated by Norbert Sendetzky over 11 years ago
Peter Niederlag wrote:
Are all of your controller/actions cached(please post your ext_localconf.php)?
No, not all my actions are cached but I had the same problem if only one cached plugin/action was placed on a single page. In this case it should work according to your explanation.
Norbert
Updated by Alexander Opitz about 10 years ago
- Project changed from 534 to TYPO3 Core
- Category changed from Extbase: Cache to Extbase
- Status changed from Needs Feedback to New
- Target version changed from Extbase 6.3 to 7.0
- TYPO3 Version set to 6.2
- Is Regression set to No
Updated by Mathias Schreiber almost 10 years ago
- Target version changed from 7.0 to 7.1 (Cleanup)
Updated by Benni Mack over 9 years ago
- Target version changed from 7.1 (Cleanup) to 7.4 (Backend)
Updated by Susanne Moog over 9 years ago
- Target version changed from 7.4 (Backend) to 7.5
Updated by Benni Mack over 5 years ago
- Status changed from New to Needs Feedback
To confirm this: This only happens with RealURL enabled but is actually a cHash calculation issue?
We introduced the requireCacheHash option for extbase plugins to overcome this in v8, and in v9 (with a patched RealURL version) I could not reproduce this anymore.
Can somebody give me some more insights please?
Updated by Riccardo De Contardi over 5 years ago
- Status changed from Needs Feedback to Closed
No feedback since the last 90 days => closing this issue.
If you think that this is the wrong decision or experience the issue again and have more information about how to reproduce your problem, please reopen it or ping me.
Thank you and best regards