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)
Comments
Comment #2
lendude@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?
Comment #3
Yuri commentedI 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
Comment #4
webdrips commentedHi @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.
Comment #5
webdrips commentedChanging the status back to active
Comment #7
samitk commentedComment #9
samitk commentedComment #10
smustgrave commented#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.
Comment #11
maskedjellybeanThe 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.
Comment #14
carlitus commentedUpps, sorry, i did something wrong with this MR. I will try to fix this.
Comment #18
paucala commentedRerolled for Drupal 10.3
Comment #19
dxvargas commentedAs 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.
Comment #20
webdrips commented#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.
Comment #21
dxvargas commented@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$urlis 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.
Comment #22
emil stoianov commentedPatch 19 did not work
Patch 20 did
D10.3.10
Comment #23
dxvargas commentedI'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.
Comment #24
jana_najdi01 commentedI 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
Comment #27
alorencRolled MR 6989
Comment #28
alorencComment #29
smustgrave commentedSummary 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)