Fix config schema violation

Looks like you tried to update from eu_cookie_compliance-1.8 to 1.14, in which range a config schema change was introduced and handled by seemingly proper hook_update_N()s. During this process, you had the config schema validator service enabled (which is a good practice on development environments anyway) which prevented you from:

• importing old config into new schema, AND
• updating old config to new one.

So in short, the commit that introduced the schema change shouldn't have removed the old schema.

@svenryen why this works as designed?

you had the config schema validator service enabled (which is a good practice on development environments anyway)

This class: https://github.com/drupal/core/blob/9.1.x/lib/Drupal/Core/Config/Develop...

I can reopen it, but I don't really understand what needs to be done.

All the fields he lists in the issue summary are removed from the module either because they were not needed or because their name changed. We don't have any plan of bringing them back.

If somebody can suggest what to actually do with this issue, we can look into it.

Well, I believe the issue that was reported is an unexpected behavior of Drupal. I wonder if Drupal core itself has a policy for changing/removing configs in a minor/patch version or only in a new major. As module maintainers, we are facing similar issues due to a lack of documentation about certain best practices, do-s, and don't-s.

@xr576, we made sure to provide an update hook whenever we changed names of config items, from what I understood, that's the best practice should need be.

I feel that this is related to this issue and why Config schema checker did not become a default enabled thing in local dev envs...

Since it can't hurt to have those keys defined and it will solve problems for people who have the config schema validator service enabled, I'm committing a slightly modified version of the patch (indicating DEPRECATED for the variables in question in case somebody inspects the file and stumble upon the unused keys).

Thank you!

If the minimum required Drupal core version becomes >= 9.1 even https://www.drupal.org/node/3129881 can be used here.

We can't drop Drupal 8, as we have 10000s of sites using the drupal 8 version of this module and I doubt they will all update to Drupal 9 (even though they should).

Hi @svenryen,

Just noticed a typo on your patch:
cookie_categories:
type: sting
label: 'Cookie categories (DEPRECATED)'

Thanks for noticing that @lesleyfernandes.

Does it cause any issues, warnings or errors?

I fixed the misspelling. Thanks for spotting that!