EasyPopulate 4.0 Support Thread

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_options_name_4,v_products_options_name_5,v_products_options_values_name_2,v_products_options_values_name_4,v_products_options_values_name_5
"WOOall83130x18002","5","Kleur","Color","Farbe","Groen","Green","Grün"

help would be appreciated.

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_options_name_4,v_products_options_name_5,v_products_options_values_name_2,v_products_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/EasyPopulate-4.0/commit/e84470175fe4235311e064efacd73083136f623a or by replacing the file with the one provided at: https://github.com/mc12345678/EasyPopulate-4.0/blob/attrib-import-lid/admin/easypopulate_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/EasyPopulate-4.0/commit/e84470175fe4235311e064efacd73083136f623a or by replacing the file with the one provided at: https://github.com/mc12345678/EasyPopulate-4.0/blob/attrib-import-lid/admin/easypopulate_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.

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?

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?
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'] [b]&& isset($filelayout['v_options_values_price_w'])[/b]) {

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.

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

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?

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

> jeking:

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

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....
Understand that more is likely to come, but would like to go ahead and cover what has been already "discussed".

So I didn't correct the attempt to use the User Defined Products Fields for an attribute field, which would be why the above "FALSE" occurred, because that field (options_values_price_w) does not exist in the products table. (Sure someone could add it, but it is not the field in question.)

So then the desire is to work with that field which has been identified as working with the module titled "Dual Pricing". As such, in the list of Custom Products Fields, if the options_values_price_w field is identified in the products_attributes table, then a TRUE will be shown. Ie.:
Product Short Descriptions: FALSE
Product Unit of Measure: FALSE
Product UPC Code: FALSE
Google Product Category: FALSE
Manufacturer's Suggested Retail Price: FALSE
Manufacturer's Advertised Price: FALSE
Group Pricing Per Item: FALSE
Exclusive Products Mod: FALSE
Stock By Attributes Mod: FALSE
CEON URI Rewriter Mod: FALSE
Dual Pricing Mod:TRUE


With that shown as TRUE, the field is expected to be included in the exported attribute_detailed file and with the correction applied above that same system could process a detailed attribute file that does not have the field and the field would remain unchanged. If the change is not applied, then the field would need to remain present when importing or else the field would become blank for each successfully processed row.

Ok, the problem was I didn't notice the installed version was 4.0.28.

I upgraded and now the v_options_values_price_w column is in the file, as expected. I've applied the edit to easypopulate_4_attrib_detailed_ep.php as well.

I'll do a small test before importing to be sure that works as planned and report back if we run into issues.

I love when things work the way they are supposed to!!

trying to get EP newest version to work on our site. We originally were able to use it without issue, install went fine etc. I was able to use it to manually move 7k products from our previous site (based on magento) into our new ZC site. Upload seemed to work fine, but after a certain (unknown) point export ceased working. I am guessing this is due to the quantity of products we are working with. However, after we got everything moved up we had a firm install and configure a custom template for us...template is based on simple mods of the base template, nothing terribly fancy or crazy and no core file mods. However, after that they ended up pulling out EP and told us it no longer worked with the current version of ZC. As a test, I took the final site and copied it to a staging domain and tried to install...install seemed to sort of work but it completely broke the CSS for the admin area and didn't seem to work for either upload or download.

I am really wanting to be able to use EP because it's a very handy module to have. Our current site is running on 1.5.5e (haven't updated to f yet). So, after searching this thread and the forum at large and not really finding solid answers I want to know:

1. can we install and get EP working with our site, given the amount of products and template changes? If it helps, feel free to take a look at the current site at https://clearwaterhydraulics.com

2. If we can get this installed and working, is there a way to keep it from breaking the CSS on the admin panel?

3. anything else I should know, that perhaps I am missing here, that needs to happen to get this to install and work correctly?

Any help would be most appreciated!

Ok, so, going to say wow... for starters.

Let's try to address each issue separately then get to where you are wanting to get.

First of all, EP4 doesn't care about the store side template. So, the only benefit/issue is how has the database been changed to support the template in regards to product specific data and the tables that might relate (ie. Categories, manufacturers, attributes, etc...)

With regards to how the admin screen of EP4 looks, well, there are some tables that are used and default ZC "references" to things like the admin menu. There is nothing about the EP4 admin display that would affect admin operation/display other than when looking at the EP4 "window". If that has been significantly revised, then there is something that has otherwise been modified that possibly needs to be brought into your install of EP4.

As to product import/export. The amount of data associated with that process is why there are some additional options for both operations. For export there is a series of dropdowns that allow export of smaller groups of data. For import there is a split "utility" intended to take a large file for import and create data chunks that each are manageable. There are some changes that have been made on github which may allow larger import/export files, but this is also dependent on server configuration. It does not address anything else of what has been described above.

To be honest, I'd probably have to have access to the admin area to identify the "css" related issues described as an image of that screen compared to another admin menu would not likely be sufficient to address that aspect.

