- 🇺🇸United States smustgrave
Since there has been no follow up going to close for now.
If still a valid request please reopen though, maybe updating issue summary for what needs to be done for D10+
Thanks all!
Code that must be able to store the configuration of plugins of different types in CMI, have no way to reference the schemas of those plugins' configuration in their own configuration schemas. To work around this, I created the plugin.plugin_configuration.$plugin_type_id.$plugin_id format convention as documented in
the Plugin module →
.
However, as Drupal core, and likely many contributed modules as well, do not adhere to this format, the configuration schemas of plugins from these projects cannot be referenced generically.
At DrupalCamp Vienna, @alexpott and @Xano discussed the idea of aliasing schemas, which will essentially allow schemas to exist under multiple names. Example:
plugin.plugin_configuration.block.*
type: block_settings.*
These aliases work well in Drupal 8.0.x, but wildcard values are not passed. This means that with this schema, lookups for plugin.plugin_configuration.block.foobar will result in the schema for block_settings.* being loaded instead of the schema for block_settings.foobar.
Resolve schema types by passing on wildcard values from 'parent' types to 'child' types.
To be determined.
None.
None.
None.
Closed: outdated
11.0 🔥
Last updated
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Since there has been no follow up going to close for now.
If still a valid request please reopen though, maybe updating issue summary for what needs to be done for D10+
Thanks all!