Undefined index notice when renaming grouped filter identifiers

I had the same error with an exposed, grouped filter in views.
The provided patch solved the problem.
As far as I could check, nothing else broke.

I experienced the same error, but only if I changed the filter identifier on a grouped filter. This patch fixed it for me!

Thanks for working on this issue!

A few points of feedback:

1. In general, suppressing notices like this to ignore empty inputs can be caused by incorrect calling code or implementations, or can hide other bugs. Looking at where this method is called in ViewExecutable, it doesn't look to me like it's valid to have an empty identifier for an exposed filter. Are there steps to reproduce this issue through the user interface using just core? @joelstein, maybe you could explain the steps to reproduce the bug as you encountered it?
2. We need automated test coverage for bug fixes. If there are steps to reproduce, those steps are a starting point to writing a test that fails with HEAD and passes with a valid fix.
3. If it does turn out that the fix in the patch is the best way to resolve the issue, there's also one small coding standards issue:
   

   +++ b/core/modules/views/src/Plugin/views/filter/FilterPluginBase.php
   @@ -1382,7 +1382,11 @@ public function acceptExposedInput($input) {
   +      } else {
   +        return FALSE;
   +      }
   

   Drupal's coding standards specify that else should not be on the same line as the closing curly from the previous condition. Reference: https://www.drupal.org/docs/develop/standards/coding-standards#controlst...

Thanks!

I had the same thing and the views exposed filter was malconfigured.

So i'd share xjm's view that IF there is a correctly configured view that triggers this, we have to debug the real issue behind that.
So if anyone checked all exposed filters and can upload an export of the view, we might be able to debug this.

Until that setting postponed.

I could workaround the issue by setting the filter id of the grouped exposed filter to the expected index. For example, here was my notice:

Notice: Undefined index: type in Drupal\views\Plugin\views\filter\FilterPluginBase->acceptExposedInput() (line 1385 of core/modules/views/src/Plugin/views/filter/FilterPluginBase.php).

My filter id was set by default on "bundle" (it was a taxonomy term) and when I changed the id to "type", the notice disappeared.

You can reproduce the issue like this:

Reproduction steps

1. Start with fresh install.
2. Login as admin.
3. Enable the Media module.
4. Create a new view of Media with a page.
5. Add a Media type filter. For this filter:
   1. Click on Expose this filter to visitors....
   2. Click on Grouped filters radio button.
   3. Uncheck optional checkbox.
   4. Set Bundle identifier to "bundlea".
   5. Configure the first two groups with "is one of".
   6. Set a group as default.
   7. Click on Apply.
6. Save the view.
7. Go to /admin/config/development/logging and enable all errors.
8. Go to the page of the view.
9. A notice will trigger.

I can add a little more info on this.

- Like #4 and #5, patch fixes (or rather, at least, hides) the error.
- This is only a problem if you rename grouped exposed filters, not single.

This seems to happen whenever expose.identifier doesn't match group_info.identifier - the latter is correct, but as soon as you switch from single to grouped or vice-versa in the UI, the identifier of the inactive type is reset to the default.

You can stop the error by manually editing the config and getting the two values in sync (but not via the UI for reason above).

My knowledge of views config is sketchy - EITHER:

- FilterPluginBase.php:acceptExposedInput() ought to check myfiltername.value (which is '0' for single, '1' for grouped) before deciding which key to read from $input - i.e. it should be checking $input[group_info.identifier] if value = 1
OR
- expose.identifier should be set to the same value as group_info.identifier when the filter is saved.

Is that enough for someone more cleverer than me to identify the correct fix?

I also ran into this issue with grouped exposed filters in Views in D8.6.2.

What is strange is that I don't have the error on the site in my Pantheon dev environment. I only have it locally in Dev Desktop, with an imported copy of the Pantheon site.

The patch in the original post hides the errors for me too.

This was my error output, which I was getting on every page, not just the pages that include Views with grouped exposed filters:

Notice: Undefined index: source in Drupal\views\Plugin\views\filter\FilterPluginBase->acceptExposedInput() (line 1389 of core\modules\views\src\Plugin\views\filter\FilterPluginBase.php).

