The notifications module will, if so configured, send email on node_save() - this can be perilous when testing migration into a site with notifications enabled. I lobbied Moshe to include a debug mail system class in devel: #625062: Fake Mail Library for sending / logging mails to a text file to debug, and made use of it on my current project, but never did get around to documenting how to do this publicly. And that's for the best - as the project approaches deployment, we'll need to disable devel, but we don't want the final migration to throw emails. Also, that mail class logs all emails to /tmp, and we ran out of disk space after doing multiple full test migrations. So, I think Moshe's initial instinct was correct - Migrate should implement its own mail system class, enabled by default; and, in addition, it should /dev/null the emails.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | migrate_mail_system_class_prevent-1254398-11.patch | 399 bytes | lliss |
Comments
Comment #1
drewish commentedI definitely need this. Just accidentally sent out 6000+ emails. The half of that when my stub created users with status=0, then the other half when the full import switched it over to status=1.
Comment #2
mikeryanOuch! Sorry to hear that... I did implement the basic support for this, thought I had committed it but apparently I forgot. It turned out this wasn't enough for our case, since we had notifications configured to queue email for a cron run, so I wanted to address that as well - I hate to have any contrib module support in the main Migrate module, but this is dangerous enough that it's worth it.
Anyway, I'll dig up the basic mail handler and get that committed.
Comment #3
moshe weitzman commentedFYI, I added this to Devel-7.x. It is hard coded into settings.php so even if devel goes missing, you could not send mail (i think). Feel free to copy that code into Migrate if you want.
Comment #4
moshe weitzman commentedOops. I read the OP and now see what you are going for. Sure, proceed.
Comment #5
mikeryanPushed the basic support for now, but it needs testing.
Comment #6
mikeryanComment #7
drewish commentedDon't we need to add this code to the .info file? I'm getting a bunch of warnings like:
class_implements(): Class MigrateMailIgnore does not exist and could not be loadedOr should it be magically loaded based on the name?
Comment #8
mikeryanYeah, this hit me as well. I had thought that modulename.mail.inc would automatically get loaded by core when seeking mail classes, but it does seem like we need to put it in the .info file...
Comment #9
drewish commentedYeah looked at system.info and they spell it out. I'll patch it.
Comment #10
mikeryanThanks!
Comment #11
lliss commentedLooks like this never made it in. Here's a simple patch to add that line to the info file.
Comment #12
mikeryandrewish did commit this fix.
Comment #14
brentgIn case anyone wants to negate this effect, to send mails, you can easily allow the mails to send by adding the global $conf and changing the 'mail_system' parameters, to know the right mail_system parameters for you, I would suggest you do a dsm on a different page then the migrate, for me the default-system was 'HTMLMailSystem__SmtpMailSystem' and the htmlmail was 'HTMLMailSystem' .
Comment #15
paulvb commentedIf you do want to send mails during your migrate you can add this to your constructor
$this->restoreMailSystem();