Special characters issue in upgrade from 1.5.1 to 1.5.5f

**shags38** · 6 Jul 2018, 11:45 PM

continuation

TEST STORE v1.5.5f

includes/languages/westminster_new/english.php

Code:

<?php
/**
 * @package languageDefines
 * @copyright Copyright 2003-2011 Zen Cart Development Team
 * @copyright Portions Copyright 2003 osCommerce
 * @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
  * @version GIT: $Id: Author: ajeh  Modified in v1.5.4 $
 * Modified by Anne (Picaflor-Azul.com) Westminster New v1.3
 */

// FOLLOWING WERE moved to meta_tags.php
//define('TITLE', 'Zen Cart!');
//define('SITE_TAGLINE', 'The Art of E-commerce');
//define('CUSTOM_KEYWORDS', 'ecommerce, open source, shop, online shopping');
// END: moved to meta_tags.php

  define('FOOTER_TEXT_BODY', 'Copyright &copy; ' . date('Y') . ' <a href="' . zen_href_link(FILENAME_DEFAULT) . '" target="_blank">' . STORE_NAME . '</a>.  Powered by <a href="http://www.zen-cart.com" target="_blank">Zen Cart</a>.  <a href="https://www.treeoflifejewellery.com/tree-of-life-necklace-collection-c-2/" target="_blank">Tree of Life Necklace</a> <a href="https://www.cliponearrings.net.au">Clip On Earrings</a>  <a href="https://www.treeoflifejewellery.com/tree-of-life-meaning-article-ezp-2.html?chapter=1">Tree of Life Meaning</a>  <a href="https://www.harmonyball.net.au/all-harmony-ball-necklaces-c-14/" target="_blank">Harmony Ball Necklace</a> <a href="https://www.etsy.com/shop/HarmonyBalls" target="_blank">Harmony Necklace</a> <a href="https://www.etsy.com/shop/MyTreeOfLifeJewelry" target="_blank">Tree of Life Jewelry</a> <a href="https://www.etsy.com/shop/EarringsArtisan" target="_blank">Silver Earrings</a> <a href="http://www.cliponearrings.net.au" target="_blank">Clip On Earrings Australia</a>  <a href="https://www.treeoflifejewellery.com.au">Tree of Life Necklace</a>  <a href="https://www.baliartisanjewelry.etsy.com">Silver Jewelry</a>  <a href="https://www.treeoflife.net.au">Tree of Life Meaning</a> <a href="https://www.treeoflifejewellery.com/">Tree of Life Jewelry</a>  <a href="https://www.harmonyballpendant.com">Harmony Ball Necklace</a>');

// look in your $PATH_LOCALE/locale directory for available locales..
  $locales = array('en_US', 'en_US.utf8', 'en', 'English_United States.1252');
  @setlocale(LC_TIME, $locales);
  define('DATE_FORMAT_SHORT', '%m/%d/%Y');  // this is used for strftime()
  define('DATE_FORMAT_LONG', '%A %d %B, %Y'); // this is used for strftime()
  define('DATE_FORMAT', 'm/d/Y'); // this is used for date()
  define('DATE_TIME_FORMAT', DATE_FORMAT_SHORT . ' %H:%M:%S');

////
// Return date in raw format
// $date should be in format mm/dd/yyyy
// raw date is in format YYYYMMDD, or DDMMYYYY
  if (!function_exists('zen_date_raw')) {
    function zen_date_raw($date, $reverse = false) {
      if ($reverse) {
        return substr($date, 3, 2) . substr($date, 0, 2) . substr($date, 6, 4);
      } else {
        return substr($date, 6, 4) . substr($date, 0, 2) . substr($date, 3, 2);
      }
    }
  }

// if USE_DEFAULT_LANGUAGE_CURRENCY is true, use the following currency, instead of the applications default currency (used when changing language)
  define('LANGUAGE_CURRENCY', 'USD');

// Global entries for the <html> tag
  define('HTML_PARAMS','dir="ltr" lang="en"');

// charset for web pages and emails
  define('CHARSET', 'utf-8');

I noted this variance however I assume it is for specific purposes and not for rendering product description pages? $locales = array('en_US', 'en_US.utf8', 'en', 'English_United States.1252');

includes/languages/english.php

Code:

