- Update the inbound whitelist.
- Add a little support for media configuration.
- Add a service call timeout (see T5969).
- Drop the needless word "Implementation" from the Adapter class tree. I could call these "Mailers" instead of "Adapters", but then we get "PhabricatorMailMailer" which feels questionable.
Used bin/mail send-test to send mail via Postmark with various options (mulitple recipients, text vs html, attachments).
I believe this change is substantially correct if we accept that D19955 is substantially correct, but tests should pass again soon to provide slightly more confidence.
(This was moved, not deleted, but the new file isn't similar enough for Git to figure it out.)
Are these commented out as a migration step?
So I googled this and only got hits for Phabricator revisions. This annotation is here to satisfy the linter for classes that can't be marked as abstract or final?
Yeah, since I haven't updated all the adapters we get runtime fatals loading them if these don't have default implementations. I'll remove these once I update all the adapters.
Yeah, the linter was complaining.
This is a pretty old rule out of T795 very long ago, which waffled a bit around @stable and then got swapped to @concrete-extensible later or something.
The original issue was that people kept sending us diffs to replace final/private/protected with public so they could extend random things in weird ways. In the cheery days of 2011 I was initially onboard with this, but soured quickly and moved toward "final absolutely everything we can".
Over time we made it to a world where every class is either abstract or final, and I think that's the right outcome. There's a linter to warn about cases which aren't abstract or final.
This class is "wrong": it should be final. However, SES extends it to use SMTP logic. An SES adapter is not a kind of PHPMailerLite adapter and this inheritance is definitely not "pure" or "correct", but I'll hopefully fix that a diff or two down the line and remove this comment/annotation/TODO, or fix it whenever T12404 happens if not here.
Ideally, we should get rid of all of these and then make the linter rule stop allowing the exception. We only have 8 left including this one, although some may be a bit tricky to exorcise.