Transport list should reflect non-overridden config

Note that the label is already loaded without overrides on this page for example.

Please let me check I understand. When mails get sent out from your site, by default they will use the override: 'mailhog'. If you look in GUI on the transport listing page, it reports that 'mailhog' is the default. However you think this is wrong, and that it should report the other transport?? Can you show any example in Core to confirm that this is correct?

The admin page allows editing config so it should always display the config that is being edited.
Here is an example of why this can be confusing: if I click "set as default" on another transport, nothing happens visually (mailhog is still displayed as default because of the override) but my config has changed. The page should reflect the config change.

It is explained here → .

The core uses it for example in GDToolkit::buildConfigurationForm() or in ThemeExperimentalConfirmForm.

🐛 Prevent saving config entities when configuration overrides are applied Needs work also talks about preventing saving the configuration when it contains overrides.
🐛 Display status message on configuration forms when there are overridden values Fixed also discusses the fact that core philosophy is that config forms don't display overrides (and suggests displaying the overrides in a warning message, not in the form itself).

Thanks for explaining, that makes sense. It would be clearer for me if we copy how it's done in the docs you link to, so like this:

// Get the default transport without overrides.
return \Drupal::config('symfony_mailer.settings')->getOriginal('default_transport') == $this->id();

The config returned is never modified so I think you are right we can use getOriginal() instead of getEditable().
I updated the MR.

Thanks

Now it is unclear the other way around. I was wondering why my local dev setting (mailhog) wasn't showing up in the transport overview. After all, the intention is to adjust the default_transport in a specific environment. Even more confusing is that the overwritten setting is used when sending the test email. So the overview says sendmail is the default, but we use mailhog as the default when sending.

Now it is unclear the other way around. I was wondering why my local dev setting (mailhog) wasn't showing up in the transport overview. After all, the intention is to change the default_transport in a specific environment. Even more confusing is that the overwritten setting is used when sending the test email. So the overview says sendmail is the default, but we use mailhog as the default when sending.

Well, that is the behavior of most of the Drupal back-office when using overridden config.
This is why the config_override_warn module → exists (until 🐛 Display status message on configuration forms when there are overridden values Fixed is fixed).

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