<?php
/**
 * @package languageDefines
 * @copyright Copyright 2003-2016 Zen Cart Development Team
 * @copyright Portions Copyright 2003 osCommerce
 * @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
 * @version $Id: Author: DrByte  Tue Jan 5 15:06:15 2016 -0500 Modified in v1.5.5 $
 */

// FOLLOWING WERE moved to meta_tags.php
//define('TITLE', 'Zen Cart!');
//define('SITE_TAGLINE', 'The Art of E-commerce');
//define('CUSTOM_KEYWORDS', 'ecommerce, open source, shop, online shopping');
// END: moved to meta_tags.php

  define('FOOTER_TEXT_BODY', 'Copyright &copy; ' . date('Y') . ' <a href="' . zen_href_link(FILENAME_DEFAULT) . '" target="_blank">' . STORE_NAME . '</a>. Powered by <a href="http://www.zen-cart.com" target="_blank">Zen Cart</a>');

// look in your $PATH_LOCALE/locale directory for available locales..
  $locales = array('en_US', 'en_US.utf8', 'en', 'English_United States.1252');
  @setlocale(LC_TIME, $locales);
  define('DATE_FORMAT_SHORT', '%m/%d/%Y');  // this is used for strftime()
  define('DATE_FORMAT_LONG', '%A %d %B, %Y'); // this is used for strftime()
  define('DATE_FORMAT', 'm/d/Y'); // this is used for date()
  define('DATE_TIME_FORMAT', DATE_FORMAT_SHORT . ' %H:%M:%S');

////
// Return date in raw format
// $date should be in format mm/dd/yyyy
// raw date is in format YYYYMMDD, or DDMMYYYY
  if (!function_exists('zen_date_raw')) {
    function zen_date_raw($date, $reverse = false) {
      if ($reverse) {
        return substr($date, 3, 2) . substr($date, 0, 2) . substr($date, 6, 4);
      } else {
        return substr($date, 6, 4) . substr($date, 0, 2) . substr($date, 3, 2);
      }
    }
  }

// if USE_DEFAULT_LANGUAGE_CURRENCY is true, use the following currency, instead of the applications default currency (used when changing language)
  define('LANGUAGE_CURRENCY', 'USD');

// Global entries for the <html> tag
  define('HTML_PARAMS','dir="ltr" lang="en"');

// charset for web pages and emails
  define('CHARSET', 'utf-8');

includes/configure.php

Code:

<?php
/**
 * @package Configuration Settings
 * @copyright Copyright 2003-2016 Zen Cart Development Team
 * @copyright Portions Copyright 2003 osCommerce
 * @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
 * File Built by Zen Cart Installer on Sun Jun 24 2018 06:19:43
 */

/*************** NOTE: This file is VERY similar to, but DIFFERENT from the "admin" version of configure.php. ***********/
/***************       The 2 files should be kept separate and not used to overwrite each other.              ***********/

/**
 * Enter the domain for your store
 * HTTP_SERVER is your Main webserver: eg-http://www.yourdomain.com
 * HTTPS_SERVER is your Secure/SSL webserver: eg-https://www.yourdomain.com
 */
define('HTTP_SERVER', 'https://www.sterlingsilverrings.com.au');
define('HTTPS_SERVER', 'https://www.sterlingsilverrings.com.au');

/**
 *  If you want to tell Zen Cart to use your HTTPS URL on sensitive pages like login and checkout, set this to 'true'. Otherwise 'false'. (Keep the quotes)
 */
define('ENABLE_SSL', 'true');

/**
 * These DIR_WS_xxxx values refer to the name of any subdirectory in which your store is located.
 * These values get added to the HTTP_CATALOG_SERVER and HTTPS_CATALOG_SERVER values to form the complete URLs to your storefront.
 * They should always start and end with a slash ... ie: '/' or '/foldername/'
 */
define('DIR_WS_CATALOG', '/teststore/');
define('DIR_WS_HTTPS_CATALOG', '/teststore/');

/**
 * This is the complete physical path to your store's files.  eg: /var/www/vhost/accountname/public_html/store/
 * Should have a closing / on it.
 */
define('DIR_FS_CATALOG', '/home/rings1/public_html/teststore/');

/**
 * The following settings define your database connection.
 * These must be the SAME as you're using in your admin copy of configure.php
 */
