Important: The list demand is not part of the cache hash 

Description 

The program list redirects a filter submission to a URL carrying the selection (Feature: Program filter selections have a URL). The page such a URL shows is page-cached like any other - the list itself is not cacheable and is rendered into it on every request - and the page cache identifier contains every argument the cache hash covers. With the demand in the hash, the redirect would hand out a valid hash for any combination of categories and sorting a visitor cares to submit, each one a page cache entry of its own.

The extension therefore excludes the demand of its plugin, tx_academicprograms_programlist, from the cache hash in its ext_localconf.php:

$GLOBALS['TYPO3_CONF_VARS']['FE']['cacheHash']['excludedParameters'][] = '^tx_academicprograms_programlist[demand]';
Copied!

The leading ^ makes the entry a prefix, so every argument below demand is excluded. Every filter URL of the list shares one page cache entry, and still carries a cHash, over the action and controller arguments.

Behind the route enhancer the extension ships (Important: The route enhancer declares no default sorting), the sorting is part of the path and the route maps action and controller: the URLs carry no cHash at all, and each of the six sorting paths is a page cache entry of its own, because the page cache identifier contains the route arguments of the path.

Impact 

  • The setting is installation-wide, and added to whatever the installation configures itself. It names the demand of this plugin and nothing else.
  • Arguments below demand need no cHash, also with $GLOBALS['TYPO3_CONF_VARS']['FE']['cacheHash']['enforceValidation'] switched on, which it is in every new installation. A URL that carries the action or controller argument still needs one.
  • The exclusion depends on nothing in the cached page reading the demand: the list action is not cacheable, and no other part of the page may take it from the URL either - a link with addQueryString = untrusted , for example, would carry the demand of whoever filled the page cache entry. A project that registers the list action as cacheable has to remove these entries again, and every filter URL shared until then that carries a cHash answers with a 404 afterwards: the hash was computed without the demand, and $GLOBALS['TYPO3_CONF_VARS']['FE']['pageNotFoundOnCHashError'] is on by default. The URLs behind the shipped route enhancer carry none; they keep rendering, and answer with a 404 only with $GLOBALS['TYPO3_CONF_VARS']['FE']['cacheHash']['enforceValidation'] switched on, as it is in every new installation.
  • A URL whose cHash was computed with the demand in it and that carries the action or controller argument as well, as every URL UriBuilder::uriFor() builds does - one a project's own redirect after the POST produced, or a link a template built with demand arguments - fails the cache hash check after the update and answers with a 404, $GLOBALS['TYPO3_CONF_VARS']['FE']['pageNotFoundOnCHashError'] being on by default. Links a template builds get the new hash on their next rendering; bookmarks of such URLs do not.
  • A plugin namespace changed with view.pluginNamespace is not covered.