Problem/Motivation

Using PHP 8.1 and D9.5.2, I'm seeing a deprecated function warning on a view with an exposed form (show in block = true) where the exposed field is the "Combined fields filter", and only the Title field is selected.

Steps to reproduce

1. Create a view with a title field
2. Add "Combine fields filter", and set it to exposed; in my case, the Title field is selected under "Choose fields to combine for filtering"
3. Under "Exposed Form", set "Exposed form in block" to "Yes"

Error with Backtrace

Deprecated function: preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated in Drupal\Core\Routing\UrlGenerator->doGenerate() (line 201 of core/lib/Drupal/Core/Routing/UrlGenerator.php).
Drupal\Core\Routing\UrlGenerator->doGenerate(Array, Array, Array, Array, Array, 'view.committees_by_assembly.page_1') (Line: 250)
Drupal\Core\Routing\UrlGenerator->getInternalPathFromRoute('view.committees_by_assembly.page_1', Object, Array, Array) (Line: 292)
Drupal\Core\Routing\UrlGenerator->generateFromRoute('view.committees_by_assembly.page_1', Array, Array, 1) (Line: 105)
Drupal\Core\Render\MetadataBubblingUrlGenerator->generateFromRoute('view.committees_by_assembly.page_1', Array, Array, ) (Line: 765)
Drupal\Core\Url->toString() (Line: 134)
Drupal\views\Form\ViewsExposedForm->buildForm(Array, Object)
call_user_func_array(Array, Array) (Line: 594)
Drupal\Core\Form\FormBuilder->retrieveForm('views_exposed_form', Object) (Line: 282)
Drupal\Core\Form\FormBuilder->buildForm('\Drupal\views\Form\ViewsExposedForm', Object) (Line: 134)
Drupal\views\Plugin\views\exposed_form\ExposedFormPluginBase->renderExposedForm() (Line: 1243)
Drupal\views\ViewExecutable->build(NULL) (Line: 1396)
Drupal\views\ViewExecutable->execute(NULL) (Line: 1459)
Drupal\views\ViewExecutable->render() (Line: 131)
Drupal\views\Plugin\views\display\Block->execute() (Line: 1635)
Drupal\views\ViewExecutable->executeDisplay('block_1', Array) (Line: 81)
Drupal\views\Element\View::preRenderViewElement(Array) (Line: 59)
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: 142)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'section_component.build.render_array') (Line: 117)
Drupal\layout_builder\SectionComponent->toRenderArray(Array, ) (Line: 88)
Drupal\layout_builder\Section->toRenderArray(Array) (Line: 316)
Drupal\layout_builder\Entity\LayoutBuilderEntityViewDisplay->buildSections(Object) (Line: 275)
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: 101)
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: 788)
Drupal\Core\Render\Renderer->doCallback('#pre_render', Array, Array) (Line: 374)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 204)
Drupal\Core\Render\Renderer->render(Array, ) (Line: 242)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 580)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 243)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 132)
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: 142)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.view') (Line: 174)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 81)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->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: 50)
Drupal\ban\BanMiddleware->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 713)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
CommentFileSizeAuthor
#19 3338057-19.diff1.03 KBdxvargas
#20 3338057-20.patch1.54 KBwebdrips

Issue fork drupal-3338057

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

webdrips created an issue. See original summary.

lendude’s picture

Status: Active » Postponed (maintainer needs more info)

@webdrips thanks for reporting this.

If I just follow your steps to reproduce on a clean Drupal install I don't see this issue.

The steps seem a bit minimal, since the block isn't actually placed with them. Looking at the stack trace it seems to be placed using Layout builder, is that relevant or do you get this error when you place it anywhere?
Also the stack trace doesn't appear to touch the Combined field filter at all, so is that needed to trigger this or can you trigger this with other exposed filters too?

Yuri’s picture

I have the exact same error.
In my case I don't use the combined fields filter.
But, I did use an exposed filter in a views block display, which triggered the error, regardless whether ajax was turned on or not.
Using Drupal distribution Open Social 11.7.1 which uses Drupal 9.4.11

webdrips’s picture

Hi @Lendude ahh yes sorry about that.

This is a bit more complex as we're using the exposed filter as a "normal" block, and the view block was placed using the Layout Builder as you suggested. We use a patch for layout builder to provide visibility rules. We're essentially taking the approach of trying to use Drupal's core modules as much as possible for maintainability.

In this case, we added the block with the layout builder, and used a taxonomy term value to control visibility.

The patch that allows that is here: https://www.drupal.org/project/drupal/issues/2916876

We have 27 core patches for this project, so there may be others involved in pulling this off.

