Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
When trying to send html emails, they always come through with the html escaped. I'll attach my current patch for this issue.
Steps to reproduce
- Enable the PF Email module.
- Setup ECA (or any other system) that will trigger an email through Push Framework
- Go to /admin/config/system/push_framework and set the text format to an HTML enabled format.
- Trigger the action setup above.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | 3387056-1.patch | 825 bytes | j_ten_man |
Issue fork push_framework-3387056
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
j_ten_man commentedPatch 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.
Comment #3
jurgenhaasGreat 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
ChannelPostRenderevent such that the output variable accepts either string orMarkupso 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.
Comment #4
j_ten_man commentedPotentially 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.
Comment #5
thomas bosviel commentedComment #7
jurgenhaasNot 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
stringtype, instead we should declarestring|MarkupInterfaceas the possible types for output, as this is as strict as we can get in this case. And I love strict types ;-)Comment #8
thomas bosviel commentedI agree, much better solution. Thanks
Comment #10
jurgenhaasThanks everyone, just merged this one.