Fresh install of v1.5.0, database CHARSET anomoly ...

Performed a fresh install of v1.5.0 on my XAMPP setup of my Windows 7 computer using a newly created a database using latin1_general_ci as my collation. On the database screen of the install, I indicated that I would be using Latin1 as my character set.

Upon completion of the installation, my /includes/languages/english.php indicates that I'm using utf-8 as my charset and my database tables are all using utf8_general_ci as their collation.

What else did I need to do to get a Latin1 instead of UTF-8 configuration?

I believe that with v1.50 - - utf-8 is the default

Zen Cart doesn't edit your language files for you. If you want to specifically use iso-8859-1, you'll need to set that in your language files by hand.

Quote:

---

Originally Posted by DrByte

Zen Cart doesn't edit your language files for you. If you want to specifically use iso-8859-1, you'll need to set that in your language files by hand.

---

OK, but how do you explain that all the tables in my database (for which I specified a latin1_general_ci collation when it was created) are using utf8_general_ci even though I specified the "Latin1" charset via the dropdown box during the installation?

This was bugging the heck out of me and I finally tracked it down. No matter what you do, if you perform a fresh install of v1.5.0 into an empty database created using latin1_general_ci collation and select "Latin1" as the database collation type the resulting database uses only utf8_general_ci collation.

The problem is in the file /zc_install/includes/installer_params.php:

Code:

---

<?php
/**
 * @package Installer
 * @access private
 * @copyright Copyright 2003-2011 Zen Cart Development Team
 * @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
 * @version $Id: installer_params.php 18819 2011-05-31 20:25:53Z drbyte $
 */

/**
 * Runtime Parameters used by browser interface
 */
//  $session_save_path = (@ini_get('session.save_path') && is_writable(ini_get('session.save_path')) ) ? ini_get('session.save_path') : realpath('../cache');
  $session_save_path = (is_writable(realpath('../cache')) ) ? realpath('../cache') : ini_get('session.save_path');
  define('SESSION_WRITE_DIRECTORY', $session_save_path);
  define('DEBUG_LOG_FOLDER', realpath('../cache'));

  // Set the following to TRUE if having problems (blank pages, etc). Best to leave at FALSE for normal use.
  define('STRICT_ERROR_REPORTING', FALSE);


  // optionally set this to 'latin1':
  define('DB_CHARSET', 'utf8');

  // optionally uncomment the following line if choosing 'utf8' or 'latin1' above are causing problems:
  // define('IGNORE_DB_CHARSET', TRUE);

---

The DB_CHARSET define is used by the CREATE_TABLE clause of the select statement of the executeSQL function within /zc_install/includes/functions/general.php and is set (if not already defined) by the dbActivate function within /zc_install/includes/classes/installer.php to reflect the value specified by the drop-down box within the Database Configuration step of the install.

The problem is that DB_CHARSET is already defined during the inclusion of the installer_parms.php file ... the net result being that a fresh install of v1.5.0 ALWAYS uses a utf8_general_ci collation regardless of the value chosen by the user during the install.

The fix is to simply comment out the define statement in the installer_parms.php file:

Code:

---

<?php
/**
 * @package Installer
 * @access private
 * @copyright Copyright 2003-2011 Zen Cart Development Team
 * @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
 * @version $Id: installer_params.php 18819 2011-05-31 20:25:53Z drbyte $
 */

/**
 * Runtime Parameters used by browser interface
 */
//  $session_save_path = (@ini_get('session.save_path') && is_writable(ini_get('session.save_path')) ) ? ini_get('session.save_path') : realpath('../cache');
  $session_save_path = (is_writable(realpath('../cache')) ) ? realpath('../cache') : ini_get('session.save_path');
  define('SESSION_WRITE_DIRECTORY', $session_save_path);
  define('DEBUG_LOG_FOLDER', realpath('../cache'));

  // Set the following to TRUE if having problems (blank pages, etc). Best to leave at FALSE for normal use.
  define('STRICT_ERROR_REPORTING', FALSE);


  // optionally set this to 'latin1':
//  define('DB_CHARSET', 'utf8');

  // optionally uncomment the following line if choosing 'utf8' or 'latin1' above are causing problems:
  // define('IGNORE_DB_CHARSET', TRUE);

---

just for interest, why did you prefer latin-1 over utf-8 for a new install?

I've got (mostly) English-only websites and I use a US-English keyboard. Why should I "take the plunge" into utf-8? It seems like most of the "funky character display" and admin white-page due to html-special-character problems that I've seen posted within this forum are based on utf8 anomalies rather than latin1.

In other words, I've not seen a compelling reason to go the utf-8 route. If you have one, let me know as I appreciate and listen to contrary opinions.

My reason for this post is that the Latin1 side of the install just plain doesn't work ... the english.php files are hard-coded utf8 and the the database install forces utf8_general_ci collation (even though you've chosen Latin1).

Quote:

---

Originally Posted by lat9

It seems like most of the "funky character display" and admin white-page due to html-special-character problems that I've seen posted within this forum are based on utf8 anomalies rather than latin1.

---

Clarification: Those problems are a result of a MISMATCH of character-set settings.

Quote:

---

Originally Posted by DrByte

Clarification: Those problems are a result of a MISMATCH of character-set settings.

---

Some of which have unfortunately been the result of a standard installation, if anyone chose (as I did) the Latin1 selection for database collation. The result in that case is that the database winds up being utf8_general_ci, the configuration.php files specify latin1 and the english.php files specify utf-8.

For an English-only storefront, what's the business-related decision to go the utf8 route rather than latin1?

Getting very off-topic here...

Quote:

---

problems.....are based on utf8 anomalies rather than latin1.

---

Yes. But as I usually stick my nose into those threads (as I had problems in the early days that took me a lot of time to understand) I think I am fairly safe in saying they are ALL due to people going 8859 to utf8 and not doing it 100%/not understanding the chain of data-passing events.

I don't think there is a problem with a new 1.5 install in utf-8.

I assume the decision to go utf-8 as the default install was taken to reduce these conversions/problems surfacing at a later date when people start selling outside their initial territory.

Nonetheless if the latin.1 option is offered at install it should work, which you have proved it doesn't.

Quote:

---

For an English-only storefront, what's the business-related decision to go the utf8 route rather than latin1?

---

None on the face of it, but maybe there will be problems with customers names and addresses using accents.

The whole charset issue is a real Pandoras Box, the best explanation I've seen is this one:
http://coding.smashingmagazine.com/2...haracter-sets/

but in the lack of any real "standard" at all, I think utf-8 is as close as it gets and should be the default setting for any software that sets itself up to be used internationally.

Thanks for the explanation, torvista, I appreciate the input and will start looking at what it takes to convert my sites to utf-8 as I am selling internationally.