[Typo3-dev] Empty cHash problem

Ernesto Baschny [cron IT] ernst at cron-it.de
Thu Oct 6 18:03:55 CEST 2005


Elmar Hinz schrieb am 06.10.2005 17:03:

>> Empty cHash problem. Empty cache is never a problem, as it can be
>> filled. :) And if its empty, the empty cHash is not a problem, its just
>> a problem if the cache already filled!

> Either this is not precise enough or tells something else then the
> article. There isn't a problem when the cache is already filled in the
> article. The problem is filling the empty cache with the right stuff.

If the cache is empty, it will be filled by the first attempt to request
the given page. The problem is if we fill the cache, but the content is
not really meant to be cached for that combination of parameters. In the
article, this results in:

<quote>
It is not only confusing but altogether impossible to see the archive
list because its place in the cache is taken by the article until
someone clears the cache!
</quote>

So clearly this is implying that the cache was filled improperly, which
is what I tried to "sum up" below:

>> The problem, to sum up:
>>
>> When generating the page that will be cached where we have our USER
>> plugin. The plugin will output something based on the piVars (e.g.
>> display the detail view of the current record). If we don't take any
>> precaution, our output will always be cached too by TYPO3 (this is why
>> we are an USER object!). So the next requests, regardless of the
>> parameters, would display the same output as the first request, thus
>> making our parameters useless! Only the first request after clearing the
>> cache wins. 

> So far it is right. Here we still have only one cache for all views.

>> We have to avoid that in the first call already, by only
>> allowing TYPO3 to cache the output if we are sure that the parameter
>> combination is something can be checked against a valid cHash.

> Here seems to be a gap in your explenation. You still haven't created
> different chaches for different combinations of parameters.

That's exactly the problem: if we allow TYPO3 to cache our output and we
are an USER object, we won't get a second chance to generate other
output for different views if we don't tell TYPO3 that we have different
views (by linking to our second view with a cHash parameter, see
previous thread). So every call to the same page that contains our
plugin will return the same content, regardless of the parameters. This
is why we (as a plugin writer) need to make sure that the cHash is being
checked (if present, TYPO3 will check it on its own, if not present or
empty, TYPO3 needs the plugins to inform if a checking is needed, which
is what this section of the article is about).

> By the way. Is there a special table for caching views with additional
> parameters or is it the same table as for the old id + type combination?
> Which tables are they? Wich fields in the tables?

Its the same table, as the cache already uses different combination of
parameters for caching the same page (e.g for different types). The
table is cache_pages, the content is in the HTML field. You will have a
huge configuration array in cache_data, which unserialized will also
tell you (amongst other) the piVar-parameters that were used to create
this cache request. But what TYPO3 uses to see which record to get is
the md5-hash of a series of information (fe_group, parameters, type,
language, etc), which will be compared against the "hash" field.

>> The article section is devoted to the case when cHash is EMPTY, so this
>> case does not apply.

> That is a quite philisophical answer.

Hehe, not really, because if cHash is not empty, the plugin writer
doesn't have to do anything, because TYPO3 will already take care of it.
This is why it's not really part of this section of the article, which
deals with stuff that a plugin writer needs to do, and why its so.

> That is exactly my thesis. The effect would be the same. Even if there
> isn't an empty cHash but an invalid one.

Right, just that with invalid ones the plugin writer won't even be
bothered with it, which is not the case if there is no, or an empty
cHash value.


Cheers,
Ernesto

PS: hey, first posting of Kasper after 6 months absense of typo3-dev!
Welcome back, Kasper! :)




More information about the TYPO3-dev mailing list