EasyPopulate 4.0 Support Thread

[mc12345678]

Importing attributes is the topic. A client has two identical sites, one wholesale and one retail.

Trying to simplify product additions for them so they:

1. add a new item to the wholesale site
2. Do a 'Complete Product' export
3. Do a 'Basic Products Attributes' export
4. Import the 'Complete Product' csv on the retail site (good so far)
5. Import the 'Basic Products Attributes' on the retail site - problem.

The new product does not have attributes. The Import Results at the bottom of the page on the retail site show:

UPDATED! - Model: JimJim | 23997 | Todler Siz | 3-T,4-T |

The problem is that the attribute name is Todler Size: This is the csv content:

v_products_model,v_products_options_type,v_products_options_name_1,v_products_op tions_values_name_1
JimJim,23997,Todler Size:,"3-T,4-T"

Just for fun, I also tried:

"v_products_model","v_products_options_type","v_products_options_name_1","v_prod ucts_options_values_name_1"
"JimJim",23997,"Todler Size:","3-T,4-T"

Issue is the v_products_options_type value (23997), this normally would be a value between 0 and 5 for a blank/fresh store... So would need to know what "type" of option is being used on each store and adjust accordingly... The products_option_type number is the option value as found from the admin screen when using the option name manager that corresponds with the particular option type, ie. dropdown is typically 0, Text is 1, Radio 2, Checkbox 3, File 4, Read Only 5... Depending on how other plugins add the values and sequence of adding the plugin(s)/values, the option value could be almost any number.

[jeking]

Issue is the v_products_options_type value (23997), this normally would be a value between 0 and 5 for a blank/fresh store... So would need to know what "type" of option is being used on each store and adjust accordingly... The products_option_type number is the option value as found from the admin screen when using the option name manager that corresponds with the particular option type, ie. dropdown is typically 0, Text is 1, Radio 2, Checkbox 3, File 4, Read Only 5... Depending on how other plugins add the values and sequence of adding the plugin(s)/values, the option value could be almost any number.

In looking at that page, the id looks to be correct:

<option value="0" selected="selected">Dropdown</option>
<option value="1">Text</option>
<option value="2">Radio</option>
<option value="3">Checkbox</option>
<option value="4">File</option>
<option value="5">Read Only</option>
<option value="23997">Grid</option>

This list is the same on both sites.

[mc12345678]

In looking at that page, the id looks to be correct:

<option value="0" selected="selected">Dropdown</option>
<option value="1">Text</option>
<option value="2">Radio</option>
<option value="3">Checkbox</option>
<option value="4">File</option>
<option value="5">Read Only</option>
<option value="23997">Grid</option>

This list is the same on both sites.

What is/was the method of verifying no attributes applied to product?

[jeking]

What is/was the method of verifying no attributes applied to product?

The A icon is black, not teal. Going to Attributes Controller also confirms no attributes exist.

[mc12345678]

The A icon is black, not teal. Going to Attributes Controller also confirms no attributes exist.

@jeking,
‎
Having difficulty reproducing the issue identified.
Here is the testing that I performed:
1. Created a new product (used ZC admin to do this for testing expediency.) gave the product the following unique Model#: ##add_attributes_EP4
2. Exported a basic attributes file.
3. Deleted all but one entry within a text editor, changed the model# of the one entry to the above Model#.
4. Imported the file.
5. Uploaded the file and had the following results:

NEW ATTRIBUTE! - Model: add_attributes_EP4, Option: Size,Values: S,M,L,XL,XXL,XXXL

Updated records: 0
New Imported records: 1
Errors Detected: 1
Warnings Detected: 0
Memory Usage: 745496
Memory Peak: 1930920
Execution Time: 0 seconds.
‎
6. Then tried using a model # that didn't exist in the database with all of the same information:

SKIPPED! - Model: add_attributes_EP4_2 - Not Found! Unable to apply attributes.

7. Then tried using the original file from above (no modification to the existing attributes before import) but changed the##v_products_options_type field to a value that didn't exist:

UPDATED ATTRIBUTE! - Model: add_attributes_EP4 Option: Size, Values: S,M,L,XL,XXL,XXXL‎
‎
8. Then added a new option value to the same entry that had a non-existent option name type:

NEW ATTRIBUTE! - Model: add_attributes_EP4, Option: Size,Values: S,M,L,XL,XXL,XXXL,XXXXL

So, I'm a smidge at a loss about what's going on. Can't be an admin/catalog database discrepancy, because EP4 uses the same database as the admin. There is a report that some of the error catching/data reporting does need some work, but the above report(s) of checking the data indicates that the assignment of attributes did not occur. Might want to look at the database directly as well, but not sure what action(s) would need to be attempted to identify the update (which sounds like the product already had attributes assigned) as being performed but it not making any change.

[jeking]

Here's the thing that stick out to me. When importing, the message is:

UPDATED! - Model: JimJim | 23997 | Todler Siz | 2T,3T,4T,4 |

The attribute name is 'Todler Size:' not 'Todler Siz'

I checked the attribute name in the db, hoping to find some odd character or spacing, but no.

I tried exporting from the retail site, adding an attribute value and importing back into the retail site. I get the same issue above of the message saying UPDATED but the attribute name being wrong.

I'm using Open Office and even opened the csv file in a text editor to confirm the file formatting is correct.

It seems as if it's reading the csv file incorrectly, but that doesn't make sense. Any way to test or troubleshoot the import process? Meaning is there a way to determine where the attribute name is getting mis-read?

[mc12345678]

How wrong are the attribute names? Always only so wide (x characters?) is there an indication in the upper right corner about mb_string or some similar function not be supported.

The basic attribute import is performed in admin/easypopulate_4_attrib.php. Now in review of that file, I see that I didn't update the queries like I did everywhere else, but I also just tried an import with Todler size: as the option name and had no truncation...##
‎
Some reasons that truncation can occur (come to mind anyways) are, 1) unescaped characters that get processed as some other character, but if such a character "combination" were a sql problem, then it should be reported as an error. 2) the option name field is shorter than the text length‎ though even so, the data should appear in the database even if truncated. 3) in part wondering if the truncation is merely visual with the full document(s) available but for some other reason not actually lmported.

One thing not discussed, but I suspect is correct, the filename when this issue has been occurring. Up to and including the letters ep, is it in anyway different than what was downloaded? The end of the filename can be whaterver is allowable by the storage system, but the beginning (capitalization not included) needs to match that of the filter to be applied.