Needs work
Project:
Pathologic
Version:
2.0.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
18 Jun 2026 at 16:56 UTC
Updated:
22 Jun 2026 at 16:39 UTC
Jump to comment: Most recent
Problem/Motivation
Wild cards were permitted in local path configuration for Pathologic for Drupal 6 under #758118: wild card for Additional paths
As far as I can see, these weren't included in the D7 version or later.
We have been patching for modern Drupal under the original issue (which admittedly got derailed onto other topics) but after another required repatch, I'm creating a new issue for visibility, as this functionality has previously been accepted as desirable and it would be good to work towards getting this merged.
So, for example
Instead of configuring
http://sub0.example.com
http://sub1.example.com
http://sub2.example.com
http://sub3.example.com
You would just need to configure
http://*.example.com
Our specific use case is a decoupled site that uses a different domains for different physical locations. Without support for wildcards, there is additional work to do every time we roll out a new location.
Proposed resolution
Update _pathologic_replace() to include wildcards in matching as per patch at #758118-18: wild card for Additional paths
Remaining tasks
Reroll patch from #758118-18: wild card for Additional paths against latest 2.0.x branch- Add tests to cover wildcard functionality
Address phpcs and phpstan failures in current patch by finding an alternative to fnmatch()
User interface changes
Update the help text on the config form to cover wild cards.
API changes
None
Data model changes
None
Issue fork pathologic-3604065
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:
changes
Comments
Comment #3
eli-tComment #4
eli-tComment #5
eli-tLooks like the phpstan and phpcs failures are both the same cause; the presence of fnmatch().
Comment #6
eli-tfnmatch() is discouraged by PHPCS and PHPStan because it is
- see https://www.php.net/manual/en/function.fnmatch.php#refsect1-function.fnm....
There doesn't seem to be a readily available polyfill either.
So we would have to use preg_match() and either convert from simple wildcards in config system and UI to regular expressions at runtime, or just have regexs in the configuration and UI.
Comment #7
eli-tIt transpires symfony/finder, already a direct requirement of Drupal core, has a Glob::toRegex() utility. This could be used to convert the simple wildcard strings to regexs suitable for preg_match() at runtime.
Comment #8
eli-tComment #9
eli-tInitial testing is successful on our site with Drupal 10.6 using the preg_match() and Glob::toRegex() approach.
Current automated tests all pass, though new ones for wildcard handling are still required.
Note that Drupals 9, 10 and 11 all require different major versions of the symfony/finder package from where we source Glob::toRegex(), so we should test all of them.