Allow Inbound PathProcessor's to specify that they should not be cached [#2769421]

Problem/Motivation

On one of our sites, we are using an InboundPathProcessor to have dynamic urls that redirect to a new path and set some data. Since we're also using them to set data on a user's account, we need these paths to always fire and not be cached.

Proposed resolution

The proposed solution I have is to update the RouteProvider::getRouteCollectionForRequest(Request $request) method to check if the Request object is to be cached. This can be accomplished with Request::isNoCache().

Remaining tasks

Needs Review / Input / Feedback
Tests
Documentation

Comments

Comment #1

19 July 2016 at 19:24

marcaddeo created an issue. See original summary.

Comment #2

marcaddeo CreditAttribution: marcaddeo commented 19 July 2016 at 19:28

Version:

8.1.x-dev

» 8.2.x-dev

Comment #3

19 July 2016 at 19:28

Version:

8.2.x-dev

» 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Comment #4

dawehner

German

CreditAttribution: dawehner as a volunteer and at Chapter Three commented 12 September 2016 at 07:01

This is indeed some quite valid usecase. A workaround for you could be to implement a KernelEvents::REQUEST listener instead dealing with it.

Just a random idea. For keeping BC we could make allow inbound path processors to add cacheability metadata onto the passed in request object.
An alternative could be to make \Drupal\Core\PathProcessor\InboundPathProcessorInterface::processInbound return string|InboundProcessedPath,
with InboundProcessedPath having cacheability metadata attached. With that the default implementation in \Drupal\Core\PathProcessor\PathProcessorManager could merge this metadata together and at least let you define cache tags and max-age.

Comment #5

Wim Leers

Ghent 🇧🇪🇪🇺

CreditAttribution: Wim Leers at Acquia commented 12 September 2016 at 09:58

Hm… I don't fully understand the use case yet.

Why can't you have your dynamic URLs be pointing to a controller, let that controller set data on the User entity and then redirect them elsewhere?

Comment #6

marcaddeo CreditAttribution: marcaddeo commented 3 October 2016 at 00:27

Our use case was for dynamic page branding, basically the InboundPathProcessor would processing incoming urls and look for brand names in the url, and translate that to the internal node url alias.

So /nike/products would translate to /brand/products as the internal node url alias. Inside of that path processor I'd also have something like $brand = $this->brandBuilder->buidlBrand($brandProcessedFromUrl); $this->brandManager->setCurrentBrand($brand);.

Since the path processing is being cached, this would cause subsequent views of the page to not call $this->brandManager->setCurrentBrand(...).

So basically internally the /brand/products is represented a single time as a node and can have it's data changed based on the dynamic brand placeholder in the url.

That's sort of our use case.

Though, this logic should likely be moved into an event subscriber instead.