UTF-8 Zen-Cart Tutorial for v1.3.x

I have a related problem... I added a second zen cart to our database after upgrading to 1.39. All good, except I had trouble getting the Collation set to utf8_general_ci for the new tables.
So I ran a sript that updated all of the tables to utf8_general_ci.

That worked, but now my 1st shopping cart, which always displayed Japanese properly, is displaying garbage characters.
However, when I go in to Admin and look at the source (e.g. Product Description) the Japanese is fine. So it's all still correctly in the datablase.

The encoding of the cart comes up as utf-8,

and no changes I can make via the browser make the Japanese not look like garbage.

But still, when I log in to the admin and try to edit the text, it's fine (real Japanese characters).

Finally, in the cart view, SOME Japanese is displaying correctly. It is the Japanese from the php files. So any boilerplate text from the files displays properly in the cart, and any database text displays properly in Admin, but it is trashed in the cart.

Sorry for describing that several different ways. It's not a problem I've seen before.

Thanks!

I am trying the script on a development copy of my site which was unfortunately created as latin1_swedish_ci somehow. It was running along fine, but then threw a fatal error part-way through the process:

Fatal error: Maximum execution time of 30 seconds exceeded in C:\wamp\www\latin1-to-utf8-conversion.php on line **90

**There were plenty of other tables converted fine before this so I'm thinking I just need to up the timeout.

Do you know where I can do this?

Thanks.

I added this to the top of the script:

set_time_limit(300);

Execution took 135 seconds for me. Others might want to add the same before trying to run it against a zen db.

DrByte:

You said your admin html shows utf-8, but your storefront does not.
Thus (assuming you're using english) you need to update your /includes/languages/english.php -- define CHARSET as utf-8

I was scratching my head for a while as to why my admin worked, but my storefront didn't... the above gave me a hint:

If you have a template over ride for your english.php, you need to edit THAT one also!

/includes/languages/<your_template>/english.php

Like, DOH!

My client got this message:

1267 Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (latin1_general_ci,IMPLICIT) for operation 'locate'
in:
[SELECT c.customers_email_address as customers_email_address FROM customers as c LEFT JOIN configuration as q on LOCATE( c.customers_email_address, q.configuration_value) >= 1 WHERE configuration_key = 'NEWSONLY_SUBSCRIPTION_TEST_GROUP' ]

So I decided that just converting the database to a standard utf8 would be the answer.

I have never done this before but I ran into an immediate problem. Now I know it's first thing in the morning and I'm not totally awake yet but I swear I put in the correct database settings - I copied them from the configure file but the connection isn't made to the database.

Says it's using the correct database but then says using the correct user name and password yes but access denied.

Could any server settings prevent this from running? I don't see how but the site is on a new server and I did create the problem by using the configure tables from a new installation with the rest of the database from the old hosting.