Problem/Motivation
It is not currently possible to enable or disable this via a settings.php change - it is controlled by the mailer configuration.
Proposed resolution
Add a setting that controls whether it is enabled.
Remaining tasks
Add a setting that controls whether the logging is enabled.
User interface changes
An option exists on the mailer configuration that controls whether the functionality is currently enabled.
API changes
tbd
Data model changes
n/a
Issue fork symfony_mailer_log-3570543
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
damienmckennaI created a MR that adds an "enable logging" option for the main settings page, and provides an update script to set it for existing sites.
Comment #4
svendecabooterThanks for the added functionality. Merged now.
Comment #7
sidgrafix commentedJust my 2 cents but this is not the way to do things. If you want an option to disable that is one thing - but to make it as enabled doesn't logically make sense.
When I "install" a contributed module I expect it to be enabled and not by a setting - as it "should" be the default behavior of any contributed module to be enabled on install (if it has sub features a user may not want to use - then an "enable option" for those features is always good).
If having/adding an option to disable a module as a means to prevent loss of data and configuration normally caused from uninstalling later "especially" when a module has already been introduced and widely used; Adding as "Disable" option, a means to "disable" later rather than adding an enable option is the smarter way to handle things logically. First, you don't need to write an update that adds then has to activate the setting by setting the value for the "enabled" option because it is already enabled. All you need to do is add the config and field for disable and leave the default config to FALSE unchecked so there are zero possibilities of adding breaking changes. Then if someone chooses to disable they can at will.
Sure, for this particular module "done the way it was by adding enabled" is less likely to introduce issues as it is a relatively simple update - however I see this happening a lot across many contributed modules over the last 6 months to a year. I have seen first hand what can happen when introducing an "enable" option as means to allow disabling especially when the update has to cycle through anywhere from hundreds to thousands of entities that were all originally enabled by default and the update fails leaving everything that was enabled disabled, and can turn into a real nightmare fast.
Food for thought!
Comment #8
damienmckennaThere are a lot of dev-focused modules that have options to enable/disable them separate to the fact that the module is installed, e.g. Shield, Reroute Email, etc, etc. This change allows managing that in a simpler way than you would normally, due to the complex way symfony_mailer manages its configuration.