Views NumericFilter not using group identifier for group filters

Can you please provide more information on how to reproduce this issue? There is no info here about when or why it occurs but it can't be fixed (and no patch will be committed) until it is verified, and there are tests.

Until it's verified to be reproducible in vanilla Drupal I am bumping down to normal. Please read this info on how to provide steps to reproduce → .

Did you recently update to PHP 8 by any chance?

This is issue come when i am using view with better expose

@pankaj1390 please read the information on providing steps to reproduce → .

It is not possible to help you currently based on the information you have provided. Also, it sounds like this is not a core issue, if it occurs using a contrib module?

Hi @pameeela,

I have the same issue.

It is independent of Better Exposed Filter module.

If you use a exposed filter type grouped for a date field, the site crash with error:

TypeError: Cannot access offset of type string on string in /web/core/modules/views/src/Plugin/views/filter/Date.php on line 153 #0 /web/core/modules/views/src/Form/ViewsExposedForm.php(188): Drupal\\views\\Plugin\\views\\filter\\Date->acceptExposedInput()\n#1 [internal function]: Drupal\\views\\Form\\ViewsExposedForm->submitForm()\n#2 /web/core/lib/Drupal/Core/Form/FormSubmitter.php(114): call_user_func_array()\n#3 /web/core/lib/Drupal/Core/Form/FormSubmitter.php(52): Drupal\\Core\\Form\\FormSubmitter->executeSubmitHandlers()\n#4 /web/core/lib/Drupal/Core/Form/FormBuilder.php(595): Drupal\\Core\\Form\\FormSubmitter->doSubmitForm()\n#5 /web/core/lib/Drupal/Core/Form/FormBuilder.php(323): Drupal\\Core\\Form\\FormBuilder->processForm()\n#6 /web/core/modules/views/src/Plugin/views/exposed_form/ExposedFormPluginBase.php(134): Drupal\\Core\\Form\\FormBuilder->buildForm()\n#7 /web/core/modules/views/src/ViewExecutable.php(1243): Drupal\\views\\Plugin\\views\\exposed_form\\ExposedFormPluginBase->renderExposedForm()\n#8 /web/core/modules/views/src/Plugin/views/display/PathPluginBase.php(392): Drupal\\views\\ViewExecutable->build()\n#9 //web/core/modules/views/src/Plugin/views/display/Page.php(196): Drupal\\views\\Plugin\\views\\display\\PathPluginBase->execute()\n#10 /web/core/modules/views/src/ViewExecutable.php(1635): Drupal\\views\\Plugin\\views\\display\\Page->execute()\n#11 /web/core/modules/views/src/Element/View.php(81): Drupal\\views\\ViewExecutable->executeDisplay()\n#12 [internal function]: Drupal\\views\\Element\\View::preRenderViewElement()\n#13 /web/core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php(101): call_user_func_array()\n#14 /web/core/lib/Drupal/Core/Render/Renderer.php(788): Drupal\\Core\\Render\\Renderer->doTrustedCallback()\n#15 /web/core/lib/Drupal/Core/Render/Renderer.php(374): Drupal\\Core\\Render\\Renderer->doCallback()\n#16 /web/core/lib/Drupal/Core/Render/Renderer.php(204): Drupal\\Core\\Render\\Renderer->doRender()\n#17 /web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(242): Drupal\\Core\\Render\\Renderer->render()\n#18 /web/core/lib/Drupal/Core/Render/Renderer.php(580): Drupal\\Core\\Render\\MainContent\\HtmlRenderer->Drupal\\Core\\Render\\MainContent\\{closure}()\n#19 /web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(243): Drupal\\Core\\Render\\Renderer->executeInRenderContext()\n#20 /web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(132): Drupal\\Core\\Render\\MainContent\\HtmlRenderer->prepare()\n#21 /web/core/lib/Drupal/Core/EventSubscriber/MainContentViewSubscriber.php(90): Drupal\\Core\\Render\\MainContent\\HtmlRenderer->renderResponse()\n#22 [internal function]: Drupal\\Core\\EventSubscriber\\MainContentViewSubscriber->onViewRenderArray()\n#23 /web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(142): call_user_func()\n#24 /vendor/symfony/http-kernel/HttpKernel.php(174): Drupal\\Component\\EventDispatcher\\ContainerAwareEventDispatcher->dispatch()\n#25 /vendor/symfony/http-kernel/HttpKernel.php(81): Symfony\\Component\\HttpKernel\\HttpKernel->handleRaw()\n#26 /web/core/lib/Drupal/Core/StackMiddleware/Session.php(58): Symfony\\Component\\HttpKernel\\HttpKernel->handle()\n#27 /web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\\Core\\StackMiddleware\\Session->handle()\n#28 /web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\\Core\\StackMiddleware\\KernelPreHandle->handle()\n#29 /web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\\page_cache\\StackMiddleware\\PageCache->pass()\n#30 /web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\\page_cache\\StackMiddleware\\PageCache->handle()\n#31 /web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\\Core\\StackMiddleware\\ReverseProxyMiddleware->handle()\n#32 /vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\\Core\\StackMiddleware\\NegotiationMiddleware->handle()\n#33 /web/core/lib/Drupal/Core/DrupalKernel.php(713): Stack\\StackedHttpKernel->handle()\n#34 /web/index.php(19): Drupal\\Core\\DrupalKernel->handle()\n#35 {main}, referer: http://XXX

