Password Reset Email Template Broken on PHP 8.0

Hi there! I’m working with a couple of users on Reclaim Hosting who are reporting the ‘Forgot Password’ email template changed when the PHP version changed.

The email breaks the URL on PHP 8.0 and looks like this (I changed the full URL to protect privacy):

Please follow this link to reset your password:=0A=0Ahttp://user f452f76472ab4f=0A=0ANeatline Administrator

Switching back to PHP 7.4 returns the correctly formatted email:

Please follow this link to reset your password: hxxp:// Neatline Administrator

We’d ideally like to keep the sites on PHP 8.0 since 7.4 is reaching EOL. The Omeka Sites are running 3.0.2.

I’m stuck trying to troubleshoot more to be able to keep the sites up-to-date. Any help is appreciated!

1 Like

Hmm, I’ll look into this, we haven’t heard a report about it other than this though.

This =0A stuff is visible in the email? That suggests the email is encoded quoted-printable as expected, but perhaps that the email headers are incorrectly not marking that encoding.

All that you’re changing is the PHP version between it working and not working? I don’t reproduce this problem when immediately checking (though I’m checking against the 8.2 beta and not 8.0 specifically).

Could you possibly share the full “source” view of the problematic email, including headers? You could send it as a private message here and/or redact information if you have privacy concerns.

All of the code is visible in the email on PHP 8.0. I just tried to replicate it again by changing PHP versions on my personal test site, but I’m getting the same result on 8.0 and 7.4 from here. Here’s what it looks like as the full email with headers (adding another reply with what it looks like in my inbox.


Here’s what the email looks like in my inbox

That image of the email source gives a clue… there’s something wrong with the email headers.

Every header is supposed to be on its own line but if you look, there are several crammed together.

In particular there’s the line for X-Mailer: it also contains the Date, Content-Type, Content-Transfer-Encoding and Content-Disposition headers on the same line. That Content-Transfer-Encoding header is what makes the =0A parts not be displayed when the user reads the email, and with it improperly stuck not on its own line like it’s supposed to be, you get this result.

You said you tried this personally and get the same results on both 7.4 and 8.0: you mean they’re both broken or both work?

Sorry for the confusion there! The test site was installed on PHP 8.0 and the password reset was broken. It would previously sort itself out by downgrading to PHP 7.4 but this time it remained broken on 7.4.

It looks like PHP did change something about how mail() works in PHP 8.0…:

This is… basically a mess, and whether it’s a problem seems to depend a lot on the specific MTA (sendmail, Postfix, etc.) running on the server.

Can you try something out? Try commenting out this line: (line 61 of application/libraries/Zend/Mail/Transport/Sendmail.php) and see if that gives you an improvement.

1 Like

That worked! The email now looks like this:

So, what we’re going to do here is make Omeka do the equivalent of that change automatically when it’s running on PHP 8+. I can’t guarantee that will eliminate all possible issues like this, but it seems to be the best possible way forward.

1 Like

Thanks! I was able to get this to work. When the fix is available will it ‘break’ this hack?

You did the commenting-out of the line I mentioned above?

When the fix is available, what will happen is that, if you’re running on PHP 8.0 or above, that change will basically be done automatically. Upgrading will overwrite that file and your manual change to it, but the manual change will no longer be required.

1 Like

The fix provided here is now included in Omeka Classic 3.1.

I just upgraded another Omeka Classic instance to 3.0.3 using Installatron on Reclaim, and the email function is broken again: “Activation code is invalid”

I am up to php 8.0.

The fix is only in 3.1.

3.0.3 is older and doesn’t have it. But the same manual fix described above would work.

Yes, thanks. I caught my mistake too late to retract!