EasyPopulate 4.0 Support Thread

[chadderuski]

Hey Bro!

Well, now that 1.55 is out I decided to give it a test drive along with your updated EP4 >>NOW IN THE PLUG-INS SECTION - YEAH!<<

Clean install on PHP 5.6.19 (still waiting for cpanel to offer PHP 7 support), and MySQL 5.6.29.

Exported data from live site using my EP 4.0.23: Full, Quantity Breaks, and Attrib files.

I ran into a small problem on importing my full sheet. For some reason category names were not being split on the "^" character.
I had to switch from mb_split() to explode() even though I'm using UTF-8 to get the categories to break properly. The sheet was as exported, so it should have worked as is. It did work with explode() and the sheet imported, but I don't have any funky characters in my data.... hmmm... I think not might be some registered and TM characters in there which are MB.

I don't think explode() supports multibyte languages (like russian, etc.), but I'll have to read up on that again.

Anyway, after getting that to work, the quantity breaks and attrib files imported fine.

I'll have to read up on mb_split() again to see what might be going on.

Congrats on all the hard work and additions. Hope all the free support doesn't wear you out

-chadderuski

[mesnitu]

Hey Bro!

Well, now that 1.55 is out I decided to give it a test drive along with your updated EP4 >>NOW IN THE PLUG-INS SECTION - YEAH!<<

Clean install on PHP 5.6.19 (still waiting for cpanel to offer PHP 7 support), and MySQL 5.6.29.

Exported data from live site using my EP 4.0.23: Full, Quantity Breaks, and Attrib files.

I ran into a small problem on importing my full sheet. For some reason category names were not being split on the "^" character.
I had to switch from mb_split() to explode() even though I'm using UTF-8 to get the categories to break properly. The sheet was as exported, so it should have worked as is. It did work with explode() and the sheet imported, but I don't have any funky characters in my data.... hmmm... I think not might be some registered and TM characters in there which are MB.

I don't think explode() supports multibyte languages (like russian, etc.), but I'll have to read up on that again.

Anyway, after getting that to work, the quantity breaks and attrib files imported fine.

I'll have to read up on mb_split() again to see what might be going on.

Congrats on all the hard work and additions. Hope all the free support doesn't wear you out

-chadderuski

I'm having the same situation. Portuguese in my case. Already reported in git.
In my case, I did stick to the mb_split('\x5e' used in previous versions.

And also, for what I can see, all is in utf8.

[mc12345678]

@chadderruski

*sigh* yes as mesnitu has just posted, he and I were trying to address that. The entry fed to mb_split is to be a regex expression. It works if the statement is single quoted text. But if feeding a variable, well there are some things that should be done to escape it, but even with that I've had intermittent success with different potential solutions... I was trying to streamline the process having seen how some don't like the carat and prefer to use something else. So thought I'd try to make it easier to change by having the info in one place and I thought I had tested it successfully.

Further, the issue of UTF-8 compatibiliity just seems odd because ZC doesn't appear to use the mb_ functions, but does claim full UTF-8 compatibility and frequently uses explode. But, results count more than discussion.
:)

Unfortunately yes, it appears that in trying to make things "better" that there was something bound to go wrong. :)

[tk42one]

Hi All,

I have a client I'm migrating over to zencart for their online marketplace as well as for their instore POS. I've been able to do everything I need with EP4 but have one issue I haven't been able to correct. I need to upload an additional barcode field with each product to work the the instore POS. I see that EP4 has a barcode field but it's set to "false" and despite my searching I haven't been able to find a clear way to add this field to the spreadsheet. I apologize if this has been addressed before, this is my first foray into zencart so I'm still exploring the full support options. If I'm dumb and there's a clear answer to this that I've overlooked feel free to call me stupid, but please link me to what it is as this has been thoroughly stumping me.

Thanks in advance and for all your effort in this plugin, it's saved me a great deal of time already!!!

[mc12345678]

Hi All,

I have a client I'm migrating over to zencart for their online marketplace as well as for their instore POS. I've been able to do everything I need with EP4 but have one issue I haven't been able to correct. I need to upload an additional barcode field with each product to work the the instore POS. I see that EP4 has a barcode field but it's set to "false" and despite my searching I haven't been able to find a clear way to add this field to the spreadsheet. I apologize if this has been addressed before, this is my first foray into zencart so I'm still exploring the full support options. If I'm dumb and there's a clear answer to this that I've overlooked feel free to call me stupid, but please link me to what it is as this has been thoroughly stumping me.

