Feature #17862

Make excludeCHashVars work

Added by Nikolas Hagelstein almost 13 years ago. Updated about 7 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2007-11-29
Due date:
% Done:

0%

Estimated time:
PHP Version:
4.3
Tags:
Complexity:
Sprint Focus:

Description

class.tslib_fe.php consiste of the excludeCHashVars property but it isnt implemented yet.

There is the need to exclude certains GET varv from chash in order to make a
USER/USER_INT "switch" work where the USER_INT's output depends on get parameters.

Sample:

class tx_myext_pi1 extends tslib_pibase {
var $prefixId = 'tx_myext_pi1';
var $scriptRelPath = 'pi1/class.tx_myext_pi1.php';
var $extKey = 'myext';
var $pi_checkCHash = true;

function main() {
....
$TS['conf']='COA_INT';
$TS['conf.']['10']='USER';
$TS['conf.']['10.']['userFunc']='tx_myext_pi1->renderUncachedBacklink';
$content = $this->renderCachedDetails($this->piVars['uid']);
$content .= $this->cObj->cObjGetSingle($TS['conf'],$TS['conf.']);
function renderUncachedBacklink() {
return '<a href=" .$this->piVars['heavyVariatingBackUrlThatShouldExcludedFromChash'] . '">back</a>';
}
function renderCachedDetails($uid) {
// return some database content depending on $uid -> inCluded to CHash.
}
}

}
(issue imported from #M6857)


Files

cHashTunnel_v2.patch (6.45 KB) cHashTunnel_v2.patch Administrator Admin, 2007-11-30 12:00

Related issues

Related to TYPO3 Core - Bug #17115: Wrong &chash values should trigger an errorClosedMathias Schreiber2007-03-12

Actions
#1

Updated by Dmitry Dulepov almost 13 years ago

cHash is supposed to have all vars in it by design. Otherwise cache will not work properly.

#2

Updated by Oliver Hader almost 13 years ago

I ran into the same problem some months ago and created a "cHashTunnel" patch for my own purpose. It was configured in TS like this "config.cHashTunnel = tx_myext_pi2,tx_myotherext_pi1" (see attached patch just for comparison).

Imagine the following situation:
  • Two plugins are on the same page
  • tx_myext_pi1 (USER)
  • tx_myext_pi2 (USER_INT)
  • now a link that keeps existing params of pi1 and adds new uncached params for pi2 is sent, e.g.
    --> index.php?id=123&tx_myext_pi1[param]=first&tx_myext_pi2[param]=second&cHash=1234abcd
    --> the calculated cHash value should only be against the USER plugins, thus agains pi1
    --> the values for pi2 shall not modify the cHash, because only the content of USER_INT changes and should not be cached at all as new entry in the cache table
#3

Updated by Oliver Hader almost 13 years ago

The attached cHashTunnel patch is FYI and was created against some 4.1 version. So, let's talk about this and maybe merge things.

#4

Updated by Ernesto Baschny almost 13 years ago

Oliver, that sounds cool and I think it is very interesting addition to 4.2.

But it won't solve the problem when loading an *_INT that depends on a specific parameter from inside a USER object (e.g. rendering the "back link" like the original poster to this bug report did), because it seems to depend on the "prefixId" for deciding which parameters to ignore.

So couldn't we have it "more generic" in that we can set a list of additional GET parameters to ignore in cHash calculations? It seems that someone once thought about it, when adding "excludeCHashVars" class variable to tsfe (was there in 3.7 already!), but was this was never implemented.

Some TypoScript like

config.excludeCHashVars = tx_ttnews[backPid],tx_cal[page_id],tx_cal[last_view]

could configure that behaviour. Static templates of extensions could add more stuff to this variable if needed.

#5

Updated by Steffen Kamper almost 13 years ago

i discussed this with Dmitry, and conclusion was that you can't exclude piVars without having wrong cache entries.
e.g. eleminating the backpid cause that you get displayed a page with a wrong backlink (because it's cached once)

piVars from USER_INT shouldn't included by default. (or does they?)

i don't see a proper solution as the cached page really presents the combine of the piVars for the view.

The best solution anyway would be not to cache pages but objects, but this is a total new concept.

#6

Updated by Ernesto Baschny almost 13 years ago

piVars from USER_INT shouldn't included by default.

Steffen, this isn't possible, because TYPO3 currently has no way to get the list of "piVars from USER_INT". Which is why I proposed that every extension that makes use of them lists them (in TypoScript), so that those could be excluded from cHash calculation.

The problem with wrong cache entries won't arise, because only USER object are cached. The backlinks would be generated by an USER_INT, which would simple be a <!--INT...--> tag in the cache.

#7

Updated by Steffen Kamper almost 13 years ago

Yes, you're right with this. I thought about looking for pivars, eg tx_myext_pi1 -> USER or USER_INT, if USER, add it, but this may fail also if you use techniques with USER_INT in a USER-Extension. So the list of exclude make sense.

But don't forget the Users (or the devs) - they didn't knew in the past how to set up proper caching, do you think they will know how to decide which vars are excluded? Also in TS Admins may define vars and don't know what the result is. This could make it very difficult and may result in wrong caching.

With well knowledge this technique could be very helpful indeed.

#8

Updated by Ernesto Baschny almost 13 years ago

If some developer don't know how to set up proper caching I don't really care. There are enough resources to learn about it. If an admin doesn't understand some setting, it should be left alone. If a developer doesn't understand the concept, he should not use it. If he does, well, then it is not "our" fault, is it?

I care more about bringing in possibilities that are missing which developers with very well thought caching requirements need and which are not possible currently. This issue here is one of them, as the combination of USER and USER_INT on a same page (or even in one plugin) is a very important aspect for programming extensions that scale.

#9

Updated by Nikolas Hagelstein almost 13 years ago

I made an extension implementing similar thing.
http://typo3.org/extensions/repository/view/nh_exclchashvars/0.0.2/

It works quite similar to olivers "hashtunnel" except for the fact that it enables you to exclude any parameter not just the "whole" prefix Id.

Just add something like :
$TYPO3_CONF_VARS['FE']['excludeCHashVars'][]= 'tx_nhasset_pi2[backPath]';
to your extensions localconf.

Oliver: the main problem about hiding a whole "prefix_id" from chash is, that a plugin could consist of a user/user_in swicht . In that case you may want to hide all parameters affecting the "user_int" part. (See my initial sample).
cheers,
NIkolas

#10

Updated by Alexander Opitz over 7 years ago

  • Category deleted (Communication)
  • Status changed from New to Needs Feedback
  • Target version deleted (0)

As this report is very old, is the handling in newer TYPO3 CMS Versions (like 6.0/6.1) more like you expect it?

#11

Updated by Alexander Opitz about 7 years ago

  • Status changed from Needs Feedback to Closed

No feedback for over 90 days.

Also available in: Atom PDF