Depends on D19954. Ref T920. This is a step toward a world where "Mailers" are generic and may send messages over a broader array of channels (email, SMS, postal mail).
There are a few major parts here:
- Instead of calling $mailer->setSubject(), $mailer->setFrom(), etc., build in intermediate $message object first, then pass that to the mailer.
- This breaks every mailer! This change on its own does not fix them. I plan to fix them in a series of "update mailer X", "update mailer Y" followups.
- This generally makes the API easier to change in the far future, and in the near future supports mailers accepting different types of $message objects with the same API.
- Pull the "build an email" stuff out into a PhabricatorMailEmailEngine. MetaMTAMail is already a huge object without also doing this translation step. This is just a separation/simplification change, but also tries to fight against MetaMTAMail getting 5K lines of email/sms/whatsapp/postal-mail code.
- Try to rewrite the "build an email" stuff to be a bit more straightforward while making it generate objects. Prior to this change, it had this weird flow:
foreach ($properties as $key => $prop) { switch ($key) { case 'xyz': // ... } }
This is just inherently somewhat hard to puzzle out, and it means that processing order depends on internal property order, which is quite surprising.