Drupal\views\Plugin\views\filter\FilterPluginBase->acceptExposedInput(Array) (Line: 306)
Drupal\views\Plugin\views\filter\InOperator->acceptExposedInput(Array) (Line: 159)
Drupal\views\Form\ViewsExposedForm->submitForm(Array, Object)
call_user_func_array(Array, Array) (Line: 111)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 51)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 589)
Drupal\Core\Form\FormBuilder->processForm('views_exposed_form', Array, Object) (Line: 318)
Drupal\Core\Form\FormBuilder->buildForm('views_exposed_form', Object) (Line: 135)
Drupal\views\Plugin\views\exposed_form\ExposedFormPluginBase->renderExposedForm() (Line: 1238)
Drupal\views\ViewExecutable->build(NULL) (Line: 1391)
Drupal\views\ViewExecutable->execute() (Line: 167)
Drupal\facets\Plugin\facets\facet_source\SearchApiDisplay->fillFacetsWithResults(Array) (Line: 370)
Drupal\facets\FacetManager\DefaultFacetManager->updateResults('search_api:views_page__site_search__page_1') (Line: 94)
Drupal\facets_summary\FacetsSummaryManager\DefaultFacetsSummaryManager->build(Object) (Line: 91)
Drupal\facets_summary\Plugin\Block\FacetsSummaryBlock->build() (Line: 203)
Drupal\block\BlockViewBuilder::preRender(Array)
call_user_func('Drupal\block\BlockViewBuilder::preRender', Array) (Line: 378)
Drupal\Core\Render\Renderer->doRender(Array, 1) (Line: 195)
Drupal\Core\Render\Renderer->render(Array, 1) (Line: 151)
Drupal\Core\Render\Renderer->Drupal\Core\Render\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 152)
Drupal\Core\Render\Renderer->renderPlain(Array) (Line: 166)
Drupal\Core\Render\Renderer->renderPlaceholder('callback=Drupal%5Cblock%5CBlockViewBuilder%3A%3AlazyBuilder&args%5B0%5D=searchsummary&args%5B1%5D=full&args%5B2%5D&token=xMG4_7eYRIczuBvduIwThwhIhhuCExBoqz4sDgC18cw', Array) (Line: 696)
Drupal\big_pipe\Render\BigPipe->renderPlaceholder('callback=Drupal%5Cblock%5CBlockViewBuilder%3A%3AlazyBuilder&args%5B0%5D=searchsummary&args%5B1%5D=full&args%5B2%5D&token=xMG4_7eYRIczuBvduIwThwhIhhuCExBoqz4sDgC18cw', Array) (Line: 550)
Drupal\big_pipe\Render\BigPipe->sendPlaceholders(Array, Array, Object) (Line: 305)
Drupal\big_pipe\Render\BigPipe->sendContent(Object) (Line: 112)
Drupal\big_pipe\Render\BigPipeResponse->sendContent() (Line: 373)
Symfony\Component\HttpFoundation\Response->send() (Line: 20)

Here are screen grabs of the filters that might be to blame. Note that I also have Better Exposed Filters on these Views, but only for the "Autosubmit" and "Hide submit button" features.

I tried the patch and it fixed the problem for me.

#13 worked for me, too. Thanks!

I can confirm that changing the filter identifier for an exposed and grouped filter will produce this error.

In my case, the filter was also a combined-fields filter, but changing the filter identifier for an exposed combined-fields filter does not produce this error, unless the filter is also a grouped filter.

Just ran into this issue as well, changing the filter identifier of a grouped filter causes the undefined index notices. This seems to solve it will add a patch if it pans out.

+ if ($this->options['is_grouped']) {
+ $value = $input[$this->options['group_info']['identifier']];
+ } else {
+ $value = $input[$this->options['expose']['identifier']];
+ }

While working on https://www.drupal.org/project/better_exposed_filters/issues/3087939#com... I was able to confirm that @Rob-holmes' suggestion resolves the issue. I attached a patch with his suggested changes.

The patch in #20 works for me, with D8.7.8. I will start to use that rather than the original patch, as this one seems to tackle the root cause rather than just hiding the error. Thank you @Rob Holmes and @Etroid.

Issue needs a status change.

Added test for #20.