My Drupal core is 9.5.2, but also hapends with 9.4.8.

#1 works for me.

Thanks

Hi @pameeela,

I had been doing some tests. The error is raised when you change the "filter ID" in the filter configuration. If you change it the site crash when you use the filter, but if you put again the same "filter ID" everithing works fine again.

Thanks.

I had the same problem, and was related with: https://www.drupal.org/project/bat → - BAT Event Series.
The view with the "filter ID" in the filter configuration was: /admin/structure/views/view/event_series

+ the same problem as #5 with combined filters on date field
trying to revert Filter Id makes no help

We get the same error message:

TypeError: Cannot access offset of type string on string in Drupal\views\Plugin\views\filter\Date->acceptExposedInput() (line 160 of /var/www/harmonyarts.ca/web/core/modules/views/src/Plugin/views/filter/Date.php)

I think #5 identifies the cause.

In our case it relates to a Views exposed group filter based on a Smart Date field. If the default Filter Identifier is used (in this case 'field_date_value') the filter works. If the Filter Identifier is changed to anything else (such as 'date2' in the attached screenshot) it stops working and gives an error message.

This was working OK a year ago. It is from a website for an annual festival and the customized Filter Identifier name has been in place and working for several years. The issue only came to light when we started populating the site with this years data.

Things to note:
- we are using Drupal 9.5.9
- we are not allowing multiple selections for the filter
- we are not using Better Exposed Filters module
- we are not using BAT Event module

Thanks

Simon P

- the line number is different (presumably the code has been updated in the meantime)

As a bug will need a test case showing the issue.

Also steps should be addded to the issue summary.

That being said typically just putting an isset() isn't enough as it's probably masking a bigger issue.

In case this helps resolve this issue, the steps to reproduce it are:

- create a view that includes a new exposed filter for a Smart Date field
- make the filter grouped and add at least one group
- note the default name of the Filter Identifier (should be something like 'field_date_value')
- test that the filter works correctly
- change the Filter Identifier (ie. 'test', 'date', etc)
- test that the filter works (it should now give an error message)
- revert the name of the Filter Identifier to the default value
- test that the filter works correctly

Thanks

Simon

Thanks @Simon-P. #14 is the correct way to reproduce. That is exactly what caused the error for me. Changing the Filter Identifier back to the default value avoids the error. We need to figure out why changing the Filter Identifier causes this error.

In my case the problem was in line 83 of Date.php

$convert = strtotime($value['value']);

didn't work because $value was just a string. So I had to change it to

$convert = strtotime($value);

I made a patch for my case, but did no further testing. But maybe it helps somebody else here

This is exactly the same issue with grouped date filters as it was in D7 back then:
https://www.drupal.org/project/views/issues/3123292 →

In the linked thread there is my fix for D7. If I develop fix for D9/10 I will post it here.

