>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3175060. --> Reported by: [spiderman](https://www.drupal.org/user/1631) >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>In trying to tackle <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/config_enforce_devel/-/work_items/3172512" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/config_enforce_devel/-/work_items/3172512</a></span>, we recognized that the way we store config "registries" should be refactored to conform more to standard convention for config objects, where the top-level structure is a mapping (key -&gt; value) rather than a simple unkeyed array.</p> <p>In considering how to refactor the code to make that change, we realized that our recent performance improvements in <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/config_enforce_devel/-/work_items/3171651" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/config_enforce_devel/-/work_items/3171651</a></span> pointed the way to a better organization of the class structure to better support what the module is doing:</p> <p>* EnforcedConfig - simple data object, just keeps the settings of enforcement (level, hash, name)<br> * TargetModule - a single module where enforced config can live<br> * EnforcedConfigRegistry - set of EnforcedConfig objects' settings, specific to 1 TargetModule<br> * EnforcedConfigCollection - collection of all EnforceConfigRegistry objects, for acting on them en masse<br> * TargetModuleCollection - ensure a default TargetModule exists, and allow EnforcedConfigCollection to gather all available TargetModules</p> <p>With these conceptual pieces, we can reorganize and better encapsulate each one's logic, and clean up the public-facing API for the module as a whole:</p> <p>* TargetModule will contain the single EnforcedConfigRegistry for that module, which encapsulates the logic of reading/writing the (renamed) `config_enforce.registry.[targetmodule].yml` config objects/files.<br> * EnforcedConfigRegistry in turn contains a number of EnforcedConfig data objects that track the "settings" for each config object being enforced (config name, directory, enforcement level, hash, and optional config_form_uri)</p> <p>This should allow us to streamline things and still support a) enforcing single config objects via their primary configuration form, which is the primary way of using Config Enforce, as well as b) acting upon multiple enforced configs at once, as in the case of "generate from module", "generate from active config", "update settings", or mass deletion. It also appears to simplify the data we need to track, and still allow performant operation.</p> <p>This entails some heavy refactoring of the code, for which we'd prefer to wait until we have a reasonable test suite in place, to ensure the existing functionality doesn't regress.</p> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <p>* Build out test suite to cover key functionality of the modules (<span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/config_enforce/-/work_items/3174603" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/config_enforce/-/work_items/3174603</a></span>)<br> * Construct EnforcedConfigCollection class to handle mass Registry management<br> * Factor our EnforcedConfig <code>save()</code> and related methods into EnforcedConfigRegistry<br> * Clean things up further?<br> * PROFIT!</p> <h3 id="summary-api-changes">API changes</h3> <p>Not entirely clear as yet, but the goal is to better encapsulate the logic and clarify the APIs between the classes described above.</p> <h3 id="summary-data-model-changes">Data model changes</h3> <p>We imagine the structure of the <code>config_enforce.enforced_configs.[targetmodule]</code> config object to change from:</p> <pre>system__site:<br>&nbsp; target_module: my_site_module<br>&nbsp; config_directory: config/install<br>&nbsp; config_file_path: modules/custom/my_site_module/config/install/system.site.yml<br>&nbsp; enforcement_level: '20'<br>&nbsp; config_form_uri: /admin/config/system/site-information<br>&nbsp; hash: r_sS8qvN4H7zzH8Z9MAnnroYoytV15MF5bGUxyQZuGE</pre><p>To something more like (and renamed to <code>config_enforce.registry.[targetmodule]</code></p> <pre>target_module: my_site_module<br>enforced_configs:<br>&nbsp; - config_name: system.site<br>&nbsp;&nbsp;&nbsp; config_directory: config/install<br>&nbsp;&nbsp;&nbsp; enforcement_level: '20'<br>&nbsp;&nbsp;&nbsp; config_form_uri: /admin/config/system/site-information<br>&nbsp;&nbsp;&nbsp; hash: r_sS8qvN4H7zzH8Z9MAnnroYoytV15MF5bGUxyQZuGE</pre>