After V155e upgrade Product Description is not populated in Admin Editor.

[idtags]

I am happy to report, that after implementing changes below, Description of products is shown in Admin Editor.
----------------------------------------------------------------------
define('DB_CHARSET', 'utf8'); // 'utf8' or 'latin1' are most common <- /includes/configure.php
----------------------------------------------------------------------
define('DB_CHARSET', 'utf8'); // 'utf8' or 'latin1' are most common <- /YOUR_ADMIN/includes/configure.php
----------------------------------------------------------------------
// charset for web pages and emails <- /includes/languages/YOUR_TEMPLATE/english.php
//define('CHARSET', 'UTF-8');
define('CHARSET', 'UTF-8');
----------------------------------------------------------------------
// charset for web pages and emails <- /YOUR_ADMIN/includes/languages/english.php
define('CHARSET', 'UTF-8');[/QUOTE]
----------------------------------------------------------------------

Attachment 17571

At this point we are working on making CKeditor functional, so Plain Text is shown.

Question is, with this progress should we still run Convert db2utf8 or it is not necessary ?

[lat9]

Woo-hoo! I'm glad that your product descriptions are back.

If you still have the pre-upgrade versions of those configure.php files, would you send them and the upgraded version to me via PM? The upgrade process should never result in the DB_CHARSET value being ''.

Regarding the need for Convert db2utf8, my suggestion is to go for it. Right now, your database is most likely configured to use an ASCII character-set, but you've told Zen Cart that it's utf8-based. That discrepancy can result in some funky characters being stored in your database, especially if your customers have non-ASCII characters (e.g. ñ) in their names. See this blog post I wrote on the subject for additional information.

[mc12345678]

I don't know what issue mc12345678 is referring to with regard to that plugin not working when a DB_PREFIX value is set.

After viewing the initial results and then when I have tried the conversion using the downloaded version I had on more than one occasion received an error that the database couldn't be converted. As my memory served (right or wrong) the issue was somehow related to the DB_PREFIX and/or database name.

Accessing convert_db2utf8 to simply see the various collations in the database did not report any issues with the sql statements, but attempting the update did report an error that was resolved by the below use of backticks at least in the first of the two code changes (lines 120 and 135). The second change was made simply for consistency after some deliberation and was not essential for operation.

Changed (line 120):

      db_query ("ALTER DATABASE " . $dbDatabase . " CHARACTER SET utf8 COLLATE $desiredCollation");

to:

      db_query ("ALTER DATABASE `" . $dbDatabase . "` CHARACTER SET utf8 COLLATE $desiredCollation");

and (line 135):

  $query_tables = db_query("SHOW TABLE STATUS FROM " . $dbDatabase);

to:

  $query_tables = db_query("SHOW TABLE STATUS FROM `" . $dbDatabase . "`");

In the situations where it hasn't work as provided, review of the database name and the included DB_PREFIX did not identify the need for quotes (backticks) and appeared to be sufficient to support unquoted identifier use as discussed in the mysql "manual".

As part of the review of the conversion software, these two lines were the only two that did not use backticks around the database identifiers, that the first modification was the only one of the two that executed solely when doing the update (point at which problem occurred), and that the code within the first change was new code for version 4. So, considering those factors, the first attempt to fix the issue was to modify both lines to the above. The modifications worked and the modified file has become the version of this plugin that I consistently and successfully use.

The whole thing seemed odd though because if there was an issue using the identifiers unquoted, it seemed like a similar issue would be expected in other ZC operations. Upon further looking, though, it appears that a database name (that otherwise would need to be quoted) is handled without additional quoting through selection of appropriate php command(s).