datetime date views filter: DateTime object not set

The Needs Review Queue Bot → tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

I also faced the same issue with the Date time object on the Views exposed filter having the wrong Date format. The issue is due to the Views Token filter module. After the proper token update it works fine.

But, expected to show a valid error or warning rather than a page break. The patch was not applied with the latest version of Drupal core 10.1.x. Rerolled the patch and resolved the page break.

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

added updated patch try to fix CCF #45. modifies the validateExposed() function to use a local variable $form_element to hold the field element that needs to be set with the form error message. It also changes the if-else block to use the null coalesce operator instead of an if-else block for brevity.

Also look at the tags please. Was previously tagged for test which are still needed.

Patch works, but not in case the form element in the exposed form is placed inside a container or other wrapper. I added support for this case. Also, I faced an issue with the "reset" button while testing this patch: validation didn't let me perform the reset action. So I added improvement for that case as well.

Code style improvement.

I still get a PHP warning in AttributeArray (line 79) because the original input array is statically cached in ViewExecutable::getExposedInput() on line 726, which happens before the data is validated. We need to validate the data before it is saved.

Saw this exception in my log slowing down my website because bots trigger this one a lot. Looks like there's been significant work done on this merge request since it's last review.

Seems will still need test coverage for this. MR should be updated for 11.x

I have reproduced the error in the UI of Drupal 11.x-dev.

The current solution seems not to solve the issue if a URL accessing the date field has an invalid date format.
For example, we received this request:

?to_date[date]=../admin/noop.cgi?foo=bar&test=blah

A bot trying to brute force and causing issues, in that case, it throws the same error:

User error: Exception thrown while calling __toString on a Drupal\Core\Datetime\DrupalDateTime object in /var/www/html/docroot/core/lib/Drupal/Component/Datetime/DateTimePlus.php on line 354: DateTime object not set. in Drupal\Component\Datetime\DateTimePlus->__toString() (line 20 of core/lib/Drupal/Component/Utility/ToStringTrait.php).
Drupal\Component\Datetime\DateTimePlus->__toString() (Line: 161)
Drupal\views\Plugin\views\filter\Date->acceptExposedInput(Array) (Line: 184)
Drupal\views\Form\ViewsExposedForm->submitForm(Array, Object)
call_user_func_array(Array, Array) (Line: 129)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 67)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 609)
Drupal\Core\Form\FormBuilder->processForm('views_exposed_form', Array, Object) (Line: 326)
Drupal\Core\Form\FormBuilder->buildForm('\Drupal\views\Form\ViewsExposedForm', Object) (Line: 134)
Drupal\views\Plugin\views\exposed_form\ExposedFormPluginBase->renderExposedForm() (Line: 1304)
Drupal\views\ViewExecutable->build(NULL) (Line: 1457)
Drupal\views\ViewExecutable->execute(NULL) (Line: 1520)
Drupal\views\ViewExecutable->render() (Line: 133)
Drupal\views\Plugin\views\display\Block->execute() (Line: 1696)
Drupal\views\ViewExecutable->executeDisplay('block_3', Array) (Line: 81)
Drupal\views\Element\View::preRenderViewElement(Array) (Line: 61)
Drupal\views\Plugin\Block\ViewsBlock->build() (Line: 106)
Drupal\layout_builder\EventSubscriber\BlockComponentRenderArray->onBuildRender(Object, 'section_component.build.render_array', Object)
call_user_func(Array, Object, 'section_component.build.render_array', Object) (Line: 97)
Drupal\tracer\EventDispatcher\TraceableEventDispatcher->dispatch(Object, 'section_component.build.render_array') (Line: 90)
Drupal\layout_builder\SectionComponent->toRenderArray(Array, ) (Line: 88)
Drupal\layout_builder\Section->toRenderArray(Array) (Line: 331)
Drupal\layout_builder\Entity\LayoutBuilderEntityViewDisplay->buildSections(Object) (Line: 291)
Drupal\layout_builder\Entity\LayoutBuilderEntityViewDisplay->buildMultiple(Array) (Line: 340)
Drupal\Core\Entity\EntityViewBuilder->buildComponents(Array, Array, Array, 'full') (Line: 24)
Drupal\node\NodeViewBuilder->buildComponents(Array, Array, Array, 'full') (Line: 282)
Drupal\Core\Entity\EntityViewBuilder->buildMultiple(Array) (Line: 239)
Drupal\Core\Entity\EntityViewBuilder->build(Array)
call_user_func_array(Array, Array) (Line: 113)
Drupal\Core\Render\Renderer->doTrustedCallback(Array, Array, 'Render #pre_render callbacks must be methods of a class that implements \Drupal\Core\Security\TrustedCallbackInterface or be an anonymous function. The callback was %s. See https://www.drupal.org/node/2966725', 'exception', 'Drupal\Core\Render\Element\RenderCallbackInterface') (Line: 870)
Drupal\Core\Render\Renderer->doCallback('#pre_render', Array, Array) (Line: 432)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 248)
Drupal\Core\Render\Renderer->render(Array, ) (Line: 238)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 638)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 231)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 128)
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: 97)
Drupal\tracer\EventDispatcher\TraceableEventDispatcher->dispatch(Object, 'kernel.view') (Line: 186)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 53)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 263)
Drupal\shield\ShieldMiddleware->bypass(Object, 1, 1) (Line: 130)
Drupal\shield\ShieldMiddleware->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 38)
Drupal\tracer\StackMiddleware\TracesMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 741)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

I will check to apply a fix for that case too.

oily → changed the visibility of the branch 2966735-datetime-date-views to hidden.

1. A new branch based on 11.x-dev has been created and is now the default branch
2. The new datetime field validation patch has been committed to a MR
3. The validation function code has been fixed including phpstan
4. The pipeline is running green
5. Testing locally in a test view with an exposed datetime filter, the fix validates wrongly formatted dates

The nScreenshot showing an invalid date getting validated in exposed filter →

Test coverage is now in place. Changing status to 'Needs review'.

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Why remove Needs Review Queue Initiative tag?

Good spot. Have restored the attribute.

Believe feedback has been addressed here.

I read the comments and the MR and tested the change locally. I find that all questions are answered. I also updated credit.

And, I'd like to remind committers that screenshots should be available from the issue summary.

Leaving at RTBC