define('DB_TYPE', 'mysql'); // always 'mysql'
define('DB_PREFIX', ''); // prefix for database table names -- preferred to be left empty
define('DB_CHARSET', 'utf8'); // 'utf8' or 'latin1' are most common
define('DB_SERVER', 'localhost');  // address of your db server
define('DB_SERVER_USERNAME', '');
define('DB_SERVER_PASSWORD', '');
define('DB_DATABASE', '');

/**
 * This is an advanced setting to determine whether you want to cache SQL queries.
 * Options are 'none' (which is the default) and 'file' and 'database'.
 */
define('SQL_CACHE_METHOD', 'none');

/**
 * Reserved for future use
 */
define('SESSION_STORAGE', 'reserved for future use');

/**
 * Advanced use only:
 * The following are OPTIONAL, and should NOT be set unless you intend to change their normal use. Most sites will leave these untouched.
 * To use them, uncomment AND add a proper defined value to them.
 */
// define('DIR_FS_SQL_CACHE' ...
// define('DIR_FS_DOWNLOAD' ...
// define('DIR_FS_LOGS' ...

// End Of File

admin/includes/configure.php

Code:

<?php
/**
 * @package Configuration Settings
 * @copyright Copyright 2003-2016 Zen Cart Development Team
 * @copyright Portions Copyright 2003 osCommerce
 * @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
 * File Built by Zen Cart Installer on Sun Jun 24 2018 06:19:43
 */


/*************** NOTE: This file is VERY similar to, but DIFFERENT from the "store" version of configure.php. ***********/
/***************       The 2 files should be kept separate and not used to overwrite each other.              ***********/

/**
 * Enter the domain for your Admin URL. If you have SSL, enter the correct https address in the HTTP_SERVER setting, instead of just an http address.
 */
define('HTTP_SERVER', 'https://www.sterlingsilverrings.com.au');
/**
 * Note about HTTPS_SERVER:
 * There is no longer an HTTPS_SERVER setting for the Admin. Instead, put your SSL URL in the HTTP_SERVER setting above.
 */

/**
 * Note about DIR_WS_ADMIN
 * The DIR_WS_ADMIN value is now auto-detected.
 * In the rare case where it cannot be detected properly, you can add your own DIR_WS_ADMIN definition below.
 */

/**
 * Enter the domain for your storefront URL.
 * Enter a separate SSL URL in HTTPS_CATALOG_SERVER if your store supports SSL.
 */
define('HTTP_CATALOG_SERVER', 'https://www.sterlingsilverrings.com.au');
define('HTTPS_CATALOG_SERVER', 'https://www.sterlingsilverrings.com.au');

/**
 * Do you use SSL for your customers login/checkout on the storefront? If so, enter 'true'. Else 'false'.
 */
define('ENABLE_SSL_CATALOG', 'true');

/**
 * These DIR_WS_xxxx values refer to the name of any subdirectory in which your store is located.
 * These values get added to the HTTP_CATALOG_SERVER and HTTPS_CATALOG_SERVER values to form the complete URLs to your storefront.
 * They should always start and end with a slash ... ie: '/' or '/foldername/'
 */
define('DIR_WS_CATALOG', '/teststore/');
define('DIR_WS_HTTPS_CATALOG', '/teststore/');

/**
 * This is the complete physical path to your store's files.  eg: /var/www/vhost/accountname/public_html/store/
 * Should have a closing / on it.
 */
define('DIR_FS_CATALOG', '/home/rings1/public_html/teststore/');

/**
 * NOTE about DIR_FS_ADMIN
 * The value for DIR_FS_ADMIN is now auto-detected.
 * In the very rare case where there is a need to override the autodetection, simply add your own definition for it below.
 */

/**
 * The following settings define your database connection.
 * These must be the SAME as you're using in your non-admin copy of configure.php
 */
define('DB_TYPE', 'mysql'); // always 'mysql'
define('DB_PREFIX', 'zen1_'); // prefix for database table names -- preferred to be left empty
define('DB_CHARSET', 'utf8'); // 'utf8' or 'latin1' are most common
define('DB_SERVER', 'localhost');  // address of your db server
define('DB_SERVER_USERNAME', '');
define('DB_SERVER_PASSWORD', '');
define('DB_DATABASE', '');

/**
 * This is an advanced setting to determine whether you want to cache SQL queries.
 * Options are 'none' (which is the default) and 'file' and 'database'.
 */