Thanks everyone for working on this and getting to the root of the problem!

While the fix in #20 fixes the notice, it leaves the filter broken since the actual filtering will still be done with the exposed identifier, so we need a second change to actually turn this into a working fix.

Added test coverage for this (which also revealed that #20 wasn't fixing everything yet).

@Lendude asked me to review this...

First of all, thanks to everyone who helped track down the actual problem here. Glad we didn't just try to suppress the error. Thanks @xjm for insisting on a real fix with a test. ;)

Next (as usual) thanks @Lendude for supplying a working test-only that demonstrates the bug! And supplying a complete fix, now that we understand the problem and have a test that exercises it.

Bot results are as expected: test-only fails, with-fix is passing. No code style problems.

Looking closely at #25, I like everything I see, except one tiny nitpick:

+++ b/core/modules/views/tests/src/Kernel/Handler/FilterInOperatorTest.php
@@ -164,6 +164,39 @@ public function testFilterNotInOperatorGroupedExposedSimple() {
+    $this->assertEquals(3, count($view->result));

$this->assertCount(3, $view->result);

That's all I can possibly complain about. ;) Otherwise, I'd RTBC on the spot.

Thanks!
-Derek

Updated the patch in 25 with the point given in #27.

@anmolgoyal74 the changes in the other tests in #28 are out of the scope, we only need to modify it in the new test.

Edit: And thanks @dww for the review!

@anmolgoyal74 re: #28 - whoops, I didn't realize there were other assertEquals(X, count(Y)) in the same test class. Good find, but yeah, out of scope. Would be a good novice follow-up issue to grep for that throughout core and change them all.

@Lendude re: #29 - looks great, thanks! And you're welcome. ;)

RTBC #29: https://www.drupal.org/files/issues/2019-11-22/2884296-29.patch

Also fixing the title to match the actual bug, and providing a proper summary for core committers / posterity.

Thanks,
-Derek

I'm currently running D8.7.10. I need both this patch and the patch at https://www.drupal.org/project/drupal/issues/2877061#comment-12102103 (#13) but they both modify the same file and cannot both be applied. I have been attempting to combine both patches but there is overlap/conflict and I'm not a coder so I don't have the skills to sort it out.

In this type of case, is it better to combine both patches and post here, or modify that other patch so that it works after this one has been applied? I'm not sure of the normal procedure.

@Nick Hope: At this point, this issue is RTBC. Hopefully it'll land soon. Posting "reroll backport combined with X" patches tend to confuse things and slow the process down (people queue things for the bots to test that can't possibly work, additional noise/comments for people asking for support with the combined patch, etc). So my vote is: no. Please don't post such a patch here.

However, I'd consider re-rolling #2877061: Illegal choice in grouped exposed filters with enabled option remember (ListField, BooleanOperator - Views filter handlers ) as if this has already been committed, then post that as a "DO-NOT-TEST-YET" patch over there. That issue is only "Needs work" right now, so there's little to no chance it'd land first. But if that patch is going to conflict with this, you could potentially help speed that issue up by having something ready-to-test once this is in Git. A preemptive re-roll of that issue for once this is committed.

Cheers,
-Derek

@dww Thank you. That makes sense. By the way it was me that changed that "illegal choice" issue from "8.6.x-dev Needs Review" to "8.9.x-dev Needs Work" last night. I may have another crack at an updated patch for that issue, but if any proficient coders feel like helping, feel free.

Pending a compatible patch for that issue, I suppose there's always the far-from-ideal fallback option of applying that patch #13 as is, together with the patch from the OP of this issue, since those 2 don't conflict.

Crediting @Dakwamine for commenting which very clear steps to reproduce the bug
Crediting @wturrell and @John Pitcairn for adding more info to solve the bug.
Crediting @Rob Holmes for posting a possible solution

Committed and pushed 1ab63529b2 to 9.0.x and 0ab34a4499 to 8.9.x. Thanks!

Backported to 8.8.x as this is non disruptive and a bug fix.

I am on an older version of Drupal (not 8.9), so these patches didn't work for me. As a workaround fix, I exported the configs and found the problem index in the yml file for the view (key = identifier). I updated the yml file with my renamed key and imported the configuration and the error went away.