Last modified: 2014-06-20 17:41:08 UTC
Currently, pages that transclude special pages aren't cached at all. I see the benefit to this (that special pages should always be "live"), but at the same time, we can probably find a smarter way of handling caching that doesn't need to completely disable it. This will likely become a bigger issue as more and more special pages are given the ability to be transcluded.
(In reply to comment #0) > Currently, pages that transclude special pages aren't cached at all. I see > the > benefit to this (that special pages should always be "live"), but at the same > time, we can probably find a smarter way of handling caching that doesn't > need > to completely disable it. This will likely become a bigger issue as more and > more special pages are given the ability to be transcluded. I've been thinking it would be good to have a method of the SpecialPage class, getTranscludeCacheTime(), which by default returns 0 (Or perhaps it should return 1 hour or something small. On a busy page, even a very small cache time would probably make a huge performance difference), which people could override as appropriate. I would also suggest that the RequestContext passed to the special page for any special page which doesn't disable cache, doesn't include the current user/etc, but instead includes an anonoymous user, and the page rendering language for the language. That way we won't have user specific things poisioning the cahe (For example, {{special:Recentchanges}} will currently show block links if you have block rights. This would be bad if the page was uncached)
Change 140945 had a related patch set uploaded by Jackmcbarn: Make transcluded special pages not disable cache in miser mode. https://gerrit.wikimedia.org/r/140945
