We are using this module on a website that also uses config_readonly.
When I try to access any admin page, it crashes with this error:

[Tue Apr 16 16:47:26.203534 2019] [php7:notice] [pid 23496] [client 127.0.0.1:54246] Uncaught PHP Exception Drupal\\config_readonly\\Exception\\ConfigReadonlyStorageException: "Your site configuration active store is currently locked." at /home/insite/production/sites/insite-scalab/web/modules/contrib/config_readonly/src/Config/ConfigReadonlyStorage.php line 141

This seems to happen because roleToFormMode() is called on each admin page load and tries to save permissions in the config everytime. (And our config is currently locked by config_read_only.)

The attached patch correctly works around the issue for us, by preventing $configuration->set() if this configuration key already exists.
(But maybe a cleaner way to solve this would be to save the configuration only when new form modes are created.)

Command icon 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

prudloff created an issue. See original summary.

prudloff’s picture

StatusFileSize
new731 bytes
jonraedeke’s picture

The patch in #2 works for me. /admin/people was also white screening for me before applying this patch.

I'm a little confused why this module needs to set permissions on those pages. It's a huge performance hit as well.

mandclu’s picture

Status: Active » Needs review
mandclu’s picture

Status: Needs review » Closed (outdated)
Related issues: +#3046679: Drupal Extend (module page) hangs after installing Form Mode Control

There was a more substantial refactoring of the permissions code in #3046679: Drupal Extend (module page) hangs after installing Form Mode Control so hopefully that will address the concern raised here. If not, feel free to reopen it.

I'm inclined to agree that in general the permission code should be run much more selectively, but I'll have to give some some more thought on what the new approach will be, and likely include that in a new major release.

timwood’s picture

Status: Closed (outdated) » Active

We are still encountering this issue after updating to the 2.0 release of form_mode_control as part of our upgrade from Drupal 8.9 to 9.2. The error occurs when config_readonly is enabled and enforced and only for certain admin screens such as /admin/people, /admin/people/permissions, /admin/people/permissions/[ROLE]. If we uninstall the form_mode_control module, the error goes away. If config_readonly enforcement is set to FALSE, the error goes away. If I downgrade to the 8.x-2.0-rc6 release and apply the patch from this issue, the error goes away.

foodslover’s picture

StatusFileSize
new814 bytes

This patch will fix the config_readonly bug for 8.x-2.0

timwood’s picture

Version: 8.x-2.0-rc5 » 8.x-2.x-dev
Status: Active » Needs review

Setting as needs review and hiding older patch file.

mandclu’s picture

Apologies, it seems that once again I've merged another issue that makes substantial changes to the FormModePermission class, this time #3228381: Container rebuild performance. Can someone test if a fix here is still needed, and if so provide an updated patch?

foodslover’s picture

StatusFileSize
new775 bytes

This patch fixes the config_readonly (8.x-1.0-beta4) bug for form_mode_control v8.x-2.1

dieterholvoet made their first commit to this issue’s fork.

dieterholvoet’s picture

  • dieterholvoet committed 73ea5eb9 on 8.x-2.x
    Issue #3048591 by prudloff, timwood, foodslover, dieterholvoet: Causes...
dieterholvoet’s picture

Status: Needs review » Fixed

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.