EasyPopulate 4.0 Support Thread

[wmorris]

I do have a question, I see a column says "Delete" if I click delete will that remove the everything from the Database or just remove that file from the list? Need to clean out the list.

[mc12345678]

I do have a question, I see a column says "Delete" if I click delete will that remove the everything from the Database or just remove that file from the list? Need to clean out the list.

When looking at the tools->Easy Populate V4 admin screen, in the "lower" area showing a list of files, the delete button there relates to just the file itself and nothing about the contents. Be advised that at this time, there is no "are you sure" question when selecting that button. The file is simply deleted.

Also, because the list is generated from what is present, if you have some reason to keep the files, then taking them out of the EP4 directory will shorten the list, but will still require storage and some future review for removal. :)

[bramf]

I am on zencart 155e and use Easy Populate 4.0.36.ZC - 07-05-2016.
My default language english has language_id 4 (and I have dutch language_id 2 and german with language_id 5.

When I import something like this, everytime a new option name is created and it is NOT assigned to the product:
v_products_model,v_products_options_type,v_products_options_name_2,v_products_op tions_name_4,v_products_options_name_5,v_products_options_values_name_2,v_produc ts_options_values_name_4,v_products_options_values_name_5
"WOOall83130x18002","5","Kleur","Color","Farbe","Groen","Green","Grün"

help would be appreciated.

[mc12345678]

I am on zencart 155e and use Easy Populate 4.0.36.ZC - 07-05-2016.
My default language english has language_id 4 (and I have dutch language_id 2 and german with language_id 5.

When I import something like this, everytime a new option name is created and it is NOT assigned to the product:
v_products_model,v_products_options_type,v_products_options_name_2,v_products_op tions_name_4,v_products_options_name_5,v_products_options_values_name_2,v_produc ts_options_values_name_4,v_products_options_values_name_5
"WOOall83130x18002","5","Kleur","Color","Farbe","Groen","Green","Grün"

help would be appreciated.

I was recently reworking the import of attributes and noticed that something like this was possible to occur. Original design appeared to consider that all installs would have at least a language_id of 1. Where 1 was the default language. The file admin/easypopulate_4_attrib.php is the one that has the "issue". Now that the problem has been clearly identified as likely to occur, I have the following suggestion, though in the upcoming release it will likely be different because there is
some code consolidation being done to reduce duplication and give the code a little more logical structure.

In admin/easypopulate_4_attrib.php make the following modifications (to suit your store) which are captured in the github commit: https://github.com/mc12345678/EasyPo...d73083136f623a or by replacing the file with the one provided at: https://github.com/mc12345678/EasyPo...e_4_attrib.php


In line 11:
From:

$language_id          = 1; // default 1=english

To:

$language_id          = $epdlanguage_id; // default 1=english or the language_id for your default language

Line 69:
From:

     $l_id = 1; // temporary check - should this be the default language id?

To:

     $l_id = $language_id; // temporary check - should this be the default language id?

Line 107:
From:

     $number_of_elements = count($values_names_array[1]); // all elements count must be the same

To:

     $number_of_elements = count($values_names_array[$language_id]); // all elements count must be the same

Line 141:
From:

         $l_id = 1; // first defined language is main key - mandatory

To:

         $l_id = $language_id; // first defined language is main key - mandatory

Line 208:
From:

          $l_id = 1; // default first language is main key

To:

          $l_id = $language_id; // default first language is main key

Line 241:
From:

         $l_id = 1; // default first language is main key

To:

         $l_id = $language_id; // default first language is main key

Line 316:
From:

                    $v_products_model, $v_products_options_name[1], implode(",", $values_names_array[1]));

To:

                    $v_products_model, $v_products_options_name[$language_id], implode(",", $values_names_array[$language_id]));

And Line 321:
From:

                   $v_products_model, $v_products_options_name[1], implode(",", $values_names_array[1]));

To:

                   $v_products_model, $v_products_options_name[$language_id], implode(",", $values_names_array[$language_id]));

[mc12345678]

