Project

General

Profile

Actions

Feature #16684

closed

option to exclude certain pages from cache control headers being set

Added by Steffen Müller about 18 years ago. Updated over 11 years ago.

Status:
Closed
Priority:
Should have
Category:
-
Target version:
-
Start date:
2006-11-03
Due date:
% Done:

0%

Estimated time:
PHP Version:
Tags:
Complexity:
Sprint Focus:

Description

In cases of improper setting of SYS_LASTCHANGE, it might be useful to disable cache control headers on certain pages.
For example, this is the case for pages containing tt_news frontend plugins. Creating a fresh news item inside a sysfolder does not update the SYS_LASTCHANGED field of those pages with frontend plugin. The result is fresh news, but unchanged cache control headers.

Appended patch extends class_tslib_fe.php, adding the following option to CONFIG section of TS:
config.sendCacheHeaders_excludePages= [comma-seperated list of page-id]

(issue imported from #M4458)


Files

bug_4458.diff (1.04 KB) bug_4458.diff Administrator Admin, 2006-11-03 01:39
Actions #1

Updated by Steffen Müller about 18 years ago

If someone tells me how to patch doc_core_tsref, I will take care of that.

Actions #2

Updated by Michael Stucki about 18 years ago

Hi Steffen,

just write down which changes are needed, and where. I'll take care of TSref when the patch is ready.

Actions #3

Updated by Michael Stucki about 18 years ago

I forgot: Please send me the text first, I want to post it together with the patch RFC.

Actions #4

Updated by Steffen Müller about 18 years ago

Property:
sendCacheHeaders_excludePages

Data type:
integer (page id) /list

Description:
List of pages that should be excluded from cache-control headers (see: sendCacheHeaders). The headers sent for these pages are:
Cache-Control: private
This option makes it possible to prevent client side caching (browser cache, proxy) on certain pages without disabling the page cache.
For example, if you have two pages (e.g. uid 17 and 58) with plugins displaying the content of another sysfolder, changing the content in the sysfolder does not update the timestamp of the those pages. Using cache-control headers, your changes then might be ignored by browsers. The solution is to exclude these pages with:
config.sendCacheHeaders_excludePages = 17,58

Default:

Actions #6

Updated by Marc Bastian Heinrichs about 18 years ago

Would be a nice feature, but I think for example for tt_news it isn't the right approach, because most news pages are the most requested pages.

I didn't posted an feature request to Rupi yet, but there is the posibilty to set $GLOBALS['TSFE']->register['SYS_LASTCHANGED'] when rendering the news, what would change the cache control headers.

Actions #7

Updated by Steffen Müller about 18 years ago

At the moment I use it as a workaround for tt_news, but this does not mean it's the only purpose. Think about webserver logging, which now can be forced for certain pages.

I agree, that this should be handled by the extension, but we have >1000 FE extensions, which probably need better timestamp handling. Outdated SYS_LASTCHANGED fields has never been a big problem , but with cache-control headers, it is. I propose to discussion this in the dev-list.

Maybe we should alter the example in the doc_core_tsref:
Description:
List of pages that should be excluded from cache-control headers (see: sendCacheHeaders). The headers sent for these pages are:
Cache-Control: private
This option makes it possible to prevent client side caching (browser cache, proxy) on certain pages without disabling the page cache.
For example, if you have two pages (with uid 17 and 58) you can exclude these pages with:
config.sendCacheHeaders_excludePages = 17,58

Actions #8

Updated by Steffen Müller almost 18 years ago

Hi Michael,
will this one make into 4.1?
It's working for me in various installations.

Actions #9

Updated by Alexander Opitz over 11 years ago

  • Category deleted (Communication)
  • Status changed from Accepted to Needs Feedback
  • Target version deleted (0)
  • PHP Version deleted (4)

As this report is very old, is the handling in newer TYPO3 CMS Versions (like 6.0/6.1) more like you expect it?

Actions #10

Updated by Steffen Müller over 11 years ago

please close.

Actions #11

Updated by Alexander Opitz over 11 years ago

  • Status changed from Needs Feedback to Closed

Closing as requested.

Actions

Also available in: Atom PDF