Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Currency symbol not showing in order emails


accolade

Recommended Posts

Hi,

I have just noticed that the currency symbol is not showing on the order confirmation email. It shows correctly everywhere else on the site, including the admin area and through the actual process. So, while not a problem as such, it is a bit of an irritant. (apparently it is showing as a question mark on the iphone!)

 

Any suggestions where I should look for the problem?

 

Thank you.

Link to comment
Share on other sites

What currency, what symbol, what version of osC, what database and page encoding? Usually the problem is editing the currency setting and cutting and pasting in symbol from a PC application, which is in the wrong encoding (e.g., a Euro sign cut and pasted from Word, which is a Windows-1252 "Smart Quotes" symbol, and pasted into a UTF-8 or Latin-1 page. It won't work. Instead of cutting and pasting in a Euro sign to the currency edit, try typing in & euro; (without the space).

Link to comment
Share on other sites

Thank you

 

Pound sterling (GBP), £, osC 2.3.3, database MySQL 5.0.92-50-log, and English.

 

I have tried what you suggest, typing in & pound; (without the space), and again, shows fine on all front end, but the order confirmation email is now showing the html code :)

 

- example-

Sub-Total: £129.00

 

I know it will be something obvious, but I can't find it

Link to comment
Share on other sites

If you're going to use & pound;, you have to send your emails in HTML mode. Otherwise, if you want to copy and paste in a £ character, it will have to be in an encoding used by your database, store, and email. I think that ordinary non-HTML emails are limited to Latin-1 encoding (if not ASCII), so that may be a sticky problem for you. osC 2.3.3 itself uses UTF-8 (multibyte) encoding, incompatible with Latin-1.

Link to comment
Share on other sites

Perhaps you are being tripped up by the htmlspecialchars function, which is used to sanitise the mail message. The description of the function, on php.net, has this to say about double-encoding

 

When double_encode is turned off PHP will not encode existing html entities, the default is to convert everything.

 

It looks as though the initial ampersand of your & pound; is being encoded as & amp; So turn off double-encoding.

Link to comment
Share on other sites

Thank you. I have reverted back to simply a symbol, as it look tidier on the emails not having a symbol at all. Taking on MrPhil's advice, I have tried copying the symbol from the old version of the shop (which used OS 2.2 MS2) as that used to work fine. Perhaps that will be the simpler fix. (time to test!) Comparing the two, everything else seems to be the same with regards to encoding.

Link to comment
Share on other sites

  • 2 weeks later...

Just in case anyone else has the same problem, at this point this is the change I have made-

in english.php it has -

// charset for web pages and emails

define('CHARSET', 'utf-8');

 

I have changed it to

// charset for web pages and emails

define('CHARSET', 'iso-8859-1');

 

I haven't yet tested on the iphone, but my basic windows system email is now showing the correct symbol.

Link to comment
Share on other sites

Your Pound sign pasted from the old shop will be Latin-1 (single byte), while osC 2.3.x is now UTF-8 (Pound is a two byte character). That's why you had to change the encoding from UTF-8 to Latin-1. Now, your database is probably still in UTF-8, but as long as the Pound sign (stored in the database, I believe) is the only non-ASCII character, you may be able to run. However, if any customer enters data with accented characters, you could have problems when the database tries to sort or otherwise work with such characters.

 

Can you tell if (before), the emails were in HTML or in plain text? If HTML, was & pound; corrupted to & amp;pound;? I'm concerned about your hacking away at the system architecture -- I suspect that things are going to slowly break one after the other.

Link to comment
Share on other sites

  • 8 months later...

Your Pound sign pasted from the old shop will be Latin-1 (single byte), while osC 2.3.x is now UTF-8 (Pound is a two byte character). That's why you had to change the encoding from UTF-8 to Latin-1. Now, your database is probably still in UTF-8, but as long as the Pound sign (stored in the database, I believe) is the only non-ASCII character, you may be able to run. However, if any customer enters data with accented characters, you could have problems when the database tries to sort or otherwise work with such characters.

 

Can you tell if (before), the emails were in HTML or in plain text? If HTML, was & pound; corrupted to & amp;pound;? I'm concerned about your hacking away at the system architecture -- I suspect that things are going to slowly break one after the other.

 

Hi MrPhil

 

I have a similar problem in osc 2.3.3.4 in the admin where the euro sign is showing as ' € ' and the euro sign and French accents are not showing in ' orders' (.ie Carroué )

 

I have checked the character encoding in english.php and it is set to UTF-8 for the admin (my admin is in english) and the french.php in admin/includes/french.php, but no luck. As you mentioned I don't want to change the UTF-8 encoding because it will probably cause problems later.

 

thanks for your ideas...

Len

Link to comment
Share on other sites

The characters are defined and output as UTF-8 (multibyte), but the page is displaying in some single byte encoding (most likely either Latin-1 or CP-1252). In your browser, go to View > Character Set (or similar) and see if the page is displaying as something other than UTF-8. Change it temporarily to UTF-8, and see if all special characters and accented characters display correctly. If the Euro etc. change to correct display, but others go bad, it means you have a mixture of Latin-1 and UTF-8, which is not good. If all non-ASCII characters display correctly now, you've got to track down who is forcing that page to the wrong encoding (single byte, such as Latin-1). Look for setlocale() calls, which should only be in <Language>.php and should indicate UTF-8.

Link to comment
Share on other sites

The encoding is set to UTF-8 in view>/Character Set on my browser.

In which section is the Language.php file? I can only find languages.php in admin/languages/english.php and there ..

there is a notice that '// this may not work under win32 environments..' ( I am using windows xp 32 bit)

 

In english.php I have @setlocale(LC_ALL, array('en_US.UTF-8', 'en_US.UTF8', 'enu_usa'));

In french.php I have define('CHARSET', 'utf-8');

Link to comment
Share on other sites

setlocale for France should be:

 

setlocale(LC_ALL, array('fr_FR.UTF-8', 'fr_FR.UTF8', 'fra_fra'));

 

The reason why it is not is likely you are using an outdated language addon.

Link to comment
Share on other sites

@ phil ,

the admin/includes/english.php has

 

// charset for web pages and emails

define('CHARSET', 'utf-8');

 

there is no 'Latin-1' or 'ISO-8859-1'

 

In admin/includes/french.php I have

 

// charset for web pages and emails

define('CHARSET', 'utf-8'); as well.

 

could there be a .php file somewhere that is overiding the language definition?

Link to comment
Share on other sites

Have your browser tell you what character set it's receiving the page in. Something like View > Character Encoding. Even if the page source (HTML) defines the character set to be UTF-8, I've seen servers that override that and force Latin-1. In that case, every non-ASCII symbol and character (including all accented characters) should be multi-character gibberish, and telling the browser to override the encoding as UTF-8 would work. So check the page(s) giving problems.

Link to comment
Share on other sites

Had an old upgrade site where I had to change old orders manually from € to € in the database but this only effected old orders the new orders came through ok

To improve is to change; to be perfect is to change often.

 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...