Integrate with the "Configuration Read-only mode" module

Created on 2 July 2021, over 4 years ago
Updated 27 August 2025, about 1 month ago

The contributed Configuration Read-Only Mode module prevents config entity forms from being submitted when the config store is set to read-only. (There is a warning at the top saying, “This form will not be saved because the configuration active store is read-only.”, and the submit button is disabled.)

However, while this usually makes sense for config entity forms, of course, it doesn’t in the case of our confirm forms for reindexing/clearing an index or rebuilding its tracker, which technically use the entity form base class, but don’t actually change any entity (or other config) values.
So, submitting those forms should still be possible.

🐛 Bug report
Status

Postponed

Version

1.0

Component

Framework

Created by

🇦🇹Austria drunken monkey Vienna, Austria

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • First commit to issue fork.
  • 🇺🇸United States averagejoe3000 Swanzey, NH

    The reference issue in #2 was fixed about a year ago. I just ran into this on a project so I've created an MR with my solution.

    I created a submodule so people could easily decide if they wanted to enable this feature or not.

    The submodule uses an event subscriber to mark certain confirm forms as editable. I hardcoded the list of form IDs that should be allowed to be used. My thought process was that any confirm form that doesn't modify config should be allowed, so the confirm forms to disable an index or server are not in the allowed list.

    This should have some tests, but I was unsure how to approach with integrating the 2 modules.

  • Pipeline finished with Success
    about 1 month ago
    Total: 352s
    #583372
  • 🇦🇹Austria drunken monkey Vienna, Austria

    Thanks, looks great!
    However, I see no reason to have that as part of a sub-module. I don’t think the current behavior (not being able to reindex because the config_readonly module is installed) is really expected or desired by anyone.
    And even if it is, there are certainly better ways to implement this than an entire sub-module for four lines of code. (A hiddent setting in our module config, for instance. We do have a few of those already.)

    I therefore removed the submodule and moved the event subscriber directly into the main module.
    I also added the config_readonly module as a dev dependency. Would you be able to write an integration test for this new functionality? It would just have to enable the config_readonly module, then go through all the forms this module provides (use, for instance, the search_api_test_db module to get some config to work with) and make sure that exactly the ones we expect to be submittable actually are.

    In any case, thanks again!
    Would be great to resolve this.

  • 🇺🇸United States averagejoe3000 Swanzey, NH

    That makes sense to me, I went back and forth on whether to do the submodule or not.

    I can take a pass at writing the tests. Thanks for pointing me in the right direction on them, writing tests is still new to me.

  • Pipeline finished with Failed
    25 days ago
    Total: 783s
    #592440
  • 🇺🇸United States averagejoe3000 Swanzey, NH

    Tests have been added. The pipeline is failing, but I'm unsure if due to my new tests or something else.

    Looking at the logs all PHPUnit tests passed (and is showing the 5 new tests I added as passing), but the failure seems to happen at "Uploading artifacts as "archive" to coordinator".

Production build 0.71.5 2024