CRE Loaded Attribute Import Field Encapsulation Bug (With Fix)

[David M. Graham]

No.  In this case trim is stripping the double quote character. 

[inetbiz]

ok I see what you did, there. Using trim() for hacking out white space before and after the string. Am I correct in that assumption?

Code: [Select]

$ret = trim($ret,'"');

[David M. Graham]

I've recently begun working a bit with the CRE Loaded Easy Populate Attribute export and import tools.   They're rather different than previous EP attribute management tools, developed largely because Chain Reaction Web's custom work in Option Type Features did not include modifications to work with Easy Populate.

There are three export file types, paralleling the table relationship chain that relates a value to an option, one or more options to an attribute, and the attribute to one (or more) products.

My objective was to rapidly correct the labels attached to attributes used on about 1250+ products.  I began with exporting a  complete product file, and one each of the EP Attribute, Options and Value files.  The database was backed up, and the options files modified using Microsoft Excel in the usual fashion. (Yes, OO Calc is open source, but the client involved uses Office - keep the variables to a minimum, eh?)

The exports went fine, the modifications were saved and re-imported to the development store.

Unfortunately, the longest option label involved came out a bit mangled.  It now began with a double quote (") and was truncated by one letter.   A brief examination of the database revealed the culprit.  Sloppy field encapsulation by Excel (a long standing pain in the posterior), combined with rather immature encapsulation management in CRE Loaded's recently implemented (6.2.4 or so) extended file formats.

After tracking my way through the sloppiness of utility functions scattered throughout the code rather than being tucked away in includes/functions/ep_functions.php where they should have been placed, I located the culprit, and applied a quick fix.

The function responsible is found in ep_import_options.php and is named get_next_str().  The distribution form of this function looks like this:

Code: [Select]

function get_next_str(&$str, $split) {
  $pos = strpos($str, $split);
  if ($pos != false) {
    $ret = substr($str, 0, $pos);
    $str = substr($str, $pos + 1);
  } else {
    if (substr($str, 0, 1) != $split) {
      $ret = $str;
    } else {
      $ret = '';
      $str = substr($str, $pos + 1);
    }   
  }
  return $ret;
}

the corrected version looks like:

Code: [Select]


function get_next_str(&$str, $split) {
  $pos = strpos($str, $split);
  if ($pos != false) {
    $ret = substr($str, 0, $pos);
    $ret = trim($ret,'"');
    $str = substr($str, $pos + 1);
  } else {
    if (substr($str, 0, 1) != $split) {
      $ret = $str;
      $ret = trim($ret,'"');
    } else {
      $ret = '';
      $str = substr($str, $pos + 1);
    }   
  }
  return $ret;
}


What this does is strip the double quote character from the beginning and end of any string which is encapsulated.  I should note that this particular bug was only found because the store owner used commas to separate words in her label.  This triggered the Excel field encapsulation which revealed the issue.  This type of thing is a great reason to include new features such as this in free releases, which often enjoy wider distribution than costly commercial variants.....

David