[TYPO3-ect] 4.1.0: Request parameters could not be validated

[Elmar HInz]

Hi Steffen,

> I think the confusing comes from deciding: make link with or without cache 
> (link to an USER object with(ot) cache, link to a USER_INT object with(out) 
> cache - does the combinations really make sense ?)

The simple rule of thumb: Only USER as target need a cHash in the link
because only those will be cached in different versions.

For the USER_INT plugin as target the presence of a cHash is of no
harm itself. *BUT* the problem occures if you send a cHash with it and if
$GLOBALS['TSFE']->reqCHash(); is set at the same time. The same page
would be cached many times for the different cHashes. This may blow
up your database if the source of the parameters has a huge amount of
possible combinations. That is why we should avoid to send a cHash to
USER_INT objects in this special cases.

The perfect solution would be an "Intelligent Link" Intellilink (R), that
discovers itself if the target is a USER or a USER_INT. For different
reasons that is practically impossible to do. So you need to supply the
link by hand with this information. If you switch the target from USER to
USER_INT you maybe like to change all links to it. See the previous
paragraph.

> Another point, which makes it difficult for me:
> A page has several objects. If there is at least one USER-Object, the Page 
> has to be cached with cHash. But this could not be decision of a single 
> object. And this is the point where all comes really complex. I still wonder 
> how it works, because it works, but many developers using "dirty tricks" to 
> prevent the cache like adding a no_cache-param.
 
Combinations is the most difficult field. There are usecases where
combinations make sense. But there are also combination that don't give
sense. I give 3 examples:

1.) USER_INT without parameters: 

Maybe it the USER_INT plugin contain a clock are counter and are not
controlled by parameters at all.

2.) Details page:

You need the result set to be a USER to be indexed for search. There can
by timely changing context lists that are dependent of the ID of the 
the details data set page. They can be USER_INT. They share the designator
and the one and only parameter.

3.) Now you have scenario 2 and you want to sort the context lists. Here
you come to the limits of TYPO3. To sort you have to send different
combinations of parameters. To cache the details page for the search
engine you need a cHash. The combination of both would result in a very
large number of cached pages. Your database would be blown. Here we would
need caching of plugins instead of whole pages. That would solve all
headaches at once. 

Regards

Elmar