I installed Mail System 7.x-2.31 and set Site-wide default MailSystemInterface to DevelMailLog. When I was finished testing email features I disabled the Mail System module and then uninstalled it. All site emails failed to go out. I checked the variables editor and found the following left behind.

mail_system
a:1:{s:14:"default-system";s:12:"DevelMailLog";}

I flushed caches and mail was still broken. I manually deleted it using the Devel variable editor and now site wide email works again (password recovery, new user, etc).

Shouldn't the module delete this variable itself on uninstall?

Comments

gregrenner’s picture

gregrenner commented

subscribe

pillarsdotnet’s picture

pillarsdotnet commented

The mail_system variable is part of Drupal core and does not belong to this module. There are many ways that the mail_system variable could be set other than by this module. How would you propose that I distinguish between a change made by this module and a change made elsewhere?

gregrenner’s picture

gregrenner commented

How about returning Drupal core variables back to how the module found them?

  • Get original value at install, save to different variable name.
  • Finish installing module.
  • On uninstall, return system variable back to its original value.

Sorry if that won't work, but having all site emails stop irrevocably because this module gets used hardly seems like an acceptable workflow. Or how about some help text on the settings page like "Hey this will disable emails permanently, even after you uninstall this module, until you manually update variables table."

pillarsdotnet’s picture

pillarsdotnet commented
Status: Active » Closed (works as designed)

How about returning Drupal core variables back to how the module found them?

The problem is, other mail-sending modules may have reason to modify the mailsystem core variable. Setting it back to defaults (that is, unsetting it, since by default it is not set at all) would be disrespectful of other mailing modules.

Consider the following scenarios:

Usual scenario:
Step Procedure Effect on mailsystem variable
1 Install Mailsystem module None
2 Install a Mailing module that requires Mailsystem Adds its own format/send classes.
3 Uninstall a Mailing module that requires Mailsystem Removes its own format/send classes.
4 Uninstall Mailsystem module None

Another possible scenario:
Step Procedure Effect on mailsystem variable
1 Install Mailsystem module None
2 Install a Mailing module that does not require Mailsystem Set to its own format/send classes.
3 Uninstall Mailsystem module None

Your problem scenario:
Step Procedure Effect on mailsystem variable
1 Install Mailsystem module None
2 Use Mailsystem UI to change the mailsystem variable. Set as requested by the user.
3 Uninstall Mailsystem module None
5 Discover that Drupal is still trying to send mail as requested. None
6 Submit bug report against Mailsystem for performing exactly as designed. None
7 Install the Devel module and set the mailsystem variable manually. Set as requested by the user.

Your proposed solution:
Step Procedure Effect on mailsystem variable
1 Install Mailsystem module None
2 Use Mailsystem API to change the mailsystem variable. Set as requested by the user.
3 Uninstall Mailsystem module Restored to original (unset) state.
5 Successfully send mail via default classes. None

My imagined scenario, after implementing your proposal:
Step Procedure Effect on mailsystem variable
1 Install Mailsystem module None
2 Install a Mailing module that does not require Mailsystem Set to its own format/send classes.
3 Uninstall Mailsystem module Restored to original unset state
4 Discover that the installed Mailing module is now broken. None
5 Submit support requests against both Mailsystem and the other Mailing module. None
6 Uninstall the Mailing module. (module-dependent; usually none)
7 Re-install the Mailing module. Set to its own format/send classes.