TYPO3 Core

keyword:cache

Related: http://bugs.typo3.org/view.php?id=6108

The no_cache parameter could be restricted in that way, that it only works, if a BE user is logged in. Then the preview mechanism keeps working and the parameter can still be used for debugging during development.

Hi Elmar, yes I totally agree with you. And I even think that this will be an easy change.

However, the rather difficult step before is to provide good documentation on how to work without no_cache, etc. We should not change anything before this is ready.

You already wrote a few blog posts on that subject - so if you don't mind, you could probably help me to write a chapter for the Inside TYPO3 + Core API documentation?

- michael

Hello Michael,

I could contribute such documentation. But my solution is to use 2 plugins, a USER plus a USER_INT. It would be much smarter and more simple to explain, if the same extension could be used as USER and as USER_INT. Then you don't have to seperate the code and you don't need to bother with different designators for the parameter arrays.

The problem is, that in tslib_pibase you also have to do different settings for USER and USER_INT, so that you can't switch it from outside alone. There are two reasons for this internal setting:

1.) The no_cache paramter itself.
2.) The triggering of the checkCHash.

1.) The no_cache parameter shall be removed anyway. This setting will not be needed any more.

2.) From my point of view the checkCHash trigger is also a superflous concept. A cHash could be checked automatically whenever if it comes in. So the decision to cache, would be done in the moment the cHash is generated by an extension. ("Single point of control", DRY). For sure it would require thorough testing with the most popular extensions before doing this step.

An alternative to the removement of the requirements for internal USER/USER_INT configuration would be, to automatically do the internal settings based on the external.

Direction:

function isUSER() {
return (bool) $this->conf['userFunc'] == 'USER';
}

userFunc value will never be USER or USER_INT

I did make some extensions wich call themselves as USER_INT to output a part of their content (like username, or user-permissions), and the best way i did found is to add a propretie like $copiedConf['userintCallback'] = true; and to check it.

But another problem appear : for each USER_INT displayed by this way, the plugin object is instanciated, so references between objects (if you use many objects) could be wrong. The solution i've found is to use a "wrapper" plugin class wich ensure that the real plugin object will instanciated only once (per plugin record of course)

By the way pibase has really bad linking functions : cHash is not always generated, and depens on the ugly proprety "pi_USER_INT_obj", that's why I use tx_pplib2 class instead of tslib_pibase.

If somebody want to read an example, i can attach latests revisions of pp_forum (wich is not on the TER for now) and of pp_lib

By the way I agree with Elmar about the cHash : it always have to be valid (That's why i created pp_chashchecker ^^)! The only little problem is for USER_INT plugins wich will create many identical cache versions if they output links with valid cHash... (see bug #17251)

TSo this is the current state of my "cHash solution specification":

a) Automatically check and cache, if a cHash has been sent. Else deliver the
default page from cache. Drop the rule, to request cHash from inside USER
objects completely.

b) The typolink function has to sign all parameters, that are not to be
tunneld, by a cHash. Only this part of the link is used for caching.

c) A mechanism is needed to assign the tunneled parameters to the typolink
function and the tunneling mechanism of the link itself.

d) The unsigned, tunneld parameters are only offered to USER_INT (during
marker replacement phase).