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

[Ernesto Baschny [cron IT]]

Martin Kutschker wrote: on 30.06.2009 09:28:

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

I don't think this is true. If the condition matches, the original cache
entry (the one with the USER object) won't match anymore and another
rendering process will start (where the plugin is USER_INT). So you get
two cached pages depending on the conditions, one with the USER and
another with the USER_INT object. That is the solution of this patch.

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

Can you explain what you mean with "over-optimized"?

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

Don't think it will slow down rendering, and it will blow up the cache
if the target page for the FORM is the current page. If the target is a
central "login" page, it will generate the same amount of cached pages.

Your simple solution also won't work, because the login-form has to be
transformed into a "Logout-Form" as soon as the user is logged in. And
also, if you don't have a specific target-page, your login-box also has
to show login-errors (wrong password, etc), so it has to somehow
transform into a USER_INT as soon as a login-attemt is made.

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

In my eyes that has the same side-effects as the solution that has been
submitted already.

Cheers,
Ernesto