Thanks in advance and for all your effort in this plugin, it's saved me a great deal of time already!!!

So this is a topic discussed in one way or another a few times in this thread... The indicator for "barcode", identifies that the applicable field has been added to the products table (or not when false). Currently the fields in the products table that are checked for are basically:

products_short_desc, products_price_uom, products_upc, products_gpc, products_msrp, map_enabled, map_price, products_group_a_price, products_exclusive, and options_values_price_w

If any of those fields exist in the products table, then the applicable false should become true. If the field you wish to populate exists in the products table, but is not in that list, then you would want to add the field to the user defined fields in the configuration window for EP4. That field though should be populated there like it appears in the products table when viewed with tools such as phpmyadmin. But, to populate the database from your file, your file will need to have the field in the header row with the v_ (letter v with and underscore) in it...

Again, the field must already exist in the database. EP4 does not create database fields, it manages those that exist. Yes there is information related to this also in the instructions as well, but doesn't really hurt to try to ask from a different direction. :)

[mc12345678]

Hey Bro!

Well, now that 1.55 is out I decided to give it a test drive along with your updated EP4 >>NOW IN THE PLUG-INS SECTION - YEAH!<<

Clean install on PHP 5.6.19 (still waiting for cpanel to offer PHP 7 support), and MySQL 5.6.29.

Exported data from live site using my EP 4.0.23: Full, Quantity Breaks, and Attrib files.

I ran into a small problem on importing my full sheet. For some reason category names were not being split on the "^" character.
I had to switch from mb_split() to explode() even though I'm using UTF-8 to get the categories to break properly. The sheet was as exported, so it should have worked as is. It did work with explode() and the sheet imported, but I don't have any funky characters in my data.... hmmm... I think not might be some registered and TM characters in there which are MB.

I don't think explode() supports multibyte languages (like russian, etc.), but I'll have to read up on that again.

Anyway, after getting that to work, the quantity breaks and attrib files imported fine.

I'll have to read up on mb_split() again to see what might be going on.

Congrats on all the hard work and additions. Hope all the free support doesn't wear you out

-chadderuski

I'm having the same situation. Portuguese in my case. Already reported in git.
In my case, I did stick to the mb_split('\x5e' used in previous versions.

And also, for what I can see, all is in utf8.

Ah ha... I think I may have the alternate solution to be able to do both things... Use a variable and to use mb_split.. :)

Change line 1112 in admin/easypopulate_4_import.php from:

$categories_names_array[$lang['id']] = mb_split($categories_delimiter, $items[$filelayout['v_categories_name_' . $lang['id']]]);

To:

$categories_names_array[$lang['id']] = mb_split(preg_quote($categories_delimiter), $items[$filelayout['v_categories_name_' . $lang['id']]]);

Let me know if that resolves the problem/issue.. It works correctly on an online sandbox area where the other two solutions also work but the code as is seems to have the problem described... Ie. the online tester seems faithful and looking at how preg_quote modifies the $categories_delimiter variable changing it from \x5e to \\x5e, this makes sense especially from the standpoint that when imploding things that a regex is not used, but when a regex is used the proper escapes need to occur. :)

Let me know what the two of you think/find... Nice to have a few independent eyes piping up on things.

[mc12345678]

Modification/patch applied (to EP4.0.34) and can be found at: https://github.com/mc12345678/EasyPo...48651b30a62005

[mesnitu]

Cool !

$categories_names_array[$lang['id']] = mb_split(preg_quote($categories_delimiter), $items[$filelayout['v_categories_name_' . $lang['id']]]); 

[mesnitu]

But is there a reason to make this change ?

$categories_delimiter = $category_delimiter; // add this to configuration variables 

Should'n it be a "global" delimeter ?

[chadderuski]

But is there a reason to make this change ?

$categories_delimiter = $category_delimiter; // add this to configuration variables 

Should'n it be a "global" delimeter ?

$category_delimiter (not categories) is defined at the top of easypopulate_4.php.

This code is a bit "mixed up" here from attempts to fix the various issues dealing with multi-byte languages.