define('SQL_CACHE_METHOD', 'none');

/**
 * Reserved for future use
 */
define('SESSION_STORAGE', 'reserved for future use');

/**
 * Advanced use only:
 * The following are OPTIONAL, and should NOT be set unless you intend to change their normal use. Most sites will leave these untouched.
 * To use them, uncomment AND add a proper defined value to them.
 */
// define('DIR_FS_SQL_CACHE' ...
// define('DIR_FS_DOWNLOAD' ...
// define('DIR_FS_LOGS' ...

// End Of File

admin/includes/languages/english.php

Code:

<?php
/**
 * @package admin
 * @copyright Copyright 2003-2016 Zen Cart Development Team
 * @copyright Portions Copyright 2003 osCommerce
 * @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
 * @version $Id: Author: DrByte  Wed Mar 23 14:21:26 2016 -0500 Modified in v1.5.5 $
 */
if (!defined('IS_ADMIN_FLAG'))
{
  die('Illegal Access');
}

// added defines for header alt and text
define('HEADER_ALT_TEXT', 'Admin Powered by Zen Cart :: The Art of E-Commerce');
define('HEADER_LOGO_WIDTH', '200px');
define('HEADER_LOGO_HEIGHT', '70px');
define('HEADER_LOGO_IMAGE', 'logo.gif');

// look in your $PATH_LOCALE/locale directory for available locales..
$locales = array('en_US', 'en_US.utf8', 'en', 'English_United States.1252');
@setlocale(LC_TIME, $locales);
define('DATE_FORMAT_SHORT', '%m/%d/%Y');  // this is used for strftime()
define('DATE_FORMAT_LONG', '%A %d %B, %Y'); // this is used for strftime()
define('DATE_FORMAT', 'm/d/Y'); // this is used for date()
define('PHP_DATE_TIME_FORMAT', 'm/d/Y H:i:s'); // this is used for date()
define('DATE_TIME_FORMAT', DATE_FORMAT_SHORT . ' %H:%M:%S');
define('DATE_FORMAT_SPIFFYCAL', 'MM/dd/yyyy');  //Use only 'dd', 'MM' and 'yyyy' here in any order
define('ADMIN_NAV_DATE_TIME_FORMAT', '%A %d %b %Y %X'); // this is used for strftime()
////
// Return date in raw format
// $date should be in format mm/dd/yyyy
// raw date is in format YYYYMMDD, or DDMMYYYY
function zen_date_raw($date, $reverse = false) {
  if ($reverse) {
    return substr($date, 3, 2) . substr($date, 0, 2) . substr($date, 6, 4);
  } else {
    return substr($date, 6, 4) . substr($date, 0, 2) . substr($date, 3, 2);
  }
}

// removed for meta tags
// page title
//define('TITLE', 'Zen Cart');

// include template specific meta tags defines
  if (file_exists(DIR_FS_CATALOG_LANGUAGES . $_SESSION['language'] . '/' . $template_dir . '/meta_tags.php')) {
    $template_dir_select = $template_dir . '/';
  } else {
    $template_dir_select = '';
  }
  require(DIR_FS_CATALOG_LANGUAGES . $_SESSION['language'] . '/' . $template_dir_select . 'meta_tags.php');

// meta tags
define('ICON_METATAGS_ON', 'Meta Tags Defined');
define('ICON_METATAGS_OFF', 'Meta Tags Undefined');
define('TEXT_LEGEND_META_TAGS', 'Meta Tags Defined:');
define('TEXT_INFO_META_TAGS_USAGE', '<strong>NOTE:</strong> The Site/Tagline is your defined definition for your site in the meta_tags.php file.');

// Global entries for the <html> tag
define('HTML_PARAMS','dir="ltr" lang="en"');

// charset for web pages and emails
define('CHARSET', 'utf-8');

That covers those files mentioned - if there are any others I should look at please let me know.

cheers,
Mike

**lat9** · 7 Jul 2018, 12:39 AM

Your configure.php files are down-level. What process did you use to upgrade? When using the zc_install process, those configure.php files "should have" been upgraded to the 1.5.5 format.

**shags38** · 7 Jul 2018, 06:34 AM

Originally Posted by lat9

Your configure.php files are down-level. What process did you use to upgrade? When using the zc_install process, those configure.php files "should have" been upgraded to the 1.5.5 format.

