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.

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:

<?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:

<?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).

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.

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...

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.

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/2012/06/06/all-about-unicode-utf8-character-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.