[TYPO3-core] RFC: Bug 4581: Duplicate entry on cache_pagesection on reloading twice

[Michael Stucki]

I didn't get any more feedback from Ernesto nor anyone else except Oliver.

I spent quite a lot of time while working on this patch, so I'm quite
certain that it does what it promises. If we encounter troubles in RC1,
then we easily know where they come from...

Any other +1?

Attached are both patches again. The first one is mandatory, the _post one
might be useful, but I tend to skip it (see comment below).

Branches: Still Trunk only

- michael

Michael Stucki wrote:

> Hi Ernesto,
> 
> sorry for the late response. I would be happy if you can investigate this
> a little more...
> 
>> This doesn't seem to be working. I still get the "duplicate entry"
>> problem, having config.no_cache=1 in my TypoScript. At the point you
>> reach line 358 of class.t3lib_tstemplate.php, $GLOBALS['TSFE']->no_cache
>> is set to "0" in my situation.
> 
> This is true. I didn't point that out in my first mail:
> 
> | 1. cache_pagesection is only written when the template parser is started
> | 
> | 2. the template parser is only started if $TSFE->config is not an array
> | 
> | 3. $TSFE->config is only set if the following condition matches:
> | 
> | if ($this->all && !$this->no_cache && !$this->headerNoCache())  {
> | 
> | 4. $this->all = the template of this condition combination exists in the
> | cache
> 
> If you are arriving without &no_cache=1 and if the admin panel doesn't
> turn it off either, then you will start with no_cache=0 until the template
> has been parsed (class.tslib_fe.php, line 1885).
> 
> So your request will try to load the template, then start the parser
> (because it was not in the cache), and write it back, because it still
> thinks that no_cache is disabled.
> 
> I didn't think about this situation before, but you are right. Attached is
> a _post patch which could be added to the one from yesterday. It just
> parses the config sections of the template and checks if no_cache needs to
> be enabled already. After all, this will only affect the condition around
> the UPDATE/INSERT queries for cache_pagesection...
> 
> However, it will cost a little bit of parsetime, that's why I'm not sure
> if it's really worth all the hassle. It was rather one more very
> interesting excercise for me to understand how everything works inside...
> :-)
> 
>> Note that I didn't set no_cache in the $_GET headers, but have it set in
>> my TS-setup. Maybe this hasn't been parsed at that point?
> 
> Exactly.
> 
> - michael

-- 
Use a newsreader! Check out
http://typo3.org/community/mailing-lists/use-a-news-reader/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: skip_cache_pagesection.diff
Type: text/x-diff
Size: 4533 bytes
Desc: not available
Url : http://lists.netfielders.de/pipermail/typo3-team-core/attachments/20070204/fc309602/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: skip_cache_pagesection_post1.diff
Type: text/x-diff
Size: 1194 bytes
Desc: not available
Url : http://lists.netfielders.de/pipermail/typo3-team-core/attachments/20070204/fc309602/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: skip_cache_pagesection_w.diff
Type: text/x-diff
Size: 3400 bytes
Desc: not available
Url : http://lists.netfielders.de/pipermail/typo3-team-core/attachments/20070204/fc309602/attachment-0002.bin