Hi Cindy - Many thanks for responding, I really appreciate it.

I have had too many failures over the years with attempting a standard upgrade so I did a new build of 1.5.5f in a test folder then imported only certain tables from the existing working site DB into that new install (primarily customer and products related tables) then imported images etc then did zc_install DB upgrade.

It is interesting you mention the php version aspect, after the rebuild when I upgraded php version on the server to 7.1 I lost the imported products description data altogether and it broke the template from the product image downwards, ie. no footer, nothing at all below the image ... and I lost the original site getting this error message 'Call to undefined function: mysql_connect(). Please install the MySQL Connector for PHP.' So server setting is back at 5.6

This was something I was going to try to investigate to find out how I can upgrade the old DB to newer version PHP before copying the tables I require without breaking the existing site. I have obviously missed a step in the process I have used, something I obviously need to correct in upgrading the other sites.

I am actually working on another under performing site at present, same rebuild process, and the import of product description pages with the special character (bullet) worked fine. I used your convert_db2utf.php plugin to convert charset on this second one as most of the tables were in latin_1. Now I am thinking I will run that convert_db2utf8.php in the site that is the subject of this thread, even though the DB already shows utf-8, and see if it joggles something - can't hurt, right?

The other reason for doing the rebuild method is that over the years from 1.3.9h to 1.5.1 to now I have used a few templates and installed and uninstalled a bunch of plugins that caused grief (numinix FEC was one major culprit) so I wanted to do a clean out - importing just the essentials, everything else will be saved for eternity on a saved copy of the existing site before switching to the 1.5.5f version (if I ever get it sorted)

Many thanks again,
cheers,
Mike

**shags38** · 7 Jul 2018, 06:49 AM

Now I am thinking I will run that convert_db2utf8.php in the site that is the subject of this thread, even though the DB already shows utf-8, and see if it joggles something - can't hurt, right?

as expected that didn't work

**davewest** · 8 Jul 2018, 05:03 PM

Originally Posted by shags38

as expected that didn't work

It did, but not what you wanted... once the code was changed, its not coming back...

Bullets are past the 128 charters that's common between UTF-8 and ASCII, after that anything can happen... You didn't say how you copied/inserted tables!! If you did it through phpmyadmin export/import your are subject to interpretation.. to understand more https://www.w3schools.com/charsets/ref_html_utf8.asp

If you have a backup of the old description data table and its correct, same as the current, but with the correct bullets, I would delete the current and sql insert of the old data! Do a Export and a SQL insert not import...

The other option is to use EZ-Populate or DBIO to pull the data into a csv, edit, then upload...

For info... I fixed mine once I converted all to correct html for bulleted lists.. You will have this problem every time you upgrade.

**swguy** · 8 Jul 2018, 06:55 PM

Looking at (for example)

https://www.sterlingsilverrings.com....246-p-272.html

I would just try using SQL to replace the â— characters.

TEST CAREFULLY ON ONE PRODUCT AT A TIME. MAKE A BACKUP.

UPDATE zen_products_description SET products_description = REPLACE(products_description, 'â—', '>►') WHERE products_id = 272;

**swguy** · 8 Jul 2018, 06:57 PM

Note that the black bolded right arrow should be encoded as

ampersand

followed by

#9658;

**shags38** · 9 Jul 2018, 07:16 AM

Originally Posted by davewest

It did, but not what you wanted... once the code was changed, its not coming back...

Bullets are past the 128 charters that's common between UTF-8 and ASCII, after that anything can happen... You didn't say how you copied/inserted tables!! If you did it through phpmyadmin export/import your are subject to interpretation.. to understand more https://www.w3schools.com/charsets/ref_html_utf8.asp

If you have a backup of the old description data table and its correct, same as the current, but with the correct bullets, I would delete the current and sql insert of the old data! Do a Export and a SQL insert not import...

The other option is to use EZ-Populate or DBIO to pull the data into a csv, edit, then upload...

For info... I fixed mine once I converted all to correct html for bulleted lists.. You will have this problem every time you upgrade.

Looking at (for example)

https://www.sterlingsilverrings.com....246-p-272.html

I would just try using SQL to replace the â— characters.

TEST CAREFULLY ON ONE PRODUCT AT A TIME. MAKE A BACKUP.