If I remove the combined filter block, the error disappears. If I put it back, I need to click search (with or without a value in the search field doesn't matter).

I'm happy to show you the issue over Zoom if it helps at all.

webdrips’s picture

Status: Postponed (maintainer needs more info) » Active

Changing the status back to active

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

samitk’s picture

Assigned: Unassigned » samitk
Status: Active » Needs work

samitk’s picture

Assigned: samitk » Unassigned
Status: Needs work » Needs review
smustgrave’s picture

Status: Needs review » Needs work

#2 it was mentioned that this wasn't reproducible.

But if this is a bug research needs to be done to find why that parameter is empty vs just putting a check in.

maskedjellybean’s picture

The patch from the MR works for me in 10.1.8 to resolve this error thrown by a view. The view then functions as it should. Not sure what to make of that.

carlitus made their first commit to this issue’s fork.

carlitus’s picture

Upps, sorry, i did something wrong with this MR. I will try to fix this.

paucala made their first commit to this issue’s fork.

paucala’s picture

Rerolled for Drupal 10.3

dxvargas’s picture

StatusFileSize
new1.03 KB

As I understand, no one here had any other problem except getting the deprecated warning. This is my case. Everything is working as expected except that I see this warning.

So, why not to just avoid this warning in the most simpler way possible?

This is what I understand that Symfony did. In the documentation, it says that the code is adapted from \Symfony\Component\Routing\Generator\UrlGenerator::doGenerate(). If we check the changes in this method, they are basically replacing $mergedParams[$token[3]] with $mergedParams[$token[3]] ?? ''.
Please check here the old code:
https://github.com/symfony/routing/blob/3.4/Generator/UrlGenerator.php#L...
And check here the new code:
https://github.com/symfony/routing/blob/7.1/Generator/UrlGenerator.php#L...

In my case (that I miss to reproduce in a vanilla install, thus I won't explain in detail) I get an error when I apply the patch in a piece of code that apparently has nothing to do with this.
I can briefly say that it's in a hook in private message entity (from the private_message module) that is displayed in layout builder, because the entity has no longer a owner. My code is heavily customized, it's difficult to debug the new error and explain what is happening.
Anyway, I think my case demonstrates how a change here can have unexpected impacts.

One think that looks suspicious in the current MR changes is that before, for each $tokens, the $url was being set with a new value.
With the changes in the current MR, if the variable $optional is true, the $url will remain unchanged.
I don't really understand all the logic here. But this doesn't look right.

I don't want to just change the MR in a completely different approach, so I'll just leave a patch here with the change I'm proposing.

webdrips’s picture

StatusFileSize
new1.54 KB

#19 didn't fix my issue (same error as before), and #17 didn't apply to 10.3.2 for me anyway, so I'm attaching a patch that worked fine for me in case anyone needs it.

dxvargas’s picture

@webdrips it is impossible that you have the same error after applying the patch in #19.
There is only preg_match() method here. After the patch, it is receiving as second argument ($subject) this: $mergedParams[$token[3]] ?? '', and this is never NULL.

My patch in #19 fixes the problem.

About your patch in #20, I have the same problem that I had with the changes in the MR.
That patch changes the logic!

Before, if $mergedParams[$token[3]] is null, !preg_match('#^' . $token[2] . '$#', $mergedParams[$token[3]] ?? '') evaluates to TRUE and an exception is thrown and no $url is returned.
After your patch, if $mergedParams[$token[3]] is null, the processing goes to $url = $token[1] . $url; and continues.

A patch here cannot change the logic. If the logic is not good, please fill another issue and let's discuss that.
Here we just need to make the PHP warning go away. Patch #19 does that.

emil stoianov’s picture

Patch 19 did not work
Patch 20 did
D10.3.10

dxvargas’s picture

I'm amazed that my patch #20 does not work and I cannot understand how the error can still happen.
If @webdrips or @emil-stoianov can please explain with more detail what happens, I would be greatly thankful.
Anyway, thanks for the feedback.

jana_najdi01’s picture

I am having this problem on webform translation and i am unable to save it even if i apply patch #20 the error goes away but still unable to save the webform translation

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

alorenc made their first commit to this issue’s fork.

alorenc’s picture

Rolled MR 6989

alorenc’s picture

Status: Needs work » Needs review
smustgrave’s picture

Status: Needs review » Needs work
Issue tags: +Needs issue summary update

Summary appears to be incomplete. Moving proposed solution. But also these kind of issues may need ot backtrace the "why" this null vs putting a check. Want to make sure we aren't masking a larger issue

50/50 if this should have a unit test (hopefully one that can be expanded)