Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
$message['body'][] = (string) \Drupal::service('renderer')->renderPlain($build);
That breaks sending HTML mails for example with swift mailer, which tries to be correct and escapes non-safe HTML.
Proposed resolution
Remove the string casts.
Remaining tasks
User interface changes
API changes
Data model changes
Comment | File | Size | Author |
---|---|---|---|
#11 | remove_contact_mail_string_cast-2666160-11-interdiff.txt | 1.58 KB | Berdir |
#11 | remove_contact_mail_string_cast-2666160-11.patch | 2.9 KB | Berdir |
#2 | remove_contact_mail_string_cast-2666160-2.patch | 1.32 KB | tduong |
Comments
Comment #2
tduong CreditAttribution: tduong at MD Systems GmbH commentedRemoved string cast.
Comment #3
Wim Leers#2506581: Remove SafeMarkup::set() from Renderer::doRender introduced those string casts.
Comment #4
Wim LeersInitially, that patch did not add this string cast. Only since #2506581-44: Remove SafeMarkup::set() from Renderer::doRender, it does. Because since that iteration of the patch,
renderPlain()
is returningSafeStringInterface
(by nowMarkupInterface
).The only reason AFAICT that we added that string cast, is to keep BC.
But perhaps in this particular instance, that was not necessary.
We should get Alex Pott's thoughts on this.
Comment #5
Wim LeersBut overall, +1, because
sounds sensible, and due to this string cast, that mailer cannot detect that this is in fact already considered safe.Comment #6
BerdirSetting to RTBC to get feedback from @alexpott.
I was thinking about tests but I'm not sure it is worth it or even possible. We'd need a HTML test mailer that checks for this, but note that there's also #2223967: Do not decode a contact message twice and it might not be possible to have a useful test without that, which we're currently working around that issue with a custom view builder in a custom module, but we can't work around this problem.
I'd also be OK with just doing this in 8.1.x if we think it's too much of a change for 8.0.x
Comment #7
Wim LeersAgreed with #6.
Comment #8
catchAssigning to @alexpott so he knows this is waiting on him.
Comment #9
alexpottIsn't there an issue with what is considered safe for email being different from html. As far as I can remember, these string casts occurred so that there was no unnecessary API change - maybe something will break now this is an object?
Comment #10
alexpottThinking so more - I'm generally happy that we should delay the string casting. But this needs to be documented on hook_mail(). In an ideal world mail sending would leverage the render system and then we'd delay everything including the render here.
Comment #11
BerdirSomething like this?
Leaving at 8.0.x for now, but I guess this will be 8.1.x only?
Comment #12
alexpott@Berdir thanks that is exactly what I was expecting.
It is shame we don't have anywhere we document some of the expectations around the API but it is not up to this issue to fix that.
Comment #13
BerdirDiscussed with alex that 8.0.x probably isn't going to happen since this is a tiny change to how it worked before.
But, I can't imagine anyone relying on that right now and for almost all cases, you shouldn't even notice if something is a string or Markup object. Someone might do Markup::create() in an alter hook to fix this, but this will continue to work, it will just no longer be required to do that.
Given that and that this is a bugfix, I think this would still be acceptable for 8.1 beta, so changing the version to that.
Comment #14
Wim Leerss/MarkupIntrface/MarkupInterface/
Can be fixed on commit.
Comment #15
alexpottI fixed up the docs to have fqcn...
Discussed with @xjm and @catch and we agreed this was eligible for inclusion in 8.1.x.
Committed 2ef41bb and pushed to 8.1.x and 8.2.x. Thanks!