UPDATE zen_products_description SET products_description = REPLACE(products_description, 'â—', '>►') WHERE products_id = 272;

Dave and Scott - many thanks indeed for your efforts to help me sort this out - Dave I don't have an unconverted back up DB file - Scott, I tried the SQL upload you mentioned but for some reason or other it would not recognize the table, I altered your code to suit my prefix but it still had the same error .... so I manually adjusted the characters in the description in that row in the table but to no avail - I looked up current html for bullet point and it didn't work either.

As per the response to Cindy a couple of posts above, I am working on rebuilding another existing v1.5.1 (utf-8) site as a fresh v1.5.5f and the imported product_description tables also with bullet points rendered correctly. So maybe as you pointed out Dave the exporting then importing may sometimes hiccup with special characters.

I will keep my fingers crossed that for the other 4 sites I get the same result. What is of greater concern is the PHP version issue as mentioned to Cindy (above) after she pointed out the variance - not sure how I should go about sorting that out?

It is interesting you mention the php version aspect, after the rebuild when I upgraded php version on the server to 7.1 I lost the imported products description data altogether and it broke the template from the product image downwards, ie. no footer, nothing at all below the image ... and I lost the original site getting this error message 'Call to undefined function: mysql_connect(). Please install the MySQL Connector for PHP.' So server setting is back at 5.6

I do not want to confuse the thread so should I make another thread on the PHP subject? - I value your opinions on this.

Thanks to everyone for all your help with the special characters issue - before I bring over the products_description table when doing the other sites I will save the DB as is but then convert to utf-8 and save that as a different version so at least I have both just in case.

cheers,
Mike

**mc12345678** · 9 Jul 2018, 03:33 PM

Originally Posted by shags38

Scott, I tried the SQL upload you mentioned but for some reason or other it would not recognize the table, I altered your code to suit my prefix but it still had the same error .... so I manually adjusted the characters in the description in that row in the table but to no avail - I looked up current html for bullet point and it didn't work either.

In each of the bolded case issues identified above, there is no specific information provided to assist resolving the issue. What is the error message? When accessing (assumably) phpmyadmin, where did you navigate to from there? Or did you run the sql command from the admin->install sql patches? Also note that when "manually" updating the field, phpmyadmin (again an assumption) also provides the sql statement that was executed. That could be used/reused to do the next one and while it may not be formatted with the replace command, at least whatever "table" issue was present could be resolved.

As far as posting the specific html as swguy tried to identify, if you encapsulate the content in [noparse][/noparse] tags, then it will remain as typed and not as displayed by a browser.

So for example instead of:

Originally Posted by swguy

Looking at (for example)

https://www.sterlingsilverrings.com....246-p-272.html

I would just try using SQL to replace the â— characters.

TEST CAREFULLY ON ONE PRODUCT AT A TIME. MAKE A BACKUP.

UPDATE zen_products_description SET products_description = REPLACE(products_description, 'â—', '>►') WHERE products_id = 272;

Would post:

Originally Posted by swguy

Looking at (for example)

https://www.sterlingsilverrings.com....246-p-272.html

I would just try using SQL to replace the â— characters.

TEST CAREFULLY ON ONE PRODUCT AT A TIME. MAKE A BACKUP.

UPDATE zen_products_description SET products_description = REPLACE(products_description, 'â & # 8 2 1 2 ;', '> & # 9 6 5 8 ;') WHERE products_id = 272;

Or in trying to use code tags:

Originally Posted by swguy

Looking at (for example)

https://www.sterlingsilverrings.com....246-p-272.html

I would just try using SQL to replace the â— characters.

TEST CAREFULLY ON ONE PRODUCT AT A TIME. MAKE A BACKUP.

Code:

UPDATE zen_products_description SET products_description = REPLACE(products_description, 'â & # 8 2 1 2 ;', '> & # 9 6 5 8 ;') WHERE products_id = 272;

Which may/may not work well, but I thought I would try. And actually none of what I tried regarding noparse worked in this situation, so in the time I had available to edit it, I placed spaces between each character...

Originally Posted by shags38

As per the response to Cindy a couple of posts above, I am working on rebuilding another existing v1.5.1 (utf-8) site as a fresh v1.5.5f and the imported product_description tables also with bullet points rendered correctly. So maybe as you pointed out Dave the exporting then importing may sometimes hiccup with special characters.

