Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
while i wasn't successfully able to get the solution in #1855080: is possible to "switch off" MigrateMailIgnore?? working, i'm not sure that re-enabling the mail system for an entire migration instance is needed.
in my use case, i needed mail enabled solely within a single instance's postImport() method. it would be good to have a bit more flexibility to the timing of re-enabling (and re-disabling) mail system.
Comment | File | Size | Author |
---|---|---|---|
#6 | migrate-mail-system-methods-2095841-6.patch | 3.97 KB | bdone |
#4 | migrate-mail-system-methods-2095841-4.patch | 4.17 KB | bdone |
#1 | migrate-mail-system-methods-2095841-1.patch | 2.13 KB | bdone |
Comments
Comment #1
bdone CreditAttribution: bdone commentedthis patch saves the mail system, prior to the MigrationBase constructor disabling it. It also adds two public methods to toggle the original mail system.
usage example...
Comment #1.0
bdone CreditAttribution: bdone commentedUpdated issue summary.
Comment #2
mikeryanPlease explicitly declare mailSystem in the class.
Consider if we originally had two keys in $conf['mail_system'], default-system and secondary-system. It looks like this will result in removing mail_system entirely, rather than restoring the original values.
Comment #3
mikeryanAlso, see https://drupal.org/comment/8592031#comment-8592031 - I think this feature should make the mail_system saving in the drush import/rollback commands obsolete, that should be removed in this patch.
Thanks.
Comment #4
bdone CreditAttribution: bdone commentedwith fixes #2, and updates to drush commands from #3, here's an updated patch for review.
Comment #5
mikeryanThe if statement here doesn't actually do anything ($system is local to the loop, unsetting it has no effect on anything else). It appears you mean to unset $conf['mail_system'][$system], but even that won't have an effect when all of $conf['mail_system'] gets overwritten in the last line. For that matter, it seems $class rather than $system should be used in the comparison.
At any rate, it seems like just the assignment to $conf['mail_system'] should be sufficient to restore it, unless you're concerned there would have been changes to mail_system during migration that you would want to preserve?
Other than the above, the rest of the patch looks good, thanks.
Comment #6
bdone CreditAttribution: bdone commentedthanks for the feedback @mikeryan. i hadn't considered mail_system changing during the migration and didn't make any changes along those lines. here's a fix dropping the unneeded unset().
Comment #8
mikeryanCommitted, thanks!