Contrib.social

Deprecated function: preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated in Drupal\Core\Routing\UrlGenerator->doGenerate()

Open on Drupal.org →
Created on 31 January 2023, almost 2 years ago
Updated 2 September 2024, 3 months ago

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)
🐛 Bug report
Status

Needs work

Version

11.0 🔥

Component
Views  →

Last updated about 4 hours ago

Created by

🇺🇸United States webdrips

Live updates comments and jobs are added and updated live.
  • PHP 8.1

    The issue particularly affects sites running on PHP version 8.1.0 or later.

Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Issue created by @webdrips
  • Status changed to Postponed: needs info almost 2 years ago
  • Comment almost 2 years ago →
    🇳🇱Netherlands Lendude Amsterdam

    @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 over 1 year ago →
    🇳🇱Netherlands Yuri

    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

  • Comment over 1 year ago →
    🇺🇸United States webdrips

    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 ✨ Add visibility control conditions to blocks within Layout Builder Needs work

    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.

  • Status changed to Active about 1 year ago
  • Comment about 1 year ago →
    🇺🇸United States webdrips

    Changing the status back to active

  • Assigned to samit.310@gmail.com
  • Status changed to Needs work 9 months ago
  • Comment 9 months ago →
    🇮🇳India samit.310@gmail.com
  • Merge request !69893338057: Deprecated function: preg_match() → (Open) created by samit.310@gmail.com
  • Pipeline finished with Failed
    9 months ago
    Total: 1312s
    #116300
  • Pipeline finished with Success
    9 months ago
    Total: 481s
    #116317
  • Issue was unassigned.
  • Status changed to Needs review 9 months ago
  • Comment 9 months ago →
    🇮🇳India samit.310@gmail.com
  • Status changed to Needs work 9 months ago
  • Comment 9 months ago →
    🇺🇸United States smustgrave

    #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 7 months ago →
    🇺🇸United States maskedjellybean Portland, OR

    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.

  • First commit to issue fork.
  • Merge request !9314Reroll patch from https://www.drupal.org/project/drupal/issues/3338057 to drupal 10.3 → (Closed) created by Carlitus
  • Pipeline finished with Canceled
    3 months ago
    Total: 114s
    #262622
  • Pipeline finished with Failed
    3 months ago
    Total: 481s
    #262623
  • Comment 3 months ago →
    🇪🇸Spain Carlitus

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

  • Comment 3 months ago →
    System Message
  • First commit to issue fork.
  • Merge request !9720rerolled MR for Drupal 10.3 → (Open) created by paucala
  • Comment about 2 months ago →
    🇪🇸Spain paucala

    Rerolled for Drupal 10.3

  • Comment 29 days ago →
    🇵🇹Portugal dxvargas

    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.

  • Comment 29 days ago →
    🇺🇸United States webdrips

    #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 28 days ago →
    🇵🇹Portugal dxvargas

    @webdrips it is impossible that you have the same error after applying the patch in #19.
    There is only preg_match() method here and it 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.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024