Problem/Motivation
Current code:
$map = $route->hasOption('_view_argument_map') ? $route->getOption('_view_argument_map') : [];
foreach ($map as $attribute => $parameter_name) {
// Allow parameters be pulled from the request.
// The map stores the actual name of the parameter in the request. Views
// which override existing controller, use for example 'node' instead of
// arg_nid as name.
if (isset($map[$attribute])) {
$attribute = $map[$attribute];
}
if ($arg = $route_match->getRawParameter($attribute)) {
}
else {
$arg = $route_match->getParameter($attribute);
}
if (isset($arg)) {
$args[] = $arg;
}
}
The issue with the above is that anything in '_view_argument_map' is controlled by us (via PathPluginBase) and will always have its keys on both the raw and the upcast parameters. Furthermore, argument and argument_validator plugins expect the raw parameters anyway.
The bug in the above code can manifest itself because of the falsy check on the raw parameter. If we have one with a value of '0', it will try to get the upcast parameter, which may break a validator that expects a raw value.
Steps to reproduce
Visit a view at foo/0 and see that argument validators receive an upcast parameter for 0, provided you have an upcast configured to do just that.
Proposed resolution
Either way, the fix is simple.
foreach ($map as $attribute => $parameter_name) {
// ...
if (isset($map[$attribute])) {
$attribute = $map[$attribute];
}
$arg = $route_match->getRawParameter($attribute);
if (isset($arg)) {
$args[] = $arg;
}
}
This will only use the raw parameters and also strictly checks for NULL, rather than falsy. We'll need to update ViewPageControllerTest because it builds RouteMatch from a Request with only attributes set and no _raw_variables. If we set _raw_variables there, the test is fixed.
Remaining tasks
Create an MR with the above changes.
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
Issue fork drupal-3631325
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #4
shank115 commentedComment #5
kristiaanvandeneyndeLooks good to me.
At one point I was thinking we may want a regression test where a raw 0 is passed with a custom upcaster that converts it into something other than a primitive and then use that in a view. But then that would test for a regression on something that should have been tested all along: That views argument plugins always get the raw parameter value.
If that were tested before, this bug wouldn't have been able to exist in the first place. And we don't need to test that with such an edge case as a 0 being upcast to something else, we can test that with any upcaster already in core, such as the entity one.
So setting to RTBC and leaving to committers to decide whether we want to fix that test gap as part of this bugfix or as a separate issue.