Random  all over my site

Feznizzle:

Dumb question... but I have to ask!

On an old zc139h, I'm attempting to follow CONVERT TO UTF8 instructions found here:
https://www.zen-cart.com/content.php?313-should-i-convert-my-store-from-iso-8859-1-to-utf8

Step one says set the define for CHARSET to 'utf-8'.
Step two says set DB_CHARSET to 'utf8'.

The first reference contains a dash (utf-8), the second does not. Is that correct?
Yes.

Browsers want it one way, and databases want it the other way. Irritating, but true.

I thought that might be the case, thanks.

But... neither of the zc139h configure files contain:
define('DB_CHARSET', 'xxxx');

Should I just add that line?

Feznizzle:

Dumb question... but I have to ask!

On an old zc139h, I'm attempting to follow CONVERT TO UTF8 instructions found here:
https://www.zen-cart.com/content.php?313-should-i-convert-my-store-from-iso-8859-1-to-utf8

Step one says set the define for CHARSET to 'utf-8'.
Step two says set DB_CHARSET to 'utf8'.

The first reference contains a dash (utf-8), the second does not. Is that correct?
The concept of a different DB_CHARSET for utf8/latin1 didn't get into the Zen Cart core until v1.5.0; I'm not sure what good it will do to update the database to UTF8 when the core v1.3.9h Zen Cart code doesn't know what to do with the difference.

Feznizzle:

I thought that might be the case, thanks.

But... neither of the zc139h configure files contain:
define('DB_CHARSET', 'xxxx');

Should I just add that line?
Correct. Prior to v1.5.0 it was always assumed that things used latin1.

If you're using the latest version of Zen Cart, it will auto-define DB_CHARSET for you if you don't. And upgrading will put the define into configure.php for you if relevant.

So, yes, if you're still stuck with using the obsolete v1.3.9 then yes you'll have to add it if you're doing conversions. Very few good reasons to stay with 2010 version though.

@DrByte, I tried to talk the client into updating but they declined. So my project is just adding new products (20k+, not to mention 2k categories).

@lat9, the reason I am doing this is because my uploads are triggering the "Â" problem all over the place. Are you saying that changing the site to UTF8 won't help me? Won't resolve the  issue?

What I'm saying is that the v1.3.9h core code isn't going to "understand" what a DB_CHARSET means. I don't know if modifying the database to be utf8 is going to correct your problem or introduce additional issues.

If you're converting to UTF8 then there's a ton of value in actually upgrading.
It's very possible that you've got language files using non-utf8 characters in them, so will get undesired symbols.
There could also be a lot of PHP files that have old latin1 symbols in them. The upgrade replaces all those core files with "clean" ones, so avoids those issues.

The FAQ article about converting to utf8 is based on the dependency of you also running Zen Cart v1.5.x or higher. If you're trying to bolt stuff onto the old version, you'll have to do additional coding to retrofit it.

Hmmm. Ok. Maybe I need to go a different direction then.

The problem only occurs with Easy Populate 4. When I export, the data contains the funny characters. When I import, the funny chars are created and inserted. But if I directly edit the mySQL table, no problems.

And the same data that looks fine on the Live site contains garbage when exporting from EP4. But it looks fine on the site.

I'm off to figure out where in the EP4 files a CHARSET gets specified and just change it there.

Thank you so much for the info!!!

DrByte:

If you're converting to UTF8 then there's a ton of value in actually upgrading.
It's very possible that you've got language files using non-utf8 characters in them, so will get undesired symbols.
There could also be a lot of PHP files that have old latin1 symbols in them. The upgrade replaces all those core files with "clean" ones, so avoids those issues.

The FAQ article about converting to utf8 is based on the dependency of you also running Zen Cart v1.5.x or higher. If you're trying to bolt stuff onto the old version, you'll have to do additional coding to retrofit it.

Gotcha, thanks. I'll keep this in mind, if/when they finally decide to upgrade.

Since you mentioned EP4, consider that using it could contribute to your problem as it is made for the later versions of ZC - thus it may be auto-converting to the later charset.

What about a 1.39 version of Ep? https://www.zen-cart.com/downloads.php?do=file&id=1103

Just a wag. Upgrade is best, of course.

dbltoe:

Since you mentioned EP4, consider that using it could contribute to your problem as it is made for the later versions of ZC - thus it may be auto-converting to the later charset.

What about a 1.39 version of Ep? https://www.zen-cart.com/downloads.php?do=file&id=1103

Just a wag. Upgrade is best, of course.
EP4 was actually made during the time of earlier versions of ZC, but had depended on two things. 1) the user entering data using utf8 AND 2) the system supporting mb_ style functions. In absence of the mb_ style functions, then it did not try to convert the text to utf8. This system apparently supports the mb_ style functions and therefore an attempt is made to export (and import) using utf8 on a non-utf8 system. It is expected that with a minor change to the EP4 code that non-utf8 encoding could be supported.

Just wanted to update my portion of this thread. Turns out the my zc139h db had been updated to UTF8 somewhere along the line, but none of the config/lang files had been updated. Once those files had been updated, EP4 began working as expected and the funny characters (Â) stopped generating.

As a followup to that change, I will grep thru all php files looking for any files where latin1 and/or iso-8539-1 has been hard coded.

If I find places where latin1/iso-8539-1 are coded in, can I simply update to utf8 or will that introduce problems?