Adding alternative plain text version & attachments when formatting the message, not sending, to play well with views_send

Although mail() does run your mail through drupal_alter('swiftmailer', $mailer, $m) which ultimately would allow other modules to directly manipulate the e-mail, it isn't doing much more than that. At least with respect to formatting.

I'm not quite sure what you mean with

most of the formatting work

. Right now, format creates a plain message of a HTML version (if applicable) and process any inline image attachments. The mail function mostly just puts the pieces together and instantiates a SwiftMailer representation of the given mail - and ships it.

Were you thinking of anything else in particular?

I didn't read the issue description well enough; I now see that it relates to attachments. Not formatting in the sense of formatting an e-mail's layout.

You'd like that format() prepares the e-mail up to the point that it is "self contained". That is, is should also hold attachments. You then want to be able to serialize/deserialize emails and not worry about wether files are still available upon sending the email (which could happen a day or two after you scheduled it for sending).

That would be possible; but would attachment size be an issue? Do you spool messages to the database? What if someone spools 10000 messages with a 1MB attachment? You'll suddenly require 10GB more of your database; that might be an issue on hosted websites.

What's your take on that?

I folded the other issue into this for now so we can get consensus on the direction.
We might or might not re-separate this later.

I dug through the views_send codebase and got a feeling for how it does things.
It's right that mimemail (which was D7 defacto standard) does things quite different to swiftmailer (which seems string in the D8 ecosystem).
But when using swiftmailer both for ->format() and ->send(), things should work out.
The problem i see in the current views_send codebase is that views_send_deliver() assumes all necessary information is in 5 items of $message and throws away the rest. That assumption should be simple to remove. Postponing until new insights on this.

function views_send_deliver($message) {
  if (is_array($message)) {
    $message = (object) $message;
  }

  $key = 'direct';
  $headers = unserialize($message->headers);

  $mail = array(
    'to' => $message->to_mail,
    'from' => $message->from_mail,
    'subject' => $message->subject,
    'body' => $message->body,
    'headers' => $headers,
  );

  $system =  $mail_backend = \Drupal::service('plugin.manager.mail')->getInstance(array('module' => 'views_send', 'key' => $key));
  return $system->mail($mail);
}

Added googlefood.

@hansfn: I'm really happy you chime in here! As swiftmailer maintainer i'm totally willing to put in some energy to improve the ecosystem of the most important main modules, and views_send is definitely on my radar.
I did not actively use views_send yet, but maybe i'll soon do and might suggest a patch for #10 (unless below!).

Currently we're doing a sprint on getting swiftmailer 2.x to beta. Unfortunately no one i know has bandwidth for this. But if you (or someone else) provides a patch for this issue before beta, i'd be more thant happy to review it!

> PS! The Views Send code is crappy - I made a crappy D7 port and then a probably even worse D8 port.

Yes i noticed that... But it's there and works for some.

> Anyway, what many people forget when they think Views Send is doing strange things, is that is supports spooling the message and sending them later using cron.

Did you notice that swiftmailer can handle the spooling part? This might be a chance to get an upcoming cleanup version of views_send more focused. ;-)