Note that as far as the ZenCart code is concerned with this particular site, the applicable configure.php files were not in the format expected for a ZC 1.5.1 site. This can be seen by the absence of the DB_CHARSET define in both files and that the top of the two files indicate that they are/were from ZC 1.3.9. This is an indication that the upgrade to that site from 1.3.9 to 1.5.1 was not done correctly. Further it means that the encoding for that aspect was dependent on some other factor whether php.ini or some internal coding to ZC 1.5.1. Such issue is likely the cause of the current problem with this one site.

Originally Posted by shags38

I will keep my fingers crossed that for the other 4 sites I get the same result. What is of greater concern is the PHP version issue as mentioned to Cindy (above) after she pointed out the variance - not sure how I should go about sorting that out?

I do not want to confuse the thread so should I make another thread on the PHP subject? - I value your opinions on this.

Well, the subject has been broached as part of working out this issue, and really the php issue is nothing new. Why do I say that? First of all ZC 1.5.1 was written back in the day where PHP 5.3.x was the highest available version. See the server requirements found on the main page of this forum site: http://www.zen-cart.com/content.php?...o-run-zen-cart
Further for ZC 1.5.1 to work at higher levels, specific changes were necessary (these were ultimately incorporated into ZC 1.5.3 and above), so it is no surprise that when attempting php 7.x that the existing online store had issues. Afterall, that's one of the reasons to be doing the update to ZC 1.5.5x so that the software can operate in current expected conditions another is to have increased security, increased speed, and in some areas improved ways to incorporate other plugins without code modification. The description of the issue though is not very clear, but if the newly built site was having issues with php 7.x, then either the upgrade/rebuild of the site wasn't done correctly, see: http://www.zen-cart.com/entry.php?3-...d-of-upgrading
Or one or more plugins (another posting tip item not answered/provided) installed to restore some feature from the old site hasn't been upgraded to handle php 7.x. That said, error logs are your friend. Based on the described result of a partial blank screen, see: http://www.zen-cart.com/content.php?124-blank-page

Originally Posted by shags38

Thanks to everyone for all your help with the special characters issue - before I bring over the products_description table when doing the other sites I will save the DB as is but then convert to utf-8 and save that as a different version so at least I have both just in case.

cheers,
Mike

This is a good plan to have a copy of both AND to keep track of what is done so that it can be quickly replicated if necessary when finishing off the upgrade.

**shags38** · 10 Jul 2018, 06:04 AM

Originally Posted by mc12345678

In each of the bolded case issues identified above, there is no specific information provided to assist resolving the issue. What is the error message? When accessing (assumably) phpmyadmin, where did you navigate to from there? Or did you run the sql command from the admin->install sql patches? Also note that when "manually" updating the field, phpmyadmin (again an assumption) also provides the sql statement that was executed. That could be used/reused to do the next one and while it may not be formatted with the replace command, at least whatever "table" issue was present could be resolved.

I used admin/install sql patches - the error message was [HTML] ERROR: Cannot execute because table zen1_products_description does not exist. CHECK PREFIXES![HTML] In phpMyAdmin I navigated to the table zen1_products_description >> and then to the specific product row and clicked edit, then changed the html code for the bullet - I know now that it doesn't appear to change html. My knowledge of datbases is very limited so I did not know how to execute an sql instruction from within phpMyAdmin.

As far as posting the specific html as swguy tried to identify, if you encapsulate the content in [noparse][/noparse] tags, then it will remain as typed and not as displayed by a browser.

So for example instead of:

Would post:

Or in trying to use code tags:

Which may/may not work well, but I thought I would try. And actually none of what I tried regarding noparse worked in this situation, so in the time I had available to edit it, I placed spaces between each character...

thanks for the info, I'm not familiar with the parsing aspect so it was useful info - I tried both versions, with and without spaces and neither was successful - without spaces returned the same error as mentioned above, with spaces resulted in a white page with an error has occurred refresh page.

Note that as far as the ZenCart code is concerned with this particular site, the applicable configure.php files were not in the format expected for a ZC 1.5.1 site. This can be seen by the absence of the DB_CHARSET define in both files and that the top of the two files indicate that they are/were from ZC 1.3.9. This is an indication that the upgrade to that site from 1.3.9 to 1.5.1 was not done correctly. Further it means that the encoding for that aspect was dependent on some other factor whether php.ini or some internal coding to ZC 1.5.1. Such issue is likely the cause of the current problem with this one site.

