Override character set of outgoing e-mails

[vjo03]

Hi,

I'm trying to migrate a 2.2rc2 osCommerce store into version 2.3...

 

I have pretty much got it all up and running, but I need outgoing e-mails to me in iso-8859-1.

 

I use the Norwegian language pack, and to get it all up and running I converted the language pack from utf-8 into iso-8859-1. Maybe that was a bad idea, but that seemed to be the only way to get it all working up against the old database. I tested lots of ideas, but only this way I got it working.

 

So, the language pack is in iso-8859-1 while it looks like outgoing emails is in utf-8 format, so they don't look good at the moment.

Is there any easy way to override the charset of the emails only, or do I really have to go back to scratch and dive into the mess of getting it all to work in utf-8?

 

Kind regards

[Chris H]

You might find that text, which is sent to STORE_OWNER_EMAIL_ADDRESS, is sanitized with htmlspecialchars (though I haven't checked). Looking at the function's definition, on the php website, we find that it accepts 4 arguments. But osC code only ever supplies the first, and accepts defaults for the other 3. We also find

 

'Defines encoding used in conversion. If omitted, the default value for this argument is ISO-8859-1 in versions of PHP prior to 5.4.0, and UTF-8 from PHP 5.4.0 onwards.'

 

So you may need to supply the 3rd argument. Where is MrPhil, when you need him? He is good at this sort of thing.

[vjo03]

Okay, thanks for that.. I will try to look into it. I was hoping to find a "quick fix" of something to change within the include/classes/mail.php for example...

 

The server runs PHP Version 5.3.3-7.

 

When I receive an e-mail sent through osCommerce, the mail header says it is in UTF-8, but it does not look correct. I also know that the content is in iso-8859-1, since i converted the language file myself... I tried to convert back the to UTF-8 the language file that is used when a user requests a password reset. That way, the e-mail was correct, but the websites that used the same language file, of course, ended up with unknown characters.