- ๐บ๐ธUnited States nicxvan
@pamneela good point actually. Existing sites already have the setting. New installs of core don't need it. And for people that need it after installing they have the change record. I've untagged.
Sorry for the confusion.
- ๐ฆ๐บAustralia pameeela
@nicxvan could you expand on why you think this change should be called out? The setting doesn't do anything. Why would it be disruptive for it to not be set on a new install?
The Needs Review Queue Bot โ tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide โ to find step-by-step guides for working with issues.
- ๐ฎ๐ณIndia kunal.sachdev
@phenaproxima I think this comment ( #18 ๐ Add validation constraints to system.theme Needs work ) was meant for ๐ [PP-1] Add validation constraints to core.extension Postponed .
- ๐บ๐ธUnited States phenaproxima Massachusetts
That's why I wonder if ExtensionExists really makes sense in the context of core.extension.
The core.extension config is the source of truth about what extensions are installed. ExtensionExists is basically validating against that, at the end of the day, and therefore it doesn't make a ton of sense for core.extension to have that constraint, does it?
- ๐ฎ๐ณIndia kunal.sachdev
The test is failing because in
RecipeRunner::installTheme()
we do\Drupal::service('theme_installer')->install([$theme]);
and in
ThemeInstaller
we have$extension_config ->set("theme.$key", 0) ->save(TRUE);
which also tries to validate the config and it breaks for
ExtensionExistsContraint
with error message 'Theme stark is not installed', which is true.