what about 5.3.9?
i don’t think it’s a problem with emails themselves, but how the front-end submission form dealt with entities, which I think is sorted now
Still happened with 5.3.9 and a non-modified forms/event-editor.php. & is shown as & amp;, < is shown as & lt; and so forth in notification email. Didn’t notice this before, but even the edit event link is wrong: [siteurl]/[editevent]/?action=edit& #038;event_id=1234 (without the space). Shouldn’t have that “#038;”.
I’ll have another look, but I remember this being fixed, so can you re-confirm reproducing it this way:
sending mail as html is disabled (so plaintext)
you’re using #_EVENTURL or #_EVENTNAME and that’s converting any relevant characters into html entities?
Steps taken on a 5.3.9:
1. Checked email sending settings: HTML is disabled (emails are plaintext).
2. Renamed the template folder, so only default templates are used.
3. Opened the page for submitting an event.
Changed name to: & <
Changed start date.
Changed location to an already existing one. Submitted. Event got automatically published.
4. Received email notification with the subject: “Published Event – & amp; & lt;” (without the two spaces).
A line from the message body: “Name: & amp; & lt;” (without the two spaces). This part comes from #_EVENTNAME.
Checked database. The name of this event is in database as “& <“, exactly as it should. Some events have “& amp;” in their event_name due to pre-5.3.9 code. It seems that between retrieval from database and the sending of email the characters are HTML encoded even when the email is plaintext.
Tried also with HTML emails. In them the subject is incorrectly encoded, but body is shown properly. Mails are sent using PHP mail function.
Also noticed that having a < and then > removes both and everything in between them. This can be seen both by submitting an event without a date and looking at the name field, or submitting an event successfully and looking at the title. Publishing “& <123> >” results in an email subject “Published Event – & amp; & gt;” and a database field event_name of “& >”.
I’ve been spending (too much) time testing this nuance, and it turns out that this is how WP behaves.
Try making a test user an author and try submitting this post title:
Test Post ' & >< - " '
Only Editors/Admins get away with this.
I don’t think it’s worth risking converting entities in the message of emails for these special cases (that’s why you can turn on HTML emails), but I do agree with the subject needing decoding since that is always plaintext, so that’ll be done next update.
That’s good news about the subject line, that has been the most noticeable thing. Thanks for looking into this.
Wouldn’t it be possible to esc_attr() the non-HTML body and then unencode it? This would have a small performance hit on the server when sending an email, but the emails would always be properly (un)encoded.
HTML emails consume more bandwidth and aren’t as readable on all programs, so we’d rather enable that only for those emails that need rich formatting: images, tables, font colors and sizes etc. Odd that WordPress encodes the non-HTML email bodies for non-Editors/Admins. If I’d know more about the specifics I’d see about opening a bug in core Trac.
Wouldn’t it be possible to esc_attr() the non-HTML body and then unencode it?
Given you could potentially reencode bad html i wouldn’t take that risk… but you can 🙂
probably the easiest way is creating a custom class which extends our EM_Mailer, overwrite that global $EM_Mailer variable, and then add a send function which does your filtering first.
