Mime messages #30416
Mime messages #30416
Conversation
36a06d0 to
c9c55dc
Compare
src/Symfony/Component/Mime/CharacterReader/Utf8CharacterReader.php
Outdated
Show resolved
Hide resolved
| // % and / are CPU intensive, so, maybe find a better way | ||
| $ignored = $strlen % $this->width; | ||
| $ignoredChars = $ignored ? substr($string, -$ignored) : ''; | ||
| $currentMap = $this->width; |
There was a problem hiding this comment.
seems you have a type error here, currentMap must be an array but it is assigned with an int
There was a problem hiding this comment.
removed the type hint for now, the code is quite messy, so it will need more thinking
src/Symfony/Component/Mime/CharacterReader/GenericFixedWidthCharacterReader.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/Mime/CharacterReader/GenericFixedWidthCharacterReader.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/Mime/CharacterReader/GenericFixedWidthCharacterReader.php
Outdated
Show resolved
Hide resolved
a5f485a to
96878a7
Compare
There was a problem hiding this comment.
That's a lot of work!
Character readers embed lots of logic. Do we want to be a bit more strict and just reject invalid UTF-8? An alternative could be to consider invalid UTF-8 as CP1252 and set a flag telling this was declared as UTF-8 but didn't really match. But that's for later I suppose :)
| $this->twig = $twig; | ||
| $this->context = $context; | ||
| if (class_exists(HtmlConverter::class)) { | ||
| $this->converter = new HtmlConverter([ |
There was a problem hiding this comment.
How could we provide autodiscovery for this?
A "suggest" entry in composer.json maybe, but that's barely visible.
I don't have a better idea. (making it a requirement with runtime suggestion for the package?)
There was a problem hiding this comment.
That seems like a good place to start - throw an exception when/if it's used (in convertHtmlToText()). So, if you set the text & html body, you'll never need it and never get an exception about missing it. But if you do, we say:
Cannot automatically convert HTML body to a text body. Run "composer require league/html-to-markdown"
or set the text content explicitly.
There was a problem hiding this comment.
I like your suggestion @weaverryan, can you create a PR for it?
| * | ||
| * @experimental in 4.3 | ||
| */ | ||
| final class Renderer |
There was a problem hiding this comment.
Where is the class used? Or where do we plan to use it?
There was a problem hiding this comment.
I thought you were at my keynote, listening carefully :) Everything is explained in the presentation linked in the description of the PR.
There was a problem hiding this comment.
my core point is related to the design of the class :)
if it's final and has no interface, then type-hinting for it means creating strong coupling, while it could be usefull to provide an alternative implementation (eg another html-to-txt - I used to use w3m for that job and it does it nicely)
c741006 to
ed0858c
Compare
This PR was merged into the 4.3-dev branch. Discussion ---------- Mime messages | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | many on Swiftmailer | License | MIT | Doc PR | upcoming As announced today at SymfonyLive Lille, here is the new MIME component. This PR is one step towards the new Symfony Mailer (announced at Symfony London). It started as a fork of Swiftmailer, but soon enough I rewrote almost everything to make it (hopefully) better and more flexible. I've removed all the complexity of Swiftmailer when it comes to multiparts for instance. Some big differences with Swiftmailer: * Way less complexity (no crazy dependency injection when not needed, less interfaces, no cache) * Plain data object and no state (out are the observers for charset and encoding, in are POPO and serializable objects) * No magic regarding multipart management, but a nice wrapper for the most common use cases swiftmailer/swiftmailer#434 swiftmailer/swiftmailer#775 swiftmailer/swiftmailer#946 swiftmailer/swiftmailer#615 swiftmailer/swiftmailer#184 swiftmailer/swiftmailer#56 and probably many others * More Symfony-like * Messages are built on-demand and we do not mess up with your headers/body (Swiftmailer add headers and change yours, but here, we generate needed headers when converting the message as a string, they are not stored -- it means for instance that generating an Email twice will give you 2 different Date headers) * and probably more that I don't remember right now I've also kept some nice features from Swiftmailer like support for any charset. More information on the slides: https://speakerdeck.com/fabpot/2-new-symfony-components-httpclient-and-mime Commits ------- ee787d1 [Mime] added classes for generating MIME messages
As announced today at SymfonyLive Lille, here is the new MIME component.
This PR is one step towards the new Symfony Mailer (announced at Symfony London). It started as a fork of Swiftmailer, but soon enough I rewrote almost everything to make it (hopefully) better and more flexible. I've removed all the complexity of Swiftmailer when it comes to multiparts for instance.
Some big differences with Swiftmailer:
Multipart hierarchy is god damn wrong. swiftmailer/swiftmailer#434
Multipart message is build up incorrectly swiftmailer/swiftmailer#775
AddPart and alternative body swiftmailer/swiftmailer#946
Content-Type: multipart/related not set when needed swiftmailer/swiftmailer#615
Swift_Image produces MIME-type multipart/related instead of multipart/alternative swiftmailer/swiftmailer#184
setBody() + addPart() with embedded images doesn't correctly add multipart/alternative entity swiftmailer/swiftmailer#56
and probably many others
I've also kept some nice features from Swiftmailer like support for any charset.
More information on the slides:
https://speakerdeck.com/fabpot/2-new-symfony-components-httpclient-and-mime