Deleting the system.site:page.front config results in a PHP deprecation

Drupal Core 9 does not have a PHP module.

Please let us know the steps to reproduce.

A stack trace would probably help.

Configure it at admin/config/development/logging. Let's leave the issue metadata alone for now until there is a way to reproduce this bug.

I also getting the same issue in Drupal 10.0.8.

Hi @All,

I am not sure this patch will resolve the issue.
The issue is because of passing empty string in preg_quote()

Hi,

i just tested the patch for 10.2.0 and 10.2.1 and it's working well.

Thanks

Patch doesn't work if system.site page.front is null. I don't know what lead to the circumstance it was null in my case, i suspect config_filter/config_ignore, but it was. Solved it by doing drush cset system.site page.front /node. this means $this->getFrontPagePath() doesn't always return a string.

getFrontpagePath could return $this->frontPage ?? ''; would be a solution I guess.

This issue is filed against a component that has been removed from Drupal core a long time ago and thus is not seen by the community. I am changing the component.

Steps to reproduce were asked for 2 years ago and they have not been supplied. What is needed is how to recreated the problem from a fresh install of Drupal 10 or 11.

Since we need more information to move forward with this issue, I am keeping the status at Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

I still got this error, when we are using the :
$node = \Drupal::routeMatch()->getParameter('node');

in this hook:
_preprocess_html(&$variables) {

we have this preg_quote error

This issue stems from the use of $this->getFrontPagePath() as the first parameter of the preg_quote() function in web/core/lib/Drupal/Core/Path/PathMatcher::matchPath method. We need to ensure that the first argument is always a string. In the attached patch, I’ve added a check to validate the returned value accordingly

Fixes should be in MRs

Issue summary should be updated with reliable steps to reproduce (moving to PNMI for that)

Also rest of sections should be filled in

Possibly will need test coverage.

I still have the Deprecated function: preg_quote(): Passing null to parameter

@sir_squall: This issue needs to be updated as specified in comment 23. Anything you can do on that end will help this to be solved.

I found another thread with a Similar issue:
https://www.drupal.org/project/domain/issues/3295160

I don't know how to do the MRs..

That’s ok. There are other issue updates needed besides code.

I was able to trigger this in a simple kernel test where I want to check that some custom entity routes are marked as admin.

/**
 * Tests the EntityAdminHtmlRouteProvider.
 */
class EntityAdminHtmlRouteProviderTest extends KernelTestBase {

  /**
   * {@inheritdoc}
   */
  protected static $modules = [
    'mymodule',
    'domain',
    'node',
    'text',
    'user',
    'system',
  ];

  /**
   * The entity type manager service.
   *
   * @var \Drupal\Core\Entity\EntityTypeManagerInterface
   */
  protected EntityTypeManagerInterface $entityTypeManager;

  /**
   * @var \Drupal\Core\Routing\AccessAwareRouter
   */
  protected AccessAwareRouter $router;

  /**
   * {@inheritdoc}
   */
  protected function setUp(): void {
    parent::setUp();
    $this->installEntitySchema('mymodule');
    $this->installSchema('system', ['sequences']);
    $this->entityTypeManager = $this->container->get('entity_type.manager');
    $this->router = $this->container->get('router');
  }

  /**
   * Tests if the canonical route is correctly configured.
   */
  public function testCanonicalRoute(): void {
    $collection = $this->router->getRouteCollection();
    $route = $collection->get('entity.mymodule_entity.canonical');
    $this->assertTrue($route->getOption('_admin_route'), 'The route is marked as an admin route.');
  }

}

The test passes, but is marked with a deprecation. Not sure how to get around it.

I reconfigured the test to not rely on a custom module that also required Domain (for the domain.negotiator service in one of its classes) and this issue went away. It must be something in Domain module and similar modules that rely on core/lib/Drupal/Core/Path/PathMatcher::matchPath.

Hello all. I was a Windows programmer but never a website/php one and have successfully used Drupal functionality for many years.
However, the charity of which I'm a member has a free account with Krystal who are very helpful - but they're not developers. We needed to upgrade our old Drupal 9 site so I deleted the old installation and installed, using a Softaculous script, a new version 11.x. It seemed to go well apart from an error re 'trusted_host_patterns' - which I managed to fix.

However, trying to access Basic Site Settings to set things like the home page produces the error "The website encountered an unexpected error. Try again later." and the log file shows "Deprecated function: preg_quote(): Passing null to parameter #1 ($str) of type string is deprecated in Drupal\Core\Path\PathMatcher->matchPath()"

The team at Krystal Hosting installed version 10.4.6 in a 'subdirectory' and that did not display the same error so I deleted the 11.x install and installed 10.4.6 using a different Softaculous script. This produced the same 'trusted_host_patterns' error and the same error when trying to access Basic Site Settings.

This is how I've ended up here posting this message. With being no PHP or Drupal developer I am at a loss to work out what is wrong and, more importantly, how to fix it. So it works in a subdirectory but not when at the actual website.

Please can anyone suggest some solution as I am at a complete loss.
Many thanks in anticipation of your help.

David

Should this be moved back to NW if someone can add steps.

This is pretty easy to reproduce, adding to the IS.

If anyone is facing this issue, setting the page.front config key in system.site configuration should fix it. You may have to use drush to do this by using drush cedit system.site and adding a front key under page, or update your exported config directly. The UI doesn't seem to be functional when this happens.

Hiding the patches, work will need to be pushed to a new MR.

Test-only coverage can be found here https://git.drupalcode.org/issue/drupal-3327662/-/jobs/7523684

Solution seems straight forward enough and don't see any issue.

Updating title

Backported down to 10.6.x as an eligible bug fix.

Committed and pushed 675ec8e209f to main and f6154ecc5a7 to 11.x and 76b064e83ce to 11.3.x and 867fd8e8e28 to 10.6.x. Thanks!