TYPO3 Core

• t3lib/class.t3lib_tstemplate.php: Just removing redundancy, no functional change => cleaner
• typo3/sysext/cms/tslib/class.tslib_pagegen.php: Recreation of cHash if necessary
• typo3/sysext/cms/tslib/class.tslib_content.php: Change order of addQueryParams and linkVars (addQueryParams is more specific than linkVars)

Hi Oliver,

good idea! This adds a very useful functionality to make all links "safe" :-)

Some comments:

1. While looking at your patch I noticed that $val is actually holding keys, so it should be renamed here:
- foreach ($linkVarArr as $val) {
+ foreach ($linkVarArr as $key) {

2. We can discuss about this one :-)
- $GLOBALS['TSFE']->linkVars.= $value;
+ $GLOBALS['TSFE']->linkVars .= $value;

3. When recreating the cHash, you have this line:
+ if ($GLOBALS['TSFE']->linkVars && $createCHash) {

I suggest that you always first check for local variables before accessing other classes. It may be a speed gain of just 0.001ms, but since we have such situations quite often, it may add a lot of overtime in total.

But all in all I like this change! Didn't test it yet, though...

I agree. I'll change the this you mentioned and provide a new patch.

• renamed $val to $var and $tmpVal to $tmpVar (it is a variable of linkVars and thus not a value or a key, is it?)
• Reduced direct writing and reading to $GLOBALS['TSFE']->linkVars

cHash should not be in linkVars list ! It needs to be generated for each link !

@Popy no-lastname-given: Guess what this patch is doing! ;-)

0005010_3.patch does work for me (several linkVars - single and array GET vars applied) like a charm and avoids serious performance issues that resulted in non cached pages with linkVars before.

Thank you very much!

If you consider this patch to merge, could you have a look at #17238 please? The topic is not really the same but the same lines of code are affected - so it might be reasonable to do so.

This really does solve a lot of problems. But if using RealUrl with the setting for variable bypass like this:

'1' => array (
'GETvar' => 'L',
'valueMap' => array (
#'en'=>'0',
'de' => '1',
'fr' => '2',
),
'noMatch' => 'bypass',
#'valueDefault' => 'en',
),

it still won't work propably.
Cause &L=0 will create a different cHash than no 'L' Parameter at all.

Please consider this: http://lists.netfielders.de/pipermail/typo3-dev/2007-August/024671.html

I'm not sure anymore if this feature is really useful. If you implement this, then the caching routine needs to be improved. I have currently no idea how this should work without introducing a separate GET parameters for cache and check hash...

- michael

Hi,

is there any reason why the change from patch 0005161 is not incuded in this patch even if it affects the same lines?

File class.tslib_content.php, line 5221 :
[code]
} elseif ($conf['useCacheHash']) {
[/code]

change to:
[code]
}
if ($conf['useCacheHash'] && trim($GLOBALS['TSFE']->linkVars.$addQueryParams)) {
[/code]

This change makes a lot of sense for me. As it enables the use of cHash even when $addQueryParams are empty and $GLOBALS['TSFE']->linkVars is set. This is very usefull if for e.G. if a typoLink changes a linkVar like "L". So it will include the new "L"-Value in the addQueryParams. So both, the $GLOBALS['TSFE']->linkVars and the $addQueryParams should be checked for the cHash.

Are there any misconceptions in my point of view?

greetings

Sareen

Yes, the reason is that this bug report existed before bug #17120 and that they address different problems.

Is this bug still present in Typo3 4.2.1?
I experience same behaviour, but the patch seems not to work there.
Any ideas?

The Sponsorship is when the bug is fixed in the core.

I want to point out some additional issues with cHash and caching that are closely related to this issue:

1)
After changing the L parameter the cHash of the previous L parameter is taken. The cHash after the language switch therefore is wrong. The page with the wrong cHash therefore is not cached. – this is just as it is explained in this bug 0005010
If RealURL is used the same phenomena occurs even if cHash is not visable in the URL

2)
These two links point to the same page:
(a) http://localhost/t3421/index.php?id=6&L=1
(b) http://localhost/t3421/index.php?id=6&L=1&cHash=b5e9312461
(a) is generated by the menu, (b) is generated by:
[code]
typolink.parameter.data = page:uid
typolink.additionalParams = &L=1
typolink.addQueryString = 1
typolink.addQueryString.exclude = L,id,cHash,no_cache
typolink.addQueryString.method = GET
typolink.useCacheHash = 1
typolink.no_cache = 0
[/code]
“useCacheHash” is necessary, cause addQueryString = 1 might carry additional params.
Result: Both URL addresses lead to two identical pages in the cache.
If RealURL is used the problem obviously is solved. Only one URL is generated and only one page is in the cache.

3)
If we have same scenario just with L=0 param the result is three URL addresses fort he same page:
(a) http://localhost/t3421/index.php?id=6
(b) http://localhost/t3421/index.php?id=6&L=0
(c) http://localhost/t3421/index.php?id=6&L=0&cHash=7fc4118ac9
Just as 2) version (a) and (b) are cached separately to version (c). So again there are two identical pages in the cache.
But this time the problem is not solved by installing RealURL. Only one URL is generated, but the cache is not cached at all.

I just reported this as a seperate bug #19003 as it might be a independent problem

Your first point (about wrong chash with L parameter) is related to bug #17070

I kow, the entire bug 0005110 is related to bug 0005117
There are quite some bugs about cHash and Caching around.