Problem/Motivation
In #3428486: Fix invalid schema definition @Grevil found schema issues with Micon.
Looking into the schema I think the module is missing the schema definitions for its fields entirely!
The schema was first introduced in #3271002: Fix coding standards, add installation test and fix schema errors a while ago, but I think we didn't run into issues, because the fields were not set up and tested entirely combined with tests?
As Micon extends StringItem I guess we shouldn't define that part of the schema ourselves but inherit the string schema, if possible?
https://git.drupalcode.org/project/drupal/-/blob/11.x/core/config/schema...
I think looking at the largest contrib field modules could speed things up:
- https://git.drupalcode.org/project/linkit/-/blob/8.x-5.x/config/schema/l...
- https://git.drupalcode.org/project/entity_reference_revisions/-/blob/8.x...
- https://git.drupalcode.org/project/paragraphs/-/blob/8.x-1.x/config/sche...
- https://git.drupalcode.org/project/address/-/blob/2.x/config/schema/addr...
Another option might be to unset these settings like written here: https://www.drupal.org/project/drowl_paragraphs_bs/issues/3428486#commen... if they are really not used and not useful!
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | 2024-03-21 10_06_29-Manage fields _ Drush Site-Install.png | 32.62 KB | grevil |
Issue fork micon-3428592
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 #2
anybodyComment #3
anybodyComment #5
grevil commentedInterestingly enough, config inspector AND the tests both won't show any schema errors... interesting.
Comment #6
grevil commentedNo idea, the schema definition seems to be fine on micon's site.
I tried redefining the storage definition using:
and "extending" it:
similiar to https://git.drupalcode.org/project/entity_reference_revisions/-/blame/8....
Nothing seems to work and neither the tests nor the config inspector throws any schema errors before or after the changes.
Comment #7
anybody@Grevil: Did you set up such a field like the one that shows the error in the tests?
My guess is, that this will first happen with a field set up?
Comment #8
grevil commentedFixed, please review!
Comment #10
anybody@Grevil: Nice! I left two minor comments.
But we shouldn't tag a release too soon with this change, I think. We need to be sure this has no side-effects.
Also one hard part is left I guess: Removing the old config from existing installations?
Perhaps you can find a snippet for that?
Comment #11
grevil commentedAlright all done! Added an update hook as well, and it runs well and as expected:

After the update, the field still works as expected and displays the given icon. Furthermore, no default_value is overriden or any other important field storage values.
Comment #12
anybodyThanks @Grevil! LGTM! Still it's a heavy, but important change, so I'd like to have a sign-off by another maintaner who tested this.
RTBC from my side.
We should then wait with a new tagged release, once signed off and merged into dev, to see if this causes trouble somewhere.
Thank you!
Comment #13
grevil commentedComment #14
grevil commented@Anybody found another schema error:
Comment #15
grevil commentedAlright, should be fixed now, back to needs review.
Comment #16
grevil commentedI guess, @jacobbell84 is quite busy. I just ran into this issue again. As you RTBC'd this, I am just going to merge it. It was tested enough in my opinion.
Comment #18
grevil commented