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

Description 

The project lists redirect a filter submission to a URL carrying the selection (Feature: Project 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, sorting and active state a visitor cares to submit, each one a page cache entry of its own.

The extension therefore excludes the demand of its plugins, tx_academicprojects_projectlist and tx_academicprojects_projectlistsingle, from the cache hash in its ext_localconf.php:

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

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

Impact 

  • The setting is installation-wide, and added to whatever the installation configures itself. It names the demand of these plugins 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 answers with a 404 afterwards: its cHash was computed without the demand, and $GLOBALS['TYPO3_CONF_VARS']['FE']['pageNotFoundOnCHashError'] is on by default.
  • 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.