Problem/Motivation

Configuration schemas for core's plugins do not use the Plugin module's unified format of plugin.plugin_configuration.$plugin_type.$plugin_id, and as such configuration of those plugins cannot be stored/validated dynamically in a unified way.

Proposed resolution

Expose core's plugin configuration schemas using 'aliases' that conform to the plugin.plugin_configuration.$plugin_type.$plugin_id format.

Remaining tasks

Find out how to alias schemas that do not contain the plugin ID in the configuration, but only in the data type. In these cases, we have no way of extracting the plugin ID, and mapping the alias to the correct schema type that Drupal core provides. As can be seen in the patch, the alias for block and condition plugins dynamically get the plugin ID from the config data and use it to define the alias' data type. Entity reference selector configuration schemas (entity_reference_selection.*) are an example of where that isn't possible, because the data contains no plugin IDs. This is good configuration design (plugin IDs should not be merged with plugin configuration in storage), but poses a problem for us.

User interface changes

None.

API changes

None.

Data model changes

None.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Xano’s picture

Xano’s picture

Issue summary: View changes
Status: Needs review » Needs work
Xano’s picture

See #2629640: Configuration schema aliases for making it possible to expose existing schemas through aliases.

Xano’s picture

Config schema types are static, with the exception that they can be based on arbitrary values within the same config object. If we also store config schema names, we can use this behavior to 'dynamically' set schema types.

Status: Needs review » Needs work

The last submitted patch, 4: plugin_2543420_4.patch, failed testing.

The last submitted patch, 4: plugin_2543420_4.patch, failed testing.

The last submitted patch, 4: plugin_2543420_4.patch, failed testing.

Xano’s picture

Xano’s picture

Status: Needs review » Needs work

The last submitted patch, 9: plugin_2543420_9.patch, failed testing.

The last submitted patch, 9: plugin_2543420_9.patch, failed testing.

The last submitted patch, 9: plugin_2543420_9.patch, failed testing.

Xano’s picture

Xano’s picture

Xano’s picture

We can add support for core's remaining plugin types, once #2633232: Missing fallback plugin configuration schemas lands.

Xano’s picture

Status: Needs review » Fixed

I talked to @GaborHojtsy and checked with Config Inspector, and all seems fine. Now all we need is an upgrade path.

Xano’s picture

Status: Fixed » Needs review

This is still NR.

drunken monkey’s picture

+++ b/PLUGIN_TYPES.md
@@ -19,6 +19,11 @@ on the class, but the default class takes the following:
+- plugin_configuration_schema_id (optional): the ID of the plugin's ¶

You have a trailing space there. Thought I'd point it out since I happened to see it – but, unfortunately, that's about as far as my expertise on this goes.

Xano’s picture

Thanks! I also updated the read of that documentation.

This patch introduces an upgrade path with test coverage.

Xano’s picture

Status: Needs review » Fixed

  • Xano committed ccbe34d on 8.x-2.x
    Issue #2543420 by Xano: Add schemas for core plugins' configuration.
    

Status: Fixed » Closed (fixed)

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