[TYPO3-core] RFC: fixed bug 4575: Changes in alternative page language does not clear cache

Ernesto Baschny [cron IT] ernst at cron-it.de
Fri May 11 17:06:29 CEST 2007

Dmitry Dulepov wrote: on 11.05.2007 16:00:

> Ernesto Baschny [cron IT] wrote:
>> I like the change, but I think that modifying $table and $uid can be
>> dangerous, as we call a hook later (clearPageCacheEval and
>> clearCachePostProc) that gets $table and $uid as input. So if there is a
>> hook out there that wants to handle something on a cache-clearing on
>> specific page_language_overlay's, it will no longer work.
>> So +1 if you modify it not to change $table/$uid anymore, or convince me
>> that this is not a problem at all. ;)
> I do not see problem with it because hook receives exacly the data that
> was used for clearing cache. In my opinion it would be wrong to clear
> cache for one record and call hook with another :)

That is true, but then we have to see what use-case are being handled
with that hook.

Do we have any way of finding an extension in TER that makes use of a
specific hook? After all, most hooks are there because "someone"
requested them...

There should be a "registry" of hooks where we can keep track on which
hook was added for which extension / person.

> <offtopic>
> This is what I did not like about a hook in tcemain. When "delete"
> command is executed for page in draft workspace, there can be many
> changes. But hook is called only for original record. So it is
> impossible to process/preserve other records without duplicating logic
> from tcemain in a hook.
> </offtopic>

I think it depends on what the hook is intended to do. If this is
properly documented (e.g. "will be called with the original record, even
if this is not really the one that was changed"), I see nothing bad
about it. If there is need for a hook to process all affected records,
there should simply be another hook or an API where the hook can get
that information from.


More information about the TYPO3-team-core mailing list