I was recently reworking the import of attributes and noticed that something like this was possible to occur. Original design appeared to consider that all installs would have at least a language_id of 1. Where 1 was the default language. The file admin/easypopulate_4_attrib.php is the one that has the "issue". Now that the problem has been clearly identified as likely to occur, I have the following suggestion, though in the upcoming release it will likely be different because there is
some code consolidation being done to reduce duplication and give the code a little more logical structure.

In admin/easypopulate_4_attrib.php make the following modifications (to suit your store) which are captured in the github commit: https://github.com/mc12345678/EasyPo...d73083136f623a or by replacing the file with the one provided at: https://github.com/mc12345678/EasyPo...e_4_attrib.php


In line 11:
From:

$language_id          = 1; // default 1=english

To:

$language_id          = $epdlanguage_id; // default 1=english or the language_id for your default language

Line 69:
From:

     $l_id = 1; // temporary check - should this be the default language id?

To:

     $l_id = $language_id; // temporary check - should this be the default language id?

Line 107:
From:

     $number_of_elements = count($values_names_array[1]); // all elements count must be the same

To:

     $number_of_elements = count($values_names_array[$language_id]); // all elements count must be the same

Line 141:
From:

         $l_id = 1; // first defined language is main key - mandatory

To:

         $l_id = $language_id; // first defined language is main key - mandatory

Line 208:
From:

          $l_id = 1; // default first language is main key

To:

          $l_id = $language_id; // default first language is main key

Line 241:
From:

         $l_id = 1; // default first language is main key

To:

         $l_id = $language_id; // default first language is main key

Line 316:
From:

                    $v_products_model, $v_products_options_name[1], implode(",", $values_names_array[1]));

To:

                    $v_products_model, $v_products_options_name[$language_id], implode(",", $values_names_array[$language_id]));

And Line 321:
From:

                   $v_products_model, $v_products_options_name[1], implode(",", $values_names_array[1]));

To:

                   $v_products_model, $v_products_options_name[$language_id], implode(",", $values_names_array[$language_id]));

As reported in issue #34 of the main repo for this plugin, the above fixes the identified issue. The concept from the above will be incorporated into the main thread for the next release.

[jeking]

I've got a question about attribute pricing. A client has this and Dual Pricing installed. The product wholesale pricing works great as that field is in the products table. For the attribute pricing, the field (options_values_price_w) is in the products_attributes table.

I thought I'd try adding it to the configuration anyway. No good:
User Defined Products Fields:
products_price_w: TRUE
options_values_price_w: FALSE

Is there a way to export and then import attribute pricing? Or would that functionality need to be added first?

[mc12345678]

I've got a question about attribute pricing. A client has this and Dual Pricing installed. The product wholesale pricing works great as that field is in the products table. For the attribute pricing, the field (options_values_price_w) is in the products_attributes table.

I thought I'd try adding it to the configuration anyway. No good:
User Defined Products Fields:
products_price_w: TRUE
options_values_price_w: FALSE

Is there a way to export and then import attribute pricing? Or would that functionality need to be added first?

Good news/bad news...

Good news is that if you have created a detailed attribute file that has the v_options_values_price_w field and the field is present in the database then it will be updated with whatever data has been provided. Also, export of a detailed attribute file should include the field. Bad news is that at the moment, without one additional tweak to the code, if the field is present in the database and is not in the file, then the field will be cleared out...

So, to fix this aspect:
In admin/includes/modules/

Change line 27 from:

  if ($ep_supported_mods['dual']) {

To

  if ($ep_supported_mods['dual'] && isset($filelayout['v_options_values_price_w'])) {

Support of the field can be identified by looking in the "upper" right hand corner should be an indicator about dual pricing and it being shown as true.

[mc12345678]

Oops. Filename is: admin/includes/modules/easypopulate_4_attrib_detailed_ep.php

[jeking]

I edited the file as you indicated, added the field in the configuration but not sure this is the result we need.

User Defined Products Fields:
products_price_w: TRUE
options_values_price_w: FALSE


I did an export and the options_values_price_w column is not in the Detailed Products Attributes file.

Did I misunderstand something you said?

[jeking]

Too late to edit.....hold on, editing error on my part. Update to come....