Support » Plugin: Events Manager » Notification emails display & instead of &

  • Resolved Daedalon


    1. In the notification emails I see “&amp”; instead of “&”.

    My guess is that htmlspecialchars() is called one time too many.

    2. Since this is not worth opening a separate topic on its own, I’d like to suggest that the Event Submitted template would default to showing “View this event – #_EVENTURL” before “Edit this event” instead of the current reverse order. I’ve changed ours to do this so the change to the defaults wouldn’t affect our site, but it might help all future installations, so wanted to bring this to your consideration.

Viewing 15 replies - 1 through 15 (of 23 total)
  • 1. Did you enable Settings > Emails > Email Settings > Send HTML Emails and/or try changing mail sending method?

    1. No, the emails are sent as plaintext. This happens with PHP mail function, Sendmail, Qmail and WP Mail sending methods, everything except SMTP which we don’t use. These methods shouldn’t have anything to do with htmlspecialchars conversions.

    Digging into the code I found that the $subject and $body parameters that are used to call EM_Mailer::send() via EM_Event->email_send() are already formatted wrong at the time of that call. The fix can be applied at em-emails.php by locating the lines 47-49:

    $subject = $EM_Event->output(get_option('dbem_event_published_email_subject'), 'raw');
    	        	$body = $EM_Event->output(get_option('dbem_event_published_email_body'), $output_type);
    		        $EM_Event->email_send( $subject, $body, $admin_emails);

    and adding four lines, in effect changing them to

    $subject = $EM_Event->output(get_option('dbem_event_published_email_subject'), 'raw');
    	        	$body = $EM_Event->output(get_option('dbem_event_published_email_body'), $output_type);
    				if ( $output_type != "html" ) {
    					$subject = htmlspecialchars_decode( $subject );
    					$body = htmlspecialchars_decode( $body );
    		        $EM_Event->email_send( $subject, $body, $admin_emails);

    The same four-line if should also be inserted right above the $EM_Event->email_send() call on lines 41 and 26, after renaming $message to $body on lines 41, 38 and 35 (I thought that renaming was done a month ago already). These two make sure the also other notification emails get the proper formatting.

    Possibly an even more proper fix is to make classes/em-event.php’s function output() apply htmlspecialchars_decode() always when it is called with the parameter used for plaintext emails.

    Plugin Author Marcus


    will test/fix

    2. we’ll be revising the templates in the future but right now to save more work for translators we will leave as is and do it in one go ina few months.

    1. Great!

    2. Sounds good as well.

    Plugin Author Marcus


    btw, Ive tested this on a shared server using phpmail and I can’t reproduce this. are you on the latest versions of EM? We made some adjustments recently to email sending and html formatting.

    Does it happen also for booking emails e.g. confirmations?

    This has happened with all recent EM version. Using latest 5.3 now.

    The main reason seems to be that the event titles are in the database in a htmlencoded format. I’ve had to add a check to templates/forms/event-editor.php to filter $EM_Event->event_name always through html_entity_decode(), otherwise the input field gets populated with “&” instead of “&” and so forth. Html_entity_decode() works better instead of htmlspecialchars_decode() that I used in the patch above, as also characters such as “@” are affected.

    I don’t know why the event_name field is in the db in an encoded format but all the others are in a raw format, but this has required to filter the data through html_entity_decode every time it’s retrieved from db and put into a field where all the characters shouldn’t be encoded (eg. yes, @ not).

    If you have the event_name field content in the db in raw format, eg. “&” instead of “&”, then it must be something on our end only.

    Plugin Author Marcus


    ah… maybe I didn’t check this way, I just modified the email template to test it out.

    so the problem then is if you create an event with a title like & and your email uses #_EVENTNAME?

    If you have any example data (e.g. event title or any other info reproducing your situation) that I can use to test that’d be nice. I’m going to release 5.3.1 now though so it’ll have to wait until next release (or earlier a dev version)

    Yes, more or less. Recap for clarity:

    1. User creates an event with “&” in the title.
      -> The database entry has “&” instead of “&” in the title.
    2. Email notifications were on.
      -> The notification email shows “&” in the event title instead of “&”.
      – This happens because the event_name data from db was in encoded format and it was sent in the email without decoding it first.
    3. User visits the front-end edit event page, which uses the default template.
      -> Event title field shows “&” instead of “&”.
      – This happens because the event_name data from db was in encoded format and templates/forms/event-editor.php encodes it yet again: htmlspecialchars($EM_Event->event_name,ENT_QUOTES)

    Generally speaking, depending on the context, the output needs to be encoded a) only via htmlspecialchars( ENT_QUOTES ), or b) more fully via html_entity_decode() or c) not at all. Now the only way to write secure and functional front-end code is to first decode event_name and then, if needed, re-encode it.

    Doing so is a better choice than having “&” be displayed to users, so I hope that EM core implements either:

    • this workaround, so that in all places where EM_Event->event_name is used, it is decoded (as needed in emails and templates) and then encoded in the proper way if needed (inside event-editor.php’s < input >), or
    • the long-term solution of making sure all event data, including event_name, is written to database in a raw, nonencoded format. When implementing this, a certain amount of care is needed to convert the existing event data just once, regardless of from which to which version the user is updating.

    As can be seen above,’s BBpress is also overly aggressive in converting & amp; (without space) to &. The first (or only) “&” on any line except “1. User creates…”, should be read as “& amp;” (without space).

    The issue persists in EM 5.3.1.

    Plugin Author Marcus


    noted down, will look into this

    Another workaround would be to have EM_Events::get() and related functions always run event title through html_entity_decode() before passing it onwards.

    Plugin Author Marcus


    btw, this should be fixed in 5.3.5

    Excellent, will test.

    The old issue with HTML entities being encoded in notification emails still persists in Submitting an event with a title of “&” results in an email notification showing the title as “& amp;”.


    thanks, am going to test this out and inform Marcus about it incase that this is a known bug.

Viewing 15 replies - 1 through 15 (of 23 total)
  • The topic ‘Notification emails display & instead of &’ is closed to new replies.