TYPO3 Core

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

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).

• 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

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

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.

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.

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 tag in the cache.

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.

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.

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