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

Command icon 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

damienmckenna created an issue. See original summary.

damienmckenna’s picture

Status: Active » Needs review

I 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.

svendecabooter’s picture

Status: Needs review » Fixed

Thanks for the added functionality. Merged now.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

sidgrafix’s picture

Just 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!

damienmckenna’s picture

There 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.

Status: Fixed » Closed (fixed)

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