domain_config_ui: account settings shows "remove" button if "system information" is enabled

Probably the same configuration ID.

Confirmed, and it is a pre-existing bug, unrelated to the recent edit-context or switcher work. The relevant line dates back to 2025-09-03.

What is happening

Core's AccountSettingsForm::getEditableConfigNames() returns three config names, with system.site first:

['system.site', 'user.mail', 'user.settings']

domain_config_ui reduces that list to its first element when checking registration:

// DomainConfigFactory::isConfigurationRegisteredForDomain()
$name = is_array($names) ? current($names) : $names;
if (isset($overridable_configurations[$name])) {
  return in_array($domain_id, $overridable_configurations[$name]);
}

So the account settings form is judged entirely by system.site. Once you enable the override on the site information form, system.site is registered for the domain, and on the account settings form the check looks at current($names) (which is system.site), finds it registered, and renders the "remove" button, even though user.mail and user.settings were never enabled.

That also explains why saving account settings writes to the default collection: the per-domain override only engages for registered names, and user.mail / user.settings are not registered. The button is wrong; the save is correct. The same first-name reduction is also in getActiveEditingDomainId().

The only "connection" between the two forms is that AccountSettingsForm lists system.site first and domain_config_ui only inspects the first name.

Possible solutions

The root cause is the current($names) reduction. Dropping it and evaluating per config name is the direction, but the toggler is a single button for a multi-config form, so "registered" needs a defined meaning:

1. Treat the form as registered only when all of its config names are registered for the domain, and make enable/remove act on all of them. The button then reflects the whole form rather than just its first config.
2. Decide the button state from the form's own names while ignoring incidentally shared, globally registered names like system.site. More targeted, but needs a rule for what counts as the form's own config.

There is a real subtlety either way: system.site is legitimately shared, so once registered it is genuinely overridable wherever it is edited, including this form. The mismatch is a binary toggle sitting on a heterogeneous set of config names. Whatever rule we pick, the per-name save behavior should stay name-scoped (the edit context already supports getDomainId($config_name) per name; the factory collapses it to the first name before calling it).

Digging into the fix, I found the root-cause method is shared between two concerns, which makes the naive fix risky.

isConfigurationRegisteredForDomain() drives the toggler (via isRegisteredConfiguration()), but the same path also gates the config load routing through isPerDomainEditable():

// DomainConfigFactory::doLoadMultiple(array $names, ...)
if ($immutable || !$this->isPerDomainEditable($names)) {
  return parent::doLoadMultiple($names, $immutable);
}

doLoadMultiple() passes the whole array, and today's current($names) reduction makes it all-or-nothing on the first name. So simply switching isConfigurationRegisteredForDomain() to "all names registered" would regress a batch load: loading ['system.site', 'user.mail', ...] when only system.site is registered would then return FALSE and load system.site from the default collection, dropping its override in that batch.

The save path is not affected: it goes through doGet($name) with a single name, where "all names" equals that one name. That is also why account settings correctly saves user.mail / user.settings to the default collection.

Plan

1. Change isConfigurationRegisteredForDomain() to "all names registered for the domain", which fixes the toggler showing "remove" when only a shared config like system.site is registered.
2. Make doLoadMultiple() route per name: load each registered name from the domain collection and each unregistered name from the parent, instead of all-or-nothing. This removes the regression above and is more correct than the current first-name behavior.

doGet() (single name) is unchanged. The toggler description will also list the config names the enable/remove action touches, so the shared-config behavior is transparent.

Tests: one asserting the toggler shows "Enable" until all of a multi-config form's names are registered (using AccountSettingsForm's ['system.site', 'user.mail', 'user.settings']), and one asserting a registered config still loads from its domain collection when batch-loaded with an unregistered sibling.

Implemented in MR !390 (against 3.x), with a correction to my earlier comment.

On a closer look the load path is not affected, so the fix is simpler than the two-part plan I described. doGet() calls doLoadMultiple([$name], ...) with a single-element array, and loadMultiple() is immutable, so doLoadMultiple() returns before the registration check is ever reached with a multi-name array. The only caller passing a genuine multi-name set is the toggler, so changing isConfigurationRegisteredForDomain() to require all names needs no matching doLoadMultiple() change.

The fix: isConfigurationRegisteredForDomain() now returns true only when every config name in the set is registered for the domain, so the account settings toggler correctly shows "Enable" until user.mail and user.settings are registered, not just system.site. The toggler also lists the affected config names as a hover title.

Added a kernel test that fails before the change and passes after. Setting to needs review.

@hanoii does it fix your problem? Can we merge it?

Thanks @hanoii for your valuable feedback.

I'll merge this one and create a dedicated issue for the bug you mention.

@hanoii can you verify that MR 391 in related issue fixes the bug you reported?

Agreed, let us go with one control per config (one enable/remove button per config name) instead of a single button for the whole form.

Why this fits: the remove button keeps its meaning, a total removal of an override, but it now acts on a single config at a time. On the account settings form you would get separate controls for system.site, user.mail and user.settings, so clearing the user-related overrides no longer takes system.site (and the name and slogan set on Site information) down with it. You only remove system.site if you explicitly act on its own control.

It also tidies up the original fix here: instead of one toggler whose state had to be derived from "all config names registered", each config shows its own state independently (enable if not yet overridden for the domain, remove if it is). Registration is already per config name, so this is the natural model.

Background that makes the bundling the real culprit: the account settings form contributes only system.site:mail_notification to system.site (a single #config_target); the name and slogan belong to Site information. So both forms share system.site but edit different keys.

Scope note: this is a UX change to the toggler introduced in this issue, so it can land here or as a dedicated "per-config override controls" follow-up. A shared config is still fully removed when you act on its own control (that is intended), so an extra confirmation note for shared configs is optional.

Looking into what exactly?

Ah, ok. Will see what I can do.

Hi @hanoii, could you give a try to MR 395?

The implemented solution uses checkboxes on the deletion confirmation page instead of multiple buttons.

Thanks for testing. I pushed updates to !395:

• A single configuration no longer shows a checkbox: there is nothing to choose, so it is confirmed directly.
• Each configuration's stored values now sit in their own collapsible section, so a long override no longer crowds the page.
• A registered configuration that carries no override values for the domain now shows a "Not overridden for this domain." note instead of an empty block.

On the font sizes and the large title: those come from the core confirmation form and the admin theme, so I would rather not fight them with custom CSS in this module.

The config-sync style diff view is a nice idea, but it is a fair amount of work and a bit outside the scope of a delete confirmation. Could we track it as a separate feature request so it does not hold up this fix?

Good point, done in MR 395: every collapsible section, including the per-config ones, is now expanded by default, so all the overrides and any non-overridden configs are visible at a glance. They can still be collapsed individually as needed.

Thanks @hanoii! It's a lot of work for sure :)

Merging.

Opened !396 as the 3.0.x backport of !395. The DeleteForm change is identical; only the unrelated @internal docblock (absent on 3.0.x) was dropped, and the test update went to the domain_config_ui copy of DomainConfigUiSavedConfigTest since the language UI is not a separate submodule on 3.0.x.