EasyPopulate 4.0 Support Thread

mc12345678:

No, your English is fine, I was however able to consider multiple ways that the information could be understood. I did not want to try to guess too much. :)

I have taken a look at the code and I have tested the changes. I have uploaded some more changes to 4.0.34 to https://github.com/mc12345678/EasyPopulate-4.0

You are very kind: I'll try this new version

mc12345678:

No, your English is fine, I was however able to consider multiple ways that the information could be understood. I did not want to try to guess too much. :)

I have taken a look at the code and I have tested the changes. I have uploaded some more changes to 4.0.34 to https://github.com/mc12345678/EasyPopulate-4.0

I always see duplicate "v products_model"
Let me know if I can privately send the exported file

mc12345678:

No, your English is fine, I was however able to consider multiple ways that the information could be understood. I did not want to try to guess too much. :)

I have taken a look at the code and I have tested the changes. I have uploaded some more changes to 4.0.34 to https://github.com/mc12345678/EasyPopulate-4.0

Question: can I go back to an old version v4.0?
The one I was working or they might be problems with the SQL DB?

Nightfly66:

I always see duplicate "v products_model"
Let me know if I can privately send the exported file

I noticed this as well when I exported using both an older version and the latest... With one language and two.

The temporary solution (workaround) would be to edit the last record in the grouping of the v_product_model (ie. Sorted by v_product_model) and upload that file or take action to reduce the number of rows of a v_product_model to one.

Before making a change to the code to reduce that result to one entry per product_model, need to understand how that "feature" is used/could be of benefit to someone. Result may be that need to add another admin->configuration control in order to allow/prevent that duplication. I don't like taking away a "feature" that exists if there is a benefit to it's presence.

Nightfly66:

Question: can I go back to an old version v4.0?
The one I was working or they might be problems with the SQL DB?

Yes you can, the suggestion would be to first use the remove/uninstall feature in the right corner of the tools->EP4 window, then to remove the current EP4 files, load the replacement (old) EP4 files and install as normal.

There may be "compatibility" issues in that the older code may not work on the current system. May I ask why this is desired?

mc12345678:

Yes you can, the suggestion would be to first use the remove/uninstall feature in the right corner of the tools->EP4 window, then to remove the current EP4 files, load the replacement (old) EP4 files and install as normal.

There may be "compatibility" issues in that the older code may not work on the current system. May I ask why this is desired?

I wish that the software is functioning as previous versions. I would like that you to confirm to me that I have no problems in importing especially prices and inventories, and that these errors do not harm my database.

Nightfly66:

I wish that the software is functioning as previous versions. I would like that you to confirm to me that I have no problems in importing especially prices and inventories, and that these errors do not harm my database.

As recommended in the instructions, this code like any other including an upgrade to ZC ought to be tested for the desired condition(s) actions independent of a live server (or at least with a backup made immediately before pushing data). The countless variations possible prohibit 100% testing of every possible condition. As can be seen, issues identified are rapidly addressed.

mc12345678:

No, your English is fine, I was however able to consider multiple ways that the information could be understood. I did not want to try to guess too much. :)

I have taken a look at the code and I have tested the changes. I have uploaded some more changes to 4.0.34 to https://github.com/mc12345678/EasyPopulate-4.0

Now, with a little more calm, I tried the v4.0.34 and it works OK!
Thank you ! You were very good!
I always duplicate products, but I have no import errors.
Thanks again !

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 :P 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 :P

-chadderuski

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 :P 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 :P

-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.

@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. :)

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!!!

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!!!

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. :)

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 :P 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 :P

-chadderuski

mesnitu:

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.

Modification/patch applied (to EP4.0.34) and can be found at: https://github.com/mc12345678/EasyPopulate-4.0/commit/23d9b848cfeee30c300b2e940948651b30a62005

Cool ! :smile:

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

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 ?

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 ?


$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.

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

This also worked for me. Looks like a great solution

@mesnitu: It was always intended to make the category delimiter customizable in the config area, but issues like these got in the way.
Also note that EP4 is the only easypopulate version that actually supported multilingual categories. I was quite proud of that.

Didn't realize that you're Chadd from EP4

Hats off !