Use the new #config_target Form API property

TIL thanks to @rosiel that this module exists! 🤯

This would definitely have been helpful when we were working on landing the many issues that made the change record https://www.drupal.org/node/3373502 → a reality. 😅

#config_target will indeed be used to bring functionality similar to this module to Drupal core in 🐛 Display status message on configuration forms when there are overridden values Fixed — I think a review from you would be super valuable there!

COI's #config vs core's #config_target

@rosiel pointed me to https://www.drupal.org/docs/8/modules/config-override-inspector/integrat... → .

COI seems to not have been written with validation constraints in mind (which makes sense). That’s why there are architectural differences.

Furthermore, COI will AFAICT only work when there’s a 1:1 mapping between UI/form elements and config property paths.

That’s specifically what we wanted to avoid in core, because 1:1 mapping of that implies that the UI must be a literal match of the config structure. And config structure makes sense to computers/developers, not to humans 😄

So, while COI looks like a fine contrib module, AFAICT it doesn’t “scale” to meet core’s requirements.

Conclusion

By no means did I mean to duplicate COI's work, I was unfortunately simply unaware. I hope that what you find in core will satisfy you … and I would LOVE to hear from you which things you believe should change/evolve in Drupal core, because I'm certain you have insights we do not yet have!

I've been reviewing the outcome of issue https://www.drupal.org/project/drupal/issues/2408549 🐛 Display status message on configuration forms when there are overridden values Fixed , which was merged into Drupal core some time ago. While the patch originally introduced a #config_data_store property, this was ultimately replaced by the now-standard #config_target property as part of the final implementation.

After inspecting core, I observed that a majority of forms now use #config_target to associate form elements with config values. Looking at the COI module, I noticed that it contains logic referencing the earlier #config_data_store approach, along with a comment linking to https://www.drupal.org/project/drupal/issues/2408549 🐛 Display status message on configuration forms when there are overridden values Fixed . This indicates that the module was already aware of the evolving direction in core and had included provisional support under a different name.

With this in mind, I’ve created a patch that updates COI to support #config_target. It:
1. Maintains backward compatibility with #config, as currently used in the module
2. Adds support for both string and ConfigTarget object variants of #config_target
3. Removes the now-defunct logic and comments referencing #config_data_store

The patch is minimal and focused, following the module’s existing code style and intent.

In response to Wim’s earlier comment: while I understand and appreciate the distinction between COI’s form-level assumptions and core’s broader abstraction goals, I believe this patch is consistent with COI’s purpose and historical context. The presence of the #config_data_store logic demonstrates that the module was not operating independently of core developments, but was in fact tracking them closely.

Separately, now that Drupal core supports #config_target natively, it's possible that fewer overrides will need to be manually defined in https://www.drupal.org/project/config_override_core_fields → . That module currently uses an alter hook to inject ['#config']['key'] on forms that do not expose override metadata. It may be worth auditing and potentially refactoring config_override_core_fields to instead make use of #config_target where applicable. This would separate concerns more clearly: COI would inspect the config structure, while config_override_core_fields would act as a bridge to ensure more fields in core expose the necessary metadata.

Happy to iterate further if needed.