- Issue created by @goldin
- Status changed to Needs review
11 months ago 6:36am 31 January 2024 - 🇮🇳India _utsavsharma
Created patch addressing the resolution provided.
Please review. - last update
11 months ago Custom Commands Failed - Status changed to Needs work
11 months ago 3:03pm 31 January 2024 - 🇺🇸United States smustgrave
Putting just an isset() usually isn't the solution, as that will mask a larger issue.
Once more research done as to why this key isn't defined. test coverage will be needed.
- 🇺🇸United States greenskin
We ran into this warning when exposing a filter as type "Grouped filters". Patch resolves the warning for us.
- 🇺🇸United States generalredneck
I'm pretty sure this is related to 🐛 Notice: Undefined index: value in Drupal\views\Plugin\views\filter\NumericFilter->acceptExposedInput() Needs work . It may possible be a duplicate? though I landed here because I"m getting a similar issue even after upgrading to 10.2.5 where the prior fix was released.
- 🇧🇪Belgium rp7
Experiencing the same issue on a project of ours. Running on 10.2.6. Patch fixes it, but I agree with #3 that this isn't really a long term solution.
- 🇩🇪Germany FeyP
Looking into this a bit, the method is called from two places. Once in the submit handler of
ViewsExposedForm
and then inViewExecutable::_build()
.The first call triggers the warning for this filter configuration, because at that time, the exposed input is not yet converted from the value of the exposed form element to the structure actually expected by the handler. You get an array with the selected option groups, e.g. something like
[1 => 1, 2 => 2, 3 => 3]
, if you have three option groups and all are selected.The parent method in
FilterPluginBase
will handle this and accept the input, but then the check in the switch statement will trigger the warning, because a) there is no handling for multiple values and b) the values have not yet been converted to the expected structure[min => .., max => .., value => ..]
.For the subsequent calls from
ViewsExecutable
, before calling the handler the input will be properly converted to the expected format and then checked for each selected option group separately, so theNumericFilter
will then accept the input via the switch statement.This might have been designed this way with the idea that the exposed input for grouped filters is initially checked by the parent method only and then the real check only happens in
ViewsExecutable
. If this assumption was correct, then checking whether the array keys are set would be the correct fix at least for this filter configuration.If we don't want to go with that, I think we would need to change the submit handler of the exposed form so that it checks the value in a similar way to how it is done in
ViewsExecutable::_build()
for this kind of filter configuration, i.e. convert everything to the expected format and then check each value separately.