hence the reasons I suggested to Cindy for me doing a fresh rebuild primarily because of past bad experiences with upgrades - to be frank I'm still a little confused with the process even after reading every FAQ and tutorial on the subject - this is how I am going about it, if there are glaring problems I would appreciate some advice;
1. in a new directory (teststore) in the public_html root I install a fresh latest version of ZC, in this case 1.5.5f
2. after installation I install a new template
3. I copy product images from existing site into teststore
4. I copy certain tables from existing live site DB into the DB of the new teststore - these tables are all those related address book, customers, orders & products
5. I install the latest versions of plugins I wish to use - testing and saving a copy of DB as I go after each install
6. I make changes to layout settings, side boxes layout and files like meta tags etc so that the site is performing like the live site but a different template
7. I install paypal express and do a test transaction (slight problem with OPC at present that Cindy is helping me with)
this is the point after proving all functions where I have gone off course in the past as you have seen and referred to above - lack of understanding of the way the ZC system works I think with configure files and database versions.
So now it is my intention, once I prove the transaction process is OK, to delete all folders of the existing site root and then upload the folders from the test store into the root so that no aspect of the old site remains and only the new site exists - it may be unconventional but my logic is that I cannot make any errors in doing that with full backup copies of both new and old on file (famous last words) ...

Well, the subject has been broached as part of working out this issue, and really the php issue is nothing new. Why do I say that? First of all ZC 1.5.1 was written back in the day where PHP 5.3.x was the highest available version. See the server requirements found on the main page of this forum site: http://www.zen-cart.com/content.php?...o-run-zen-cart
Further for ZC 1.5.1 to work at higher levels, specific changes were necessary (these were ultimately incorporated into ZC 1.5.3 and above), so it is no surprise that when attempting php 7.x that the existing online store had issues. Afterall, that's one of the reasons to be doing the update to ZC 1.5.5x so that the software can operate in current expected conditions another is to have increased security, increased speed, and in some areas improved ways to incorporate other plugins without code modification.
The description of the issue though is not very clear, but if the newly built site was having issues with php 7.x, then either the upgrade/rebuild of the site wasn't done correctly, see: http://www.zen-cart.com/entry.php?3-...d-of-upgrading
Or one or more plugins (another posting tip item not answered/provided) installed to restore some feature from the old site hasn't been upgraded to handle php 7.x. That said, error logs are your friend. Based on the described result of a partial blank screen, see: http://www.zen-cart.com/content.php?124-blank-page

The issue with the new 1.5.5f testsite when changing php to 7.1 was with the product info pages (everything else was fine) - aside from the product title and the main product image everything else on the page was blank (no pricing, add to cart, product description etc and no flexible footer. So my assumption is that the imported product_description tables are incompatible (5.6 vs 7.1) albeit everything else appeared OK. So aside from product description text I assume those tables have template elements to them?
So referring to the above method of upgrading it has this major flaw and I'm not sure how to solve it? How would a standard upgrade procedure overcome the situation I have with a php upgrade?

cheers,
Mike

Thread: Special characters issue in upgrade from 1.5.1 to 1.5.5f

Thread Tools

Search Thread

Display

Re: Special characters issue in upgrade from 1.5.1 to 1.5.5f

Re: Special characters issue in upgrade from 1.5.1 to 1.5.5f

Re: Special characters issue in upgrade from 1.5.1 to 1.5.5f

Re: Special characters issue in upgrade from 1.5.1 to 1.5.5f

Re: Special characters issue in upgrade from 1.5.1 to 1.5.5f

Re: Special characters issue in upgrade from 1.5.1 to 1.5.5f

Re: Special characters issue in upgrade from 1.5.1 to 1.5.5f

Re: Special characters issue in upgrade from 1.5.1 to 1.5.5f

Re: Special characters issue in upgrade from 1.5.1 to 1.5.5f

Re: Special characters issue in upgrade from 1.5.1 to 1.5.5f

Similar Threads

v155 Japanese characters showing wrong after upgrade from 1.3.9

Special Characters in DB

UTF8 and special characters after upgrade

Upgrade from 1.3.9f to 1.3.9h issue

Remove group discounts from special offers issue

Bookmarks

Bookmarks

Posting Permissions