- Issue created by @prudloff
- 🇫🇷France prudloff Lille
Note that the label is already loaded without overrides on this page for example.
- last update
9 months ago 7 pass - @prudloff opened merge request.
- Status changed to Needs review
9 months ago 4:30pm 2 October 2023 - 🇬🇧United Kingdom AdamPS
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?
- 🇫🇷France prudloff Lille
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 inThemeExperimentalConfirmForm
.🐛 Prevent saving config entities when configuration overrides are applied Needs work also talks about preventing saving the configuration when it contains overrides.
🐛 There is no indication on configuration forms if there are overridden values Needs work 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). - Status changed to Needs work
9 months ago 4:48pm 4 October 2023 - 🇬🇧United Kingdom AdamPS
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();
- 🇫🇷France prudloff Lille
The config returned is never modified so I think you are right we can use
getOriginal()
instead ofgetEditable()
.
I updated the MR. - Status changed to Needs review
8 months ago 3:58pm 20 October 2023 -
AdamPS →
committed 0ff71089 on 1.x authored by
prudloff →
Issue #3391090: Transport list should reflect non-overridden config
-
AdamPS →
committed 0ff71089 on 1.x authored by
prudloff →
- Status changed to Fixed
8 months ago 9:20am 21 October 2023 - 🇳🇱Netherlands mishavantol Haarlem
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.
- 🇳🇱Netherlands mishavantol Haarlem
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.
- 🇫🇷France prudloff Lille
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 🐛 There is no indication on configuration forms if there are overridden values Needs work is fixed). Automatically closed - issue fixed for 2 weeks with no activity.