- Issue created by @j_ten_man
- πΊπΈUnited States j_ten_man
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.
- π©πͺGermany jurgenhaas Gottmadingen
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 orMarkup
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.
- πΊπΈUnited States j_ten_man
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.
- Assigned to Thomas Bosviel
- Merge request !13Fix type of output property in ChannelPostRender β (Merged) created by Thomas Bosviel
- π©πͺGermany jurgenhaas Gottmadingen
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 declarestring|MarkupInterface
as the possible types for output, as this is as strict as we can get in this case. And I love strict types ;-) - Status changed to Needs review
2 months ago 10:41am 24 January 2025 -
jurgenhaas β
committed 972a723a on 2.3.x authored by
thomas bosviel β
Issue #3387056 by thomas bosviel, j_ten_man, jurgenhaas: HTML emails do...
-
jurgenhaas β
committed 972a723a on 2.3.x authored by
thomas bosviel β
- π©πͺGermany jurgenhaas Gottmadingen
Thanks everyone, just merged this one.
Automatically closed - issue fixed for 2 weeks with no activity.