The instructions do at least lightly describe settings that can be modified to support longer time durations for import/export.

But, the statement that the plugin is not functional for ZC 1.5.5x is untrue. Not compatible with whatever admin templating was done, sure could be that way, but not unmanageable.

Hi
Exporting prices, for some reason I can't format either in libre calc or Excel decimal values like this: 11.99, 5.5, etc...
While integers it formats: 17 to 17,00 EUR , etc...

What can I do to go around this ?
I actually never need it, always use the cvs format, to update, but now I do nedd to convert this values to use somewhere else.

Thanks

Could you connect the dots a little more?

Export of the file creates a csv file with numbers in it. When using a plain text editor, what do these numbers look like?

Then opening in open office or Libre, how does this display change?

When saving/save as the file (using a slightly modified filename to support comparing) how do the numbers now appear?

Then upload and import of that row, what happens?

In a way it sounds as if the application of use is possibly converting the currency symbols to support the locale, but possibly the import file needs to have a different series of currency symbols. If this is the case, then typically such settings are specific to the cell(s) of the spreadsheet and at least for import to the store, the file should be formatted to the same as the store exports.

mc12345678:

Could you connect the dots a little more?

Export of the file creates a csv file with numbers in it. When using a plain text editor, what do these numbers look like?

In a way it sounds as if the application of use is possibly converting the currency symbols to support the locale, but possibly the import file needs to have a different series of currency symbols. If this is the case, then typically such settings are specific to the cell(s) of the spreadsheet and at least for import to the store, the file should be formatted to the same as the store exports.

They look like ... numbers :)
What I find odd, is that I can't format the decimal numbers either in excel or libre calc
The example bellow shows what happens.
With specials prices, the same thing.

It's a bit odd, isn't ? Can you convert some price like 11.99 to 11.99 EUR in excel / libre calc ?

4,00 EUR
4,00 EUR
4,00 EUR
4,00 EUR
5.5
5.5
5.5
5.5

Thanks

Just to be clear.
The export / import works as desire.
I just want to format in libre cal .

I would add another column with a header that doesn't conflict with ZC (best for it not to start with v_) after the price and include the currency there. This way the data doesn't get affected by the added user information, but it still adds value to reviewing the file. The extra field will be ignored on import so won't have an effect on the store.

Hopefully have understood the intent.

If you do want to concatenate two fields (join them) at that point, then there is a function aptly named concatenate to do just that. A yet other column could be created to have that information and would be something like (see help file for associated program): =CONCATENATE('A2',' ','B2') which would take the content of cell A2, put a space after it, then to that add on the contents of B2. If the function is in cell C2, then it could be copied down for the rest of the column and the contents of the cell would become the combination of the two.

After that, I suggest searching the Internet for other useful ways to work with spreadsheets and workbooks to accomplish your desired operation.

Otherwise perhaps I still haven't understood the question. But past experience has been that the file needs to be opened not as read only in order to manipulate cell styles etc...

Thanks.
I could do that, but there's a catch: I also need to change the dot to a comma ( for whatever reason we use that currency format).
And even that I can't do.
Haven't tried to use the "find and replace", but that a lot of extra steps , that opens doors to mistakes.

I'm trying to export to a Facebook catalog, and they require that format: 10,50 EUR.

Now, in Zen cart the prices are displayed correctly for my country, with a comma.
Maybe I could change the $row "prices" at export ( using the ep4bookx), to use the country currencies format, but I think that's a class "currencies".

Either way, it puzzles me why I can't format the numbers.
Thanks

So there are a couple of options...

Export could be by use of ZC currency style "conversion" as one.
Another is through instruction related to this libreoffice help article: https://help.libreoffice.org/Calc/Cells_in_Currency_Format
Though the cells may initially be in text or general format and need to be changed to a currency format.
Or by way of "equation" to build/rebuild the values through some sort of operation(s) like find and replace on the column.

Presumably though this is something you'd like to automate rather than have to manipulate on each such transfer. To accomplish that and not to disrupt the normal export process, a new field would be needed in the export file. That is accomplished by "adding" a field to the filelayout for the export type that is to have that field.

Then at some point after the price has been collected from the database, the field for the associated record would need to be "built" to contain your desired text. I don't know if you would be trying to export in every currency supported by the store or just the default currency, but for each such field, would need a filelayout field.

The currency could/would be exported using the $currencies variable/class which is declared in the easypopulate_4.php file. The currency class offers output "modules" to support providing the string version of the currency. Some manipulation may be necessary to append the three letter representation of the currency, but it is all something doable for any of the exports that offer the price of the product.

Thanks
After all with a "search and replace" dot by comma does the trick, and then I can format the numbers.

Another question, I now realize that if a products is "linked" ( two categories) , it exports in two different lines. Is there a "simple" way not to do it?

Thanks