As alluded to in #13, these patches are along the wrong lines and mask the actual problem. There is a section in NumericFilter.php which is supposed to put the value into the correct array format.

    // rewrite the input value so that it's in the correct format so that
    // the parent gets the right data.
    if (!empty($this->options['expose']['identifier'])) {
      $value = &$input[$this->options['expose']['identifier']];
      if (!is_array($value)) {
        $value = [
          'value' => $value,
        ];
      }
    }

However, that is failing because the value in the options only contains the default field identifier rather than any other value which might be overriding it from the filter identifier box. I would say the bug is down to whatever is populating $this->options['expose']['identifier'] for grouped exposed filters.

So based on my last comment, I dug a bit deeper and noticed that the parent NumericFilter class didn't use the correct identifier for group filters. I've created an MR which checks if a filter is a group and uses the relevant identifier.

I suspect there might be other issues relating to this that aren't covered by this MR as that class makes a number of references to what would presumably be the wrong identifier elsewhere. I didn't make any sweeping changes though and kept the MR purely about the bug in this issue. If this is the correct solution to this issue it might be worth moving the code to get the identifier into a separate method and applying that in various places.

Good work digging through, issue summary should be updated to include steps to reproduce and proposed solution.

Also as a bug will need a test case that is showing this problem.

I am having this same issue after upgrading a site from D8 to D9.

TypeError: Cannot access offset of type string on string in Drupal\views\Plugin\views\filter\Date->acceptExposedInput() (line 153 of core/modules/views/src/Plugin/views/filter/Date.php).

I have a grouped date filter. When I remove that filter the error goes away so I know that is where the issue is coming from.

I am not quite clear if there is a way I can rewrite the View so to fix the error.

The issue I found during debugging, when a new identifier label is provided then rather than updating the key value of the old filter identifier it adds a new key with a type string.

 $input = [
  "date" => "All"
  "submit" => "Apply"
  "form_build_id" => "form-A3NiCslN2CyU2rJ0l_kFpajDkqmxnrFLlpQ58pZ3z8o"
  "form_id" => "views_exposed_form"
  "" => "Apply"
  "field_date_value" => [
    "value" => null
  ]
]

It should look like

 $input = [
  "submit" => "Apply"
  "form_build_id" => "form-A3NiCslN2CyU2rJ0l_kFpajDkqmxnrFLlpQ58pZ3z8o"
  "form_id" => "views_exposed_form"
  "" => "Apply"
  "date" => [
    "value" => "All"
  ]
]

If we fix this then we will not require adding additional checks for fetching the filter value, otherwise, validation added in #22 solves the error.

P.S. Please ignore the MR for 3336312-23.

Fixed for me by patching with Merge request from #19 [https://git.drupalcode.org/project/drupal/-/merge_requests/5391.diff]. Thanks @very_random_man!

As fonant → says #26 🐛 TypeError: Cannot access offset of type string on string Needs work , https://git.drupalcode.org/project/drupal/-/merge_requests/5391.diff has also worked very well for me.

Issue summary contains steps to reproduce
Also adding the error message for folks using search engines

TypeError: Cannot access offset of type string on string in Drupal\views\Plugin\views\filter\Date->acceptExposedInput() (line 153)

https://git.drupalcode.org/project/drupal/-/merge_requests/5391.diff has also worked well for me.

Tried to make sense of which MR or patch to use. Consensus seems to be MR 5391, but that is against 10.1.x. There is an MR against 11.x but that has over 1000+ changes. Nevertheless the 10.1.x diff applies to 11.x. It's missing tests though as requested in #13 in June last year. The issue title is not particular helpful in describing what this issue is about, as this error could appear anywhere.

very_random_man → changed the visibility of the branch 3336312-typeerror-cannot-access to hidden.

very_random_man → changed the visibility of the branch 3336312-23 to hidden.

Patch from https://git.drupalcode.org/project/drupal/-/merge_requests/5391.diff still works here to fix the problem:

patching file core/modules/views/src/Plugin/views/filter/NumericFilter.php
Hunk #1 succeeded at 420 (offset 16 lines).

The patch for this issue doesn't apply on 10.2.5, apparently because #2825860 🐛 Notice: Undefined index: value in Drupal\views\Plugin\views\filter\NumericFilter->acceptExposedInput() Needs work got merged and directly conflicts with MR 5391. It looks like it should do the same thing albeit expressed differently. Can anyone else confirm?