Blacklist parameter is a reactive way to ignore parameters sent by traffic sources (GA, Facebook, other social networks).
At the same time, Drupal has well working mechanism of determining what URL parameters are important for the request - it's response cache contexts.
I.e. if a page contains a view with exposed filters, each filter's machine name will be present in response cache contexts list as `url.query_args:`
- Add new configuration parameter 'filter_response_context', defaulting to FALSE
- When this parameter is set to TRUE, check if request contains parameters that are not expected by response, and ignore response in this case.
Write the patch
No UI changes
Internal method generateUrlOrPathToRegister() gets additional parameter $response
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | 3030681-7.patch | 3.32 KB | webflo |
| #6 | 3030681-6.patch | 3.26 KB | webflo |
| #4 | 3030681-4.patch | 3.31 KB | valthebald |
| #3 | 3030681-3.patch | 5.51 KB | valthebald |
| #3 | interdiff-3030681-2-2.txt | 1.93 KB | valthebald |
Comments
Comment #2
valthebaldComment #3
valthebaldMore fine-grain query string check
Comment #4
valthebaldAfter testing the filtering approach for a couple of days, it makes sense to throw away ignored parameters (i.e. not queue response for clearing), so the check happens in the same way as blacklist,
Comment #5
lisa.rae commentedMarking Needs Work, patch failed to apply to both dev and rc versions
Comment #6
webflo commentedI'm going to try it out in a project.
Comment #7
webflo commentedFixed PHP error, url_to_store not initialized
Comment #8
ericgsmith commentedAre we sure this premise is true? I'm just trying this patch on an existing project and don't see this.
I've got a view with exposed filters, which exposes a taxonomy term with the url query param "type". When I apply this patch and debug the cache contexts I see the more generic
url.query_argscontext is present but nothing specific for type - there is nourl.query_args:type. I don't know if that is optimized away at some point or if views isn't adding it - I have not debugged further. With the current patch its then leaves type in the$query_paramsand the returnsNULL, incorrectly skipping this page from the registry.I need to test this on a clean install / check where cache contexts get optimized as query param garbage is a huge problem for me too / this module and am super interested in solutions to this problem.
Comment #9
ericgsmith commentedOn further investigation - I don't think views is smart enough to add all the specific contexts as the issue summary describes, I can only see it adding the full url context here https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/views...