Sitewide default mailsystem changing back to default

I'd look for the variable string in other modules. Some modules try to automatically configure/enable themself.

We are experiencing the same issue on Version: 7.x-2.34 as well. Seems to happen randomly.

Also seems to have only started happening a month or two ago, so i wonder if a recent Drupal or common module update caused the issue.

I am experiencing the same issue on version 7.x-2.34, too. Email that went out at 9:00am yesterday was fine, then ones that went out later in the day were formatted using the default class. No module updates or core update happened yesterday, though. Only weirdness was Amazon outage, which did affect us. :)

This happened to me as well (also on 7.x-2,34), sometime after 1pm on Feb. 28 (so no mail has been delivered for a week, but the client only just caught it.) No core or module changes had been made to the site since January 23, when I upgraded the site to Drupal 7.53, updated Domain Access and Imagecache Actions, and uninstalled Node Convert and Node Clone Tab. I probably also ran Module Missing Messages Fixer at that time.

I don't know if this is a change or whether I just can't remember how to configure this module, but before the reset (and still on my dev site), the settings page offered fields for other installed modules that might handle mail, like this:

and after the reset (on production) it looks like this:

So where did all those module fields go (and how do I add them back?)

I thought I was going crazy that the settings could have reset on their own so I was relieved to find this issue. FWIW the site is hosted on Pantheon. If there are any other details I can share that might help solve this, please let me know.

Sorry for the additional comments; my screenshots disappeared from my comment above and I had to re-upload them.

I can confirm that this does seem to be a recurring issue - when I have noticed it happening before - it just sets back to default but in this last instance, my custom formatter/send class was no longer there at all and I had to recreate it. I think this bug should be set to major as it significantly impacts all site e-mail when it happens.

In my case I am using mimemail for the formatter and mailgun for delivery. Works great when it works but this has now happened a few times that it has reset itself and I think there is definitely something going on here.

Thanks

Thanks @iaminawe — I agree this is a major bug. My client's site just reset for a second time and they realized no mail has gone out in the last 10 days. The client reports that the last mail they received was 3/22; I last touched the site on 3/9 so this really does seem random.

this just happened to our site, major issue as some crucial mails were missed. would this be an issue with the core?

edit: update; seems like our mailsystem file became undreadable in default/file/mailsystem which caused the variables to go back to default, of course it became readable soon after but the settings remained default.

Hi All,

Am also facing the same problem for the version 7.x-2.34 has hosted in Pantheon server. This problem is due to file permission changing(agree to command #10).

While pantheon team updating the file system for some security reason. The default/files permission has changed and reset to the previous configuration. This is the root problem for the Mail System default configuration changes.

btw I've made a module that checks the mail settings and reverts them on cron run when the mailsystem files are readable again - also has some notification/watchdog settings. Check it out here:

https://www.drupal.org/project/mail_settings_checker

I have also got same issue few days back. In my case, after reset email was being sent as plain text. I wanted to set html mail if anytime it reset from actual configuration. To fix this issue, I have used below code & its working for me.

function hook_init() {    
   if (module_exists('mailsystem')) {
		 $mailsystem_classes = mailsystem_get_classes();
		 $mailsystem = variable_get('mail_system', null);
		 if(!isset($mailsystem_classes['HTMLMailSystem__SmtpMailSystem'])) {
			 $mailsystem['default-system'] = 'HTMLMailSystem';
			 variable_set('mail_system', $mailsystem);
		 }
		 else {
			 $mailsystem['default-system'] = 'HTMLMailSystem__SmtpMailSystem';
			 variable_set('mail_system', $mailsystem);
		 }
	}
}

If you use the module from #12 I'd recommend using this patch: https://www.drupal.org/project/mail_settings_checker/issues/2933981#comm...

For Pantheon users please see the troubleshooting page: https://pantheon.io/docs/email/#troubleshooting

Just ran into the same issue.

We have two site environments (staging and prod) running like-for-like code and databases. But all e-mails from the prod site stopped working, or sending as corrupted plain-text. Where as our staging site had no issues at all.

After spending time comparing the two, I noticed that the mail system settings on prod had reverted to their default settings.

These settings are stored in the mail_system variable, which confirmed this. On prod it was the default value (a single item in an array) where as on staging it had 2 items (inc. our custom mail class) both set to Mime Mail. After copying the variable back from staging to live, e-mails sprung back to life.

Reading #11 it sounds like it could be permission based, but the prod default/mailsystem folder seem to be correct (664) and the file within it hasn't been modified recently and still contains the correct information. It's unclear how this file would have any affect on the mail_system variable.

Just to add, we're running on AWS so it's possible they made some sort of file-system change which temporarily could have made it unreadable. At the least can we make the module detect when the file becomes unreadable and avoid overwriting the settings it has stored in it's mail_system variable, and flag it as an issue on the status report screen.

I have the same problem as Welsby. No problems with the beta website, however, the issue appears on production. I'm also hosting on AWS.

I have noticed that other settings also are reverted back: I'm using the Administration theme module (admin_theme) allowing other users to use Adminimal theme. I need to clear the cache, to fix the theme issue and manually revert the settings for mail.

Not sure if this is related to #3014951: cache_set is temporary.

Not sure, but this might be fixed w/ #3014951: cache_set is temporary.

I just encountered this issue w/ 7.x-2.35 hosted at Pantheon.

Effected the production site but not the development sites.
I recreated the classes for the 1/2 dozen modules that were originally set.

Did you have #3014951: cache_set is temporary applied?

I have found an issue inside my custom module. After fixing it other problems like Mail System have disappeared.

All reports here seem to be for 7.x-2.x versions.

Did anyone find a solution for this? The year 2020, just wanted to phone home...Running on Pantheon too.