Problem/Motivation
Saving the text format settings form fails with errors:
'item' is not a supported key.
'block' is not a supported key.
'random' is not a supported key.
'button' is not a supported key.
'img' is not a supported key.
'quote' is not a supported key.
'clear' is not a supported key.
'highlight' is not a supported key.
'link' is an unknown key because filters.shortcode.id is shortcode (see config schema type filter_settings.shortcode).Steps to reproduce
1. Enable shortcode.
2. Try to save a text format.
Proposed resolution
Add a shortcode.schema.yml file.
This will be tricky because the schema depends on the plugins. I'm not sure how to implement that.
Remaining tasks
User interface changes
API changes
Data model changes

| Comment | File | Size | Author |
|---|---|---|---|
| #16 | Screenshot 2024-07-12 9.37.25 PM.png | 39.36 KB | swirt |
| #14 | shortcode-add-filter-settings-config-schema-3457731-14.patch | 278 bytes | jverneaut |
Issue fork shortcode-3457731
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
vincent.hoehnI get the same error, but only in combination with the CKEditor 5 Plugin Pack module.
Comment #4
swirtI am seeing this same issue and not related to CKEditor5_plugin_pack
Comment #5
swirtOur current config prior to 10.3 has this
The complaint is that
What I am not clear on is what the new structure of the config should be.
Comment #6
swirtI tried commenting out the validation to see if I could save the form and export the config to see if the config would take on a different structure. It did not.
The problem seems to be that the file
/Drupal/Core/Validation/Plugin/Validation/Constraint/ValidKeysConstraintValidator.php validate()
went through significant refactoring in 10.3 and broke it for shortcode.
Comment #7
swirtThe problem is that this line
is not grabbing the dynamic keys that are in the settings. So they are not present.
edit:7/8/24. 1:48 ET
$mapping->getDynamicallyValidKeys()
returns array(2)
filter_settings.filter_html = array(3)
filter_settings.filter_url = array(1)
Which later gets flattened to
$all_dynamically_valid_keys
0 => "allowed_html"
1 => "filter_html_help"
2 => "filter_html_nofollow"
3 => "filter_url_length"
none of which are related to shortcodes.
Comment #8
swirtBumping this up to a major bug.
Comment #9
swirtI believe the shortcode module needs to declare a schema for the settings similar to the way other filter plugins declare them.
https://api.drupal.org/api/drupal/core%21modules%21filter%21config%21sch...
Comment #10
vincent.hoehnWe are using the shortcode module without the basic tags, but we have a custom module that uses the shortcode API.
I am trying to implement the configuration scheme as follows:
It's not enough to implement the schema. We have to edit the plugin file (*Shortcode.php), because of the configuration section.
Comment #11
jverneaut commentedLike #10, I'm using the shortcode module without the basic tags. After some trial and error, I was able to get the provided shortcode_example module to work by adding the following minimal configuration at
shortcode_example/config/schema/shortcode_example.schema.ymlwherecolis the name of its defined shortcode:It is therefore possible to add configuration mappings to the base shortcode module from custom shortcode modules which was a sufficient fix in my case to be able to save the text formats.
Comment #12
mortona2k commented@jverneaut I think the issue is needing to determine the schema dynamically, or populating default values for unused parameters.
All the shortcode plugins have their own parameters. Are we able to add all the optional parts to the main schema, or does it only work when you explicitly match the schema file with the plugins in use?
It seems like we need a way to dynamically alter schema?
Comment #13
swirtWhen I was xdebugging some of this I noticed there support for a pattern that is 'settings.*' that other plugins were using. I interpreted that as being essentially allow any settings. Which I think, like mortana2k is suggesting, it a bit more dynamic. I had to step away from this for a bit, so I did not chase that farther.
Comment #14
jverneaut commentedI dug a little deeper and found in the configuration schema docs that the appropriate type for configuration objects with unknown keys is actually
sequence, I then tried to create a configuration file at/config/schema/shortcode.schema.ymlat the root of the base shortcode module with this content and I can then save text formats successfully and the config gets correctly exported.Comment #15
swirtSadly I am away from my machine and can't test this but it seems like the right fix. Nice digging jverneaut.
Comment #16
swirtI was able to test this using simplytest.me and applying the patch
Nicely done jverneaut. Thank you. Changing to RTBC
Comment #17
swirtAnd on a side note, Welcome to Drupal jverneaut. You've been on Drupal.org for less than 15 hours and already have a successful patch submitted. That is pretty impressive. Cheers.
Comment #18
vincent.hoehnThank you jverneaut. The patch works like a charm! I was able to save the settings without errors, and the shortcodes work as expected.
Comment #21
nicxvan commentedI added the missing newline.
Comment #22
nicxvan commentedI had to apply this patch and add this file:
web/modules/custom/custom_shortcode/config/schema/custom_shortcode.schema.yml
Then for each custom shortcode I need the following:
Comment #23
steven snedker commentedI'm very impressed with the solution in #14. Repaired the upcoming version of Wayback Filter as well. Thank you, Julien.
Comment #25
denes.szabo commentedThank you guys, nice improvement! Merged.
Comment #26
denes.szabo commentedComment #27
nicxvan commented