Thread

At first I thought maybe this was something I did when I upgraded, but it’s now happen on two separate servers when I upgraded from EE 1.6.9 to EE 1.7.0. One server is an IIS server we use at work, and the other is a Linux server I use for personal websites.

This currently seems to only happen with emails, though I suspect it may be happening elsewhere. Emails that used to look like this in my inbox:
“You have received a new post at - whatever topic”

now look like this…

“You_have_received_a_new_post_at_-_whatever_topic”

It happens no matter what email address the notifications are sent too. Any suggestions on how we can fix this? In EE the Default Character Set is utf-8 for both installations.

Thanks,
John

Hi John,

I’m just checking with the rest of team about this and we will respond as soon as we can.

Cheers

Greg

Just chiming in to note that I see exactly the same thing on a Linux server (EngineHosting). Just upgraded today, and tried adding a new member as a test. Notification emails to me as Admin and me as new user both had underlines instead of spaces in email subject line. The notification templates look normal.

Tim

EDIT: Looks like Silenz noticed the same thing, and maybe the problem?

Yup, there have been three reports so far, and Greg can replicate the problem as well. He forwarded this thread to the Dev team for additional info. Thanks in advance for your patience.

Thanks for all your help guys and for looking into this, we appreciate it. I noticed it happened on my EngineHosting account yesterday as well, so that makes for three servers on my end with the issue. Thank you all for confirming it was happening elsewhere. Hopefully a fix is in the works.

On a side note, I seem to remember this happening on one of my larger sites when I upgraded to 1.6.9, and then quickly reverted back. I’m wondering if it’s the same issue now.

-John

Still looking into this one. Thanks again for your patience

John, thanks for looking in to this. Just a note to say that emails sent from FreeForm are not doing the underlining thing. I don’t know what the difference is between FreeForm and the standard EE emails, but FreeForm isn’t affected.

Removed Post

The above was me under my work account, sorry.

Freeform seems to have it’s own way of sending emails. I say that because we’ve run into another interesting problem with Freeform vs. standard EE emails. And they clearly have their own unique methods of sending emails.

To explain, first I should point out that we host our email off site from our server, and that seems to be the root of the issue. When email is hosted within our server’s system (on this particular IIS host), Freeform, EE emails, etc all work fine. As I noted, it’s also an IIS sever, which may account for some issues. But here’s the jist of how I know they work separately.

When using phpMail Freeform does NOT work on our server - to any email address, internal or not. Internal mail to our domain also doesn’t work for any of the EE templates. However external email addresses can receive email send from EE (other than Freeform).

When using STMP Freeform works ONLY for internal email, but not external. EE emails also work internally, but not externally.

So, in our case, Freeform has some issues with our email settings being off-site and phpMail being used. It’s another problem entirely and one I haven’t posted about yet. We’re moving to Engine Hosting and I suspect that’s going to solve our issues promptly.

But it proves that Freeform and EE emails are clearly send using different methods.

Our devs are still looking into this. Thanks for your patience.

It looks like a fix for a rare encoding issue interfered with the subjects.  A more permanent fix has been committed for the next release.  For the short term, I’d suggest a change to system/core/core.email.php around line 836, replace:

if (preg_match('/[^\x00-\x7F]/', $str))
{
    $str = trim(preg_replace('/^(.*)$/m', ' =?'.$PREFS->ini('charset').'?Q?$1?=', $str));
}
else
{
    $str = trim($str);
}

with

$str = trim(preg_replace('/^(.*)$/m', ' =?'.$PREFS->ini('charset').'?Q?$1?=', $str));

Make sense?  And does that do the trick for you?

Thanks, that appears to have worked. I will confirm when another email comes through. But my test via the Communicate tab worked without the spaces.

-John

John, great. Let us know when the other email comes through.

Just wanted to confirm for you guys I’ve tried this now on multiple 1.7.0 installations after upgrading (each which had the underscore problem post-upgrade) and the above fix works on ALL of them. So this definitely solved the problem.

Thanks for your help on this guys, I really do appreciate it.

-John

Hi John,

Thanks for updating us and glad that it’s now working correctly. Please post back if you have further questions or problems.

Cheers

Greg