Add schema definitions for Tamper plugins

This commit was reset (blame it on temporary confusion):

The current fail in GitLab is perhaps because of this?

    drupalConstraint=10.5.1 (from DRUPAL_CORE)
    core_version=10.5.1

As it stands, the 2/40 schema definitions seem to work fine. Please validate before I work on the remaining 38 definitions.

Thanks for starting this process. We need to do the same for all the other modules as well, that extend ECA. But this one is a good starting point, but it is somehow special: the ECA Tamper module doesn't really define any plugins itself, it derives tamper plugins from the tamper module, and potentially also from others who may implement tamper plugins. This will then result in derived eca_tamper action and condition plugins, both of which will have the same schema definitions.

So, for that case I wonder if we should derive the schema from the plugin source, i.e. from the tamper module. In other words, the eca_tamper module is not really in charge of the config schema, it just relies on what the tamper plugin owner defines about their plugin config.

My suggestion is that we implement a config_schema_info_alter that goes through all the available tamper plugins, determines their schema, and then creates the config schema for ECA action and condition plugins on the fly by using the upstream schema and adding extra properties like eca_data and eca_token_name.

I'm happy to take that on it this touches on areas that are not widely known yet.

Using config_schema_info_alter to generate the schema configs on the fly is a smart idea. Except this is somewhat discouraged in function hook_config_schema_info_alter:

If implementations of this hook add or remove configuration schema a ConfigSchemaAlterException will be thrown. Keep in mind that there are tools that may use the configuration schema for static analysis of configuration files, like the string extractor for the localization system. Such systems won't work with dynamically defined configuration schemas.

For adding new data types use configuration schema YAML files instead.

So that approach has unwanted effects in the UI (see capture). That's a nice catch-22. So it looks like generating a static eca_tamper.schema.yml is perhaps the preferred way to go…?

This MR now attempts to go that way and includes a drush command for generating the schema definitions.

Auto-generating the derived schema definitions is brilliant, I like that.

What I'd like to discuss is if this drush command should be living in the eca_tamper module, as it will exclusively be used by maintainers and not by users. Maybe this can be made more generic and then be moved to the eca_development submodule which is only really used by maintainers. With some extra arguments to the CLI command we could probably achieve a lot not only for eca_tamper, but also for eca_commerce and maybe others, where we have similar requirements. I mean, even if the output is not a hundred percent accurate, it can still create the 98% of schema definition that can be copied into the schema file together with all the other things that may still be handcrafted.

2 other pieces, readme and hook help, are unrelated to this issue and should be moved into separate issues. The readme should then be written such that its content qualifies to be used as the content for the project page on d.o, which it already does. The hook_help is, in my opinion, one of the hooks with no value, I wouldn't want to implement that.

I looked at this again and opened 📌 Add drush command to generate config schema for wrapper plugins Active to build this in a generic way into ECA. We should be able to find the schema definition of the original plugin and use that instead of guessing field types etc. This way we will then also receive extra information like constraints and validators.

@bisonbleu I think I found a way that will help us really making this generic, see my commit in #9

The way this is supposed to be working is that the first 2 entries eca_tamper.default.condition and eca_tamper.default.action are handcrafted, and they define the common extra properties that the eca_tamper module adds to the wrapped plugins.

This is then followed by a list of plugin schema definitions where the original schema key (e.g. tamper.math) will be eca.condition.plugin.eca_tamper_condition:math or action.configuration.eca_tamper:math for conditions and actions.

The rest of the definition is the same as in the original tamper.schema.yml with the type being set to either eca_tamper.default.condition or eca_tamper.default.action. So each of the wrapper definitions extends one of the 2 base definitions and we don't have any repetitive definitions in that file.

When we want to build a drush command to generate this, we would only have to provide the plugin prefix ID from e.g. \Drupal\eca_tamper\Plugin\ECA\Condition\Tamper and the schema type eca_tamper.default.condition. Everything else, the drush command should be able to find out by itself.

I'm therefore closing this issue as we now have a schema definition that's current, and the drush command to re-generate this should be developed in the related issue.