Feature: Partner filter selections have a URL 

Description 

The filter and sorting form of the partner list and the partner map submits by POST, and a filtered list used to be the answer to that POST: it had no URL of its own. It could not be bookmarked or shared, a reload asked to send the form again, and no link rendered inside the list could carry the selection.

Both plugins now answer the submission with a 303 See Other to the same page and plugin, carrying the selection as GET arguments:

?tx_academicpartners_list[action]=list
&tx_academicpartners_list[controller]=Partner
&tx_academicpartners_list[demand][filterCollection][categories]=3,6
&tx_academicpartners_list[demand][sortingDirection]=asc
&tx_academicpartners_list[demand][sortingField]=title
&cHash=…
Copied!
  • The URL is built from what the plugin accepted, not from the request: a category of another group, a uid no category has and the referrer and request hash fields of the form never appear in it.
  • The categories of every category type are one comma separated list, in ascending order, so one selection has exactly one URL.
  • The sorting is always part of the URL. The content element's preset categories and sorting apply only to the page URL without any list argument, so a visitor who clears a preset category keeps it cleared.
  • A GET request with those arguments renders the list exactly as the POST did before, and the form shows the selection again.
  • The selection is read from the submitted form alone. A form that posts to the URL of a filtered list replaces its selection rather than adding to it, and a POST carrying no demand of the plugin - another plugin's form on the page - is not redirected.

Nothing changes in the templates, so overridden filter templates keep working as long as they submit fields the demand knows: the redirect carries the selection the plugin accepted and nothing else. A field a project adds to its filter partial, read by a listener from the request, is lost on the redirect. The list and map actions stay non-cacheable, and the demand is not part of the cache hash, so every filter URL of a list shares one page cache entry, see Important: The list demand is not part of the cache hash.

Impact 

  • A filter or sorting submission answers 303 instead of 200. Browsers and fetch() follow it by default; JavaScript that posts the form and reads the HTML of the response itself has to follow the redirect. The redirect target carries the plugin's own arguments only: a page type, arguments of other plugins and campaign parameters of the submitted URL are not kept, so a form posted to a page type endpoint lands on the full page.
  • A project that added its own redirect after a POST, in a subclass of the controller, can drop it together with the subclass, which no longer loads in 3.0, see Breaking: The partner controller is final. The URLs that redirect produced change their cHash, see Important: The list demand is not part of the cache hash.
  • A route enhancer for these plugins must not declare defaults for the sorting: a default is left out of a generated path, so the redirect for the default sorting would end on the page URL without arguments, where the preset applies again.