Per filter headers, whiteboards and fragment caching

It turns out that fragment caching really doesn’t play nicely with
optional headers generated by the likes of the typo:lightbox
filter. I’m not entirely sure about whether the workings of
whiteboards are quite right either.

So, until I’ve worked out what’s going on, I shall be removing
fragment caching. The file based page caching should continue
to work though.

So, I’m giving textfilters and whiteboards a long hard look. Right
now, we’re using class methods on the textfilter, but I think a better
approach would be to instantiate them on a per request basis. The idea
being that you use the same instance to format the contents of a page
and then query the textfilter instances for required headers etc.

This might be the first step to a callback based API for Typo
extensions, but I’m making not promises.

Out of curiosity, how will page caching work any better with extra
headers? It doesn’t store any HTTP headers at all on disk, even
content-type.

Scott

“Scott L.” [email protected] writes:

Out of curiosity, how will page caching work any better with extra
headers? It doesn’t store any HTTP headers at all on disk, even
content-type.

Not HTTP headers, but the contents of the section of the
page. All I’ve turned off is the caching of filter output, we’re still
doing action caching by default.