Exposed date filter leads to a notice

I've also received this notice on a Development site that was updated from Drupal 8.10 to Drupal 8.2 . This notice shows on all Views Pages with exposed date filters. (Events, Meetings, Publications), practically everywhere i'm allowing the user to filter by Date/Time or Authored On dates. Once a date is selected(Jquery UI Date Picker) and the view is filtered, the notice disappears.

@DeFR's Patch solves this issue for my current installation.

Drupal 8.2
PHP 7 (Apache, MySQL etc)
Ubuntu 16.04

Notice: Undefined index: type in Drupal\views\Plugin\views\filter\Date->acceptExposedInput() (line 125 of core\modules\views\src\Plugin\views\filter\Date.php).
Drupal\views\Plugin\views\filter\Date->acceptExposedInput(Array) (Line: 1353)
Drupal\views\ViewExecutable->_build('filter') (Line: 1249)
Drupal\views\ViewExecutable->build() (Line: 351)
Drupal\views\Plugin\views\display\PathPluginBase->execute() (Line: 168)
Drupal\views\Plugin\views\display\Page->execute() (Line: 1617)
Drupal\views\ViewExecutable->executeDisplay('page_1', Array) (Line: 78)
Drupal\views\Element\View::preRenderViewElement(Array)
call_user_func(Array, Array) (Line: 376)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array, ) (Line: 226)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 574)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 227)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 117)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
call_user_func(Array, Object, 'kernel.view', Object) (Line: 61)
Symfony\Component\EventDispatcher\Debug\WrappedListener->__invoke(Object, 'kernel.view', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.view', Object) (Line: 132)
Symfony\Component\EventDispatcher\Debug\TraceableEventDispatcher->dispatch('kernel.view', Object) (Line: 144)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 62)
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: 38)
Drupal\webprofiler\StackMiddleware\WebprofilerMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 652)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Fix makes sense.

