HTML emails do not work

Patch attached.

The issue stems from the fact that the ChannelPostRender event casts the $output variable to a string, so we lose the Markup class on it.

Great finding @j_ten_man, thanks for reporting this. Wouldn't it be better, to avoid casting in the first place? I mean, we could update the ChannelPostRender event such that the output variable accepts either string or Markup so that we never even loose context. What do you think?

When we continue working on this, please turn this into an issue fork with a merge request. Patches will no longer work soon, so we've already changed workflow to MRs, which is much more convenient for development, review and everything else.

Potentially that's a better solution - it allows other event subscribers to correctly handle the text that way. I wasn't sure of other unintended consequences of doing it that way as it would potentially be an API change, and this solution was good enough for my needs.

Not sure, if this is already ready for review, since the issue status doesn't indicate that yet. But from what I can see in the MR so far, I wouldn't remove the string type, instead we should declare string|MarkupInterface as the possible types for output, as this is as strict as we can get in this case. And I love strict types ;-)