We never check if there is an input index for an exposed filter before we try to fetch it from the array of inputs in FilterPluginBase::acceptExposedInput which can causes notices for empty inputs:
$value = $input[$this->options['expose']['identifier']];

Further down in FilterPluginBase::acceptExposedInput we check if the $value variable is set. But at this point, we've already received a notice.

if (isset($value)) {
  $this->value = $value;
  if (empty($this->alwaysMultiple) && empty($this->options['expose']['multiple']) && !is_array($value)) {
    $this->value = [$value];

Stack trace:

Notice: Undefined index: filename in Drupal\views\Plugin\views\filter\FilterPluginBase->acceptExposedInput() (line 1385 of core/modules/views/src/Plugin/views/filter/FilterPluginBase.php).
Drupal\views\Plugin\views\filter\FilterPluginBase->acceptExposedInput(Array) (Line: 1352)
Drupal\views\ViewExecutable->_build('filter') (Line: 1248)
Drupal\views\ViewExecutable->build(NULL) (Line: 1377)
Drupal\views\ViewExecutable->execute(NULL) (Line: 1440)
Drupal\views\ViewExecutable->render() (Line: 33)
Drupal\entity_browser\Plugin\views\display\EntityBrowser->execute() (Line: 1616)
Drupal\views\ViewExecutable->executeDisplay('entity_browser_1') (Line: 118)
Drupal\entity_browser\Plugin\EntityBrowser\Widget\View->getForm(Array, Object, Array) (Line: 127)
Drupal\entity_browser\Form\EntityBrowserForm->buildForm(Array, Object)
call_user_func_array(Array, Array) (Line: 514)
Drupal\Core\Form\FormBuilder->retrieveForm('entity_browser_browse_files_modal_form', Object) (Line: 271)
Drupal\Core\Form\FormBuilder->buildForm('entity_browser_browse_files_modal_form', Object) (Line: 74)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 574)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
call_user_func_array(Object, Array) (Line: 144)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 64)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 656)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
Members fund testing for the Drupal project. Drupal Association Learn more


kallehauge created an issue. See original summary.

kallehauge’s picture

Title: Undefined index notice on empty filter text inputs » Undefined index notice on empty exposed filter text inputs in views

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

alduya’s picture

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.

joelstein’s picture

Status: Active » Reviewed & tested by the community

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

xjm’s picture

Status: Reviewed & tested by the community » Needs work

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...


xjm’s picture

Issue tags: +Needs tests
axel.rutz’s picture

Status: Needs work » Postponed (maintainer needs more info)

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.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.