+++ b/core/modules/views/src/Plugin/views/filter/Date.php
@@ -125,6 +125,9 @@ public function acceptExposedInput($input) {
+    // restore what got overwritten by the parent.

Lets update the comment while we are moving it by giving it a capital at the start.

Also, this needs tests.

Tried the patch against 8.2 and it worked.

This is discussed at some length in #2648950: [PP-2] Use form element of type date instead textfield when selecting a date in an exposed filter and that in turn defers to #2369119: Fatal error when trying to save a View with grouped filters using other than string values. Both those issues are MUCH bigger in scope then this, so I'll leave it open for now, but if any of those two issues land, this can be closed.

I confirm the patch works.

Drupal 8.2.2
PHP 7.0.8 (MAMP)

Patch works. Thank you.
Drupal 8.2.2
PHP 5.6.15
WAMP

Actually, we don`t need this workaround with 'type' in acceptExposedInput() at all.
There is no exposed element that may change the value for 'type' and configured value is stored in $this->options['value']['type']
which is used in opBetween() and opSimple() only.

The patch that removes the workaround and changes the logic for op methods is attached and works for me on 8.2.3 and 8.3.x

Works for me on 8.2.3

This is still Needs Work b/c the failing test in #9.

Trying to fix tests.

Fixes the notice for me, just found this in logs today and was happy to see the patch cleared everything up!

Seems some issues with CI tests.

I applied this patch and the error disappeared when I edit the view. But when I go to the view (page or block), I see another error.

Notice: Undefined index: type in Drupal\datetime\Plugin\views\filter\Date->opBetween() (line 93 of /var/www/html/drupal/web/core/modules/datetime/src/Plugin/views/filter/Date.php).

With 8.3.0 looming, I think the usefulness of this patch is dwindling, and we need to get #2369119: Fatal error when trying to save a View with grouped filters using other than string values in as the long term fix, and then see what else we need to adjust.

#15 Patch of '2811887-19-fix-tests.patch' it works for me (Drupal core 8.2.5).

Here are some details about the view I am using with this patch:

Show type: Custom Entity type
Display: page
Format: Table
Fields: including date, string
Filter Criteria:
Created date (exposed)
Name string (exposed)
language code (exposed)

Filter plugin module(contributed): Better Exposed Filters

This patch both works on view editing and view page.

Thanks a lots

For what it's worth I have the patch applied from #2369119 (-145) and it doesn't appear to resolve this particular issue (it was mentioned it would in #6). I still get: Notice: Undefined index: type in Drupal\views\Plugin\views\filter\Date->acceptExposedInput() (line 132 of core/modules/views/src/Plugin/views/filter/Date.php).

#24, that surprises me a little, but in some ways it doesn't; #2369119: Fatal error when trying to save a View with grouped filters using other than string values is a really weird problem. @Lendude and I discussed both of these issues, along with some other related ones, at length. We decided to not officially postpone this, but we decided #2369119: Fatal error when trying to save a View with grouped filters using other than string values really needs to get in before we touch the same part of the code (and tests) in other issues, primarily because of the non-trivial merge conflicts that would result. That particular issue is soft- or hard-blocking about four or five others right now.

This is not working for 8.2.6. Patch #15 worked me but only up to only 8.2.5 . Finding a solution for 8.2.6.

I can confirm that I am getting the same error on 8.2.6 with date filter in views not only grouped but also single filter on date that is of the type timestamp not string.

Also noticing the notice again now that 8.2.6 is out.

Same. The patch did fine until 8.2.6. Receiving the notices on only one out of 3 views that use the same date setup..

Hello,

In our project we are using Drupal 8.2.6 and the patch from #15 did not solve the problem.

However when I inspected the code I saw that the original solution ("restore what got overwritten by the parent") seem to be placed on the wrong location, eg: after the return statements in the if-statements that checked the value and mix-max-values.

So if any of these if-statements applied, the "restore what got overwritten by the parent" was not applied and the second time the code was executed the above described notice was thrown.

My simple solution (move the "restore what got overwritten by the parent" to a place where it is always executed) is included in the attached patch, as explained above: this is for Drupal 8.2.6.

Uploading the modified version of the patch in #15 that applies with patch 2369119-145.patch from https://www.drupal.org/node/2369119. I need this for composer patching as I need both patches. Someone might also need it.

AFAICT there's no difference difference between 2811887-2-exposed-date-restore-type-ealier.patch and 2811887-30-move-restore-overwritten-by-parent.patch

Just assigning myself to triage this again in the next day or two, and try to touchbase with @Lendude.

Did a bit of debugging and using 8.4.x it is as @louisnagtegaal describes. When we return early in \Drupal\views\Plugin\views\filter\Date::acceptExposedInput and acceptExposedInput gets called a second time (and on a normal page load it will get called more times then that), then things go wrong.

An empty value will do, and because we submit the form on load (see #2568889: Views exposed text filter set to required shows an empty error and form error on page load) just loading the page will trigger the notice.

Test and a fix. I went back to just moving the restore logic. The fix direction from #9 will alter the data that is provided by the plugin and any plugins extending the Date filter should be able to rely on the correct data being there.

Manually tested this, and all is good. Looked at patch, and no real feedback. We may end up adjusting the test in #2648950: [PP-2] Use form element of type date instead textfield when selecting a date in an exposed filter to be more robust, and match the changes that get introduced there, but this is fine to prevent any regressions for now.

Committed 36c53a2 and pushed to 8.4.x. Thanks!

I think this should be ported to 8.3.x too.

diff --git a/core/modules/views/src/Tests/Handler/FilterDateTest.php b/core/modules/views/src/Tests/Handler/FilterDateTest.php
index 2f6a61e..f81e753 100644
--- a/core/modules/views/src/Tests/Handler/FilterDateTest.php
+++ b/core/modules/views/src/Tests/Handler/FilterDateTest.php
@@ -295,7 +295,7 @@ protected function _testFilterDatetimeUI() {
   /**
    * Tests that the exposed date filter is displayed without errors.
    */
-  function testExposedFilter() {
+  public function testExposedFilter() {
     $this->drupalLogin($this->drupalCreateUser(['administer views']));
     $this->drupalPostForm('admin/structure/views/nojs/handler/test_filter_date_between/default/filter/created', [], t('Expose filter'));
     $this->drupalPostForm('admin/structure/views/view/test_filter_date_between/edit', [], t('Add Page'));

All methods must have visibility - fixed on commit.

+1 for cherry-picking, trivial fix with test coverage.

Committed d6afa76 and pushed to 8.3.x. Thanks!

Tried the patch from @louisnagtegaal (#30) on Drupal 8.2.7 and it works. Thanks

Hi,
i realised that there is still a notice, when you use "grouped filter".
Steps to reproduce:
- Change your views filter criteria to exposed and grouped
- go to /admin/reports/dblog

Sorry,
Lars

P.S.: We are using Drupal 8.4.5

Yes, still a notice when using "grouped filter" as exposed filter.

Same here #45 #46

Also same here

By coincidence I got rid of the notice. After saving the grouped exposed filter there is a short warning below the views options that something is wrong with some selection (no specific details). Instead of saving the view I opened the filter again and saved it again. The short warning disappeared, I saved the view and the long notice on the view page also disappeared!

Hi johnnny83. Tried your work around but couldn't figure it out.
I don't see the short warning, like you mentioned. But I tried to re-open the grouped filter after saving, saved it again, and then saved the view. But that didn't work. Still a notice.

Ok, try this:
1. Open the filter and change it to a single filter
2. Save filter
3. Save the view
4. Maybe clear cache (don't remember if I did it)
Then the same as before:
5. Open the filter again
6. Change it back to a grouped filter and put your options again
7. Save it
8. Open again
9. Save it
10. Save the view

Tried #51, but that didn't work. But it led me to a cause and workaround.

My error notice looked like this:

Notice: Undefined index: min in Drupal\views\Plugin\views\filter\NumericFilter->acceptExposedInput() (line 416 of /data/sites/web/www/core/modules/views/src/Plugin/views/filter/NumericFilter.php)

After opening the grouped filter and resetting it to a single filter, I noticed that the operator of the single filter previously was set to "is between". Which is not the default.

• Changed the grouped filter to a single filter
• Changed the operator of the single filter back to "is equal to",
• Saved the filter,
• Re-opened the filter + made it into a "grouped filter" again
• Reset my grouped filter values (Today, Greater than or equal to, -1 day)
• Re-saved my filter + view

Fixed. No notice any more !!

NB: Somehow the previous value ("is between") of my "single filter" was still being used/checked and throwing a notice when converted to a grouped filter.

So make sure the value of a single filter is always set to "is equal to" before selecting the "grouped filter" option.

Hope this helps someone out.

I have created a small patch which removes this annoying notice: Undefined index: type in Drupal\views\Plugin\views\filter\Date->acceptExposedInput()

Have same issue with an exposed grouped date filter; work-arounds are great; but this issue shouldn't be marked as closed yet - sadly, it can't be re-opened.

Adding to comment 52 above #2811887-52: Exposed date filter leads to a notice, the exposed identifiers for the un-grouped and grouped parts of the config also need to be the same.

Some pattern similar to #52 addressed the notices for us. Thanks!

EDIT: Nevermind? This solution stopped working after a cache-clear.
Thanks johnnny83 - your notes helped fix the problem for me. I opened the .yml configuration file for my view and copied one of my grouped filter's operator & value settings into the default operator & value settings, did a config-import, and the error went away. E.g., in my case, see the "COPIED FROM group_items[1]" lines:

        field_event_date_end_value:
          id: field_event_date_end_value
          table: node__field_event_date
          field: field_event_date_end_value
          relationship: nid
          group_type: group
          admin_label: ''
          plugin_id: datetime
          operator: '<=' # COPIED FROM group_items[1] (BELOW)
          value:
            min: '' # COPIED FROM group_items[1]
            max: '' # COPIED FROM group_items[1]
            value: '-1 month' # COPIED FROM group_items[1]
            type: offset # COPIED FROM group_items[1]
          group: 1
          exposed: true
          expose:
            operator_id: field_event_date_end_value_op
            label: 'Event date (field_event_date:end_value)'
            description: null
            use_operator: false
            operator: field_event_date_end_value_op
            operator_limit_selection: false
            operator_list: {  }
            identifier: field_event_date_end_value
            required: false
            remember: false
            multiple: false
            remember_roles:
              authenticated: authenticated
            min_placeholder: null
            max_placeholder: null
            placeholder: null
          is_grouped: true
          group_info:
            label: 'Past events'
            description: ''
            identifier: date_end_value
            optional: true
            widget: select
            multiple: false
            remember: false
            default_group: All
            default_group_multiple: {  }
            group_items:
              1:
                title: '1 month past'
                operator: '<='
                value:
                  min: ''
                  max: ''
                  value: '-1 month'
                  type: offset
              2:
                title: '6 months past'
                operator: '<='
                value:
                  min: ''
                  max: ''
                  value: '-6 months'
                  type: offset

#52 helped me! Thank you SO MUCH, it was driving me batty.