The request in #2865419: Allow wildcard for import force was to force import with wildcards. That issue was closed without actually implementing wildcards for the force import. On line 86 it specifically checks for ~foo.bar and doesn't check for the wildcard possibility of ~foo.*

CommentFileSizeAuthor
#9 config_ignore-3160360-3.x.patch2.76 KBpookmish
#5 interdiff_1-5.txt1.07 KBericjenkins
#5 config_ignore-wildcard_force_import-3160360-5.patch884 bytesericjenkins
config_ignore-wildcard_force_import.patch925 bytespookmish

Comments

pookmish created an issue. See original summary.

j_ten_man’s picture

j_ten_man commented

Tested. Works as expected.

This does require that your wildcards come first, but I think that's a fair tradeoff vs performance.

In other words, this does not work:

foo.*
~foo.bar.*

It has to be in this order:

~foo.bar.*
foo.*
pookmish’s picture

pookmish commented

Both orders work in my case. What I'm using this for is to allow subthemes to be enabled and it's ignoring the blocks that are created when turning on a theme.

  - 'core.extension:theme'
  - 'system.theme:default'
  - 'block.block.*'
  - '~block.block.seven_*'
  - '~block.block.my_base_theme*'

With that set as the config ignore settings, I'm able to generate any new theme and enable it without any conflicts with config. The theme creates the new config even if it doesn't have any in the config/install directory and they are all prefixed with the theme name. ie "block.block.new_theme_menu" which are then ignore by the rules I'm using.

Perhaps my use case is slightly different which allows the order to be different.

pookmish’s picture

pookmish commented

Ahh I take back my previous comment. @j_ten_man was correct. I had to move `block.block.*` to the bottom to get the config import to force my custom theme blocks to be imported.

ericjenkins’s picture

ericjenkins commented
StatusFileSize
new config_ignore-wildcard_force_import-3160360-5.patch884 bytes
new interdiff_1-5.txt1.07 KB

I was having a nearly-identical desire for a wildcard-for-forced-import feature in the config_export_ignore project and submitted a proposed patch over there.

Inspecting patch #1 has me thinking I should adjust my logic from:

if (fnmatch($config_ignore_setting, static::FORCE_EXCLUSION_PREFIX . $config_name)) {

to:

if (
  substr($config_ignore_setting, 0, 1) === static::FORCE_EXCLUSION_PREFIX &&
  fnmatch(substr($config_ignore_setting, 1), $config_name)
) {

I've also been having the same negated-wildcard ordering issue mentioned in #2, but I think it could be addressed by creating two separate foreach() loops, and to make up for some of the performance hit we could remove the in_array() check.

Attaching patch #5 and interdiff.

Status: Needs review » Needs work

The last submitted patch, 5: config_ignore-wildcard_force_import-3160360-5.patch, failed testing. View results

grimreaper’s picture

grimreaper
Primary language French
Location France 🇫🇷
commented

Hi,

I have tested patch from comment 5. Works for me.

Thanks!

nicholasthompson’s picture

nicholasthompson
Primary language English
commented
Status: Needs work » Reviewed & tested by the community

Patch 5 worked for me too - thank you!

pookmish’s picture

pookmish commented
StatusFileSize
new config_ignore-3160360-3.x.patch2.76 KB

I took a run at the patch for the 3.x version. I've updated the unit test as well.

pookmish’s picture

pookmish commented

I believe this is outdated now with the 8.x-3.0-rc1 release. I am able to use wildcard force imports without the need for any patch. If anyone can confirm, this issue might be closed.

bircher’s picture

bircher
Location 🇨🇿
commented
Status: Reviewed & tested by the community » Fixed

Yes this is fixed now, we also have a test for it.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.