Problem/Motivation
When importing a form_mode_control config change I get the following error:
The configuration property _core.default_config_hash doesn't exist.
Our config doesn't have _core.default_config_hash yet and core is trying to set it automatically. The problem is that in Drupal\Core\Config\Schema\ArrayElement::get(), line 64, there's a check to make sure default_config_hash is an instance of TypedConfigInterface. With this module's config present it's not, it's an instance of \Drupal\Core\TypedData\Plugin\DataType\StringData. This happens because config/schema/form_mode_control.settings.yml is telling Drupal that form_mode_control.settings is an sequence of only strings, but since Drupal adds a few default properties we can't make this assumption. Config objects should be set to type: config_object.
Proposed resolution
Nest the permissions under a parent key, e.g. permissions. A temporary quickfix could be to revert #3359220: Add schema for form_mode_control.settings.
Remaining tasks
Update the schema, any places using the settings config and any existing config data to match the new structure.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 3431354-5.patch | 1.47 KB | marthinal |
Issue fork form_mode_control-3431354
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
dieterholvoet commentedComment #3
dieterholvoet commentedComment #4
dieterholvoet commentedComment #5
marthinal commentedI have this error when updating Drupal core:
I updated the schema + implemented hook_update_N
Comment #6
balagan commentedConfirming that patch in #5 solves that problem, but probably that should be a separate issue.
Comment #7
pianomansam commentedPatch in #5 fixes this issue for me as well.
Comment #9
mandclu commentedI merged the patch in #5, but not 100% clear if that addresses the original issue here. The patch does resolve a fatal error when updating to Drupal 10.3, so wanted to make a new release with this fix. Feel free to reopen this issue if more work is needed.
Comment #10
dieterholvoet commentedThe update hook in #5 does not work at all, there was no
sequencekey in the previous config schema. I'll update the patch, hopefully this hasn't been released yet.Comment #11
dieterholvoet commentedLooks like it has been released. I'll add a new update hook instead of fixing the existing one.
Comment #12
dieterholvoet commentedThe configuration form also hasn't been updated to work with the new config format. Kind of a shame that this has been released without proper testing.
Comment #13
dieterholvoet commentedComment #15
balagan commentedThis is already merged in 2.4.
Comment #16
dieterholvoet commented@balaganb you didn't read my comment in #10, this issue is not actually fixed.
Comment #17
dieterholvoet commented@mandclu would you mind having a look at this? The config form is still broken in the current release.
Comment #18
eduardo morales albertiInstalling config_inspector we have several errors related to the config from form_mode_control.
Error 'use The form mode default linked to block_content entity( banner_bar )' is not a supported key....
The Mr solves the issue.
Comment #19
eduardo morales albertiAny news? The last release was one year ago
Comment #20
defcon0 commentedIssues here, as well :(
Comment #22
defcon0 commentedOK, we've had additional problems when opening the user overview page. Here FormModePermission::roleToFormMode() ran and tried to store the config into the old, wrong schema. This was missing in the MR #13 I guess.
I opened a new MR #16
Comment #23
jaydarnellEdit: Disregard, I believe I'm experiencing a separate problem.
Comment #24
dieterholvoet commented@defcon0 next time just add your changes to the existing MR. I just did, so I'm going to close your MR.
Comment #28
dieterholvoet commented