[TYPO3-core] RFC: #9599: [felogin] Enable Caching "USER" instead of "USER_INT"

Martin Kutschker masi-no at spam-typo3.org
Tue Jun 30 09:28:34 CEST 2009


Michael Stucki schrieb:
> Steffen Kamper schrieb:
>>>> For me the whole USER stuff makes no sense. The only point in having a
>>>> form cached is when the form is not on its "landing page", ie when you
>>>> have a small "login box" on every page.
>>>
>>> Exactly. So if you have a login box included in the navigation,
>>> you'll end up with at least one USER_INT object on every page.
>>
>> why not simply the old way, adding
>> <input type="hidden" name="no_cache" value="1" />
>>
>> then the object can be USER without any problems.
> 
> Because it is the wrong attempt. This will work fine without using
> no_cache, so let's avoid it please.
> 
> May someone explain me the problem that Masi mentioned, please?

The situation is like this:

If you have a FORM and the form result on one page (implemented by a
single plugin) then you need a USER_INT. If you start with a USER you
cannot switch back to USER_INT no matter what TS conditions you have.

Now typo3.org and many others want to have a "login box" on *every* page
of their site. As the form action redirects to another page they
naturally want a USER object.

For this situation they have over-optimized the plugin. IMHO it'd be
simple for them to set the type USER into the TS configuration. If the
"login box" is embedded in the layout it will be hard-coded anyway.

Another simple solution is to provide another plugin (without CE) only
for that purpose. This would avoid complicated TS conditions (which IMHO
will only slow down rendering and blow up the cache).

Perhaps it's also possible with the plugin code by the USER/USER_INT
switches. Or maybe you can use a URL with a cHash as form action that
makes the plugin render itself als USER_INT.

Masi


More information about the TYPO3-team-core mailing list