EasyPopulate 4.0 Support Thread

Quote:

---

Originally Posted by wtashby

One quick, perhaps dumb question. Why did you move from v_category_name_1, v_category_name_2, etc. to using the caret? That, to me just complicates things having to use formulas and such instead of the old way.

---

You mean, way back when why did chadderuski change up the method of assigning categories?

Well, there were two things at play from what I have seen throughout the thread and from looking at how it works. One was that there was the concept of multiple languages, so there had to be a method to apply that, then there was the "stack-up" of categories.. How many v_categories_name_x fields need to be added to address the multiple layers in which a product can exist? Then on top of that applying a second+ language at the same time...

So, as to the use of the caret (or other character as so desired), v_category_name_1 is the category name for the product in the row that is to be in the first language of the store (having language_id = 1), the category that it resides is main_cat1^sub_cat1^sub_sub_cat1^sub_sub_sub_cat1 Thus the product's category is fully defined in a single field.

This has been this way with EP4 for as long as I've known it (4+ years), so I'm curious about to what "old way" this is being compared.

Quote:

---

Originally Posted by Nightfly66

I will try to explain better with some examples:

1) Each product has a unique code (v_products_model) but each product has a unique code but this code is duplicated for the product name in English and the name of the product in Italian language (v_products_model)
2) I have twice the same product code associated with the same product model one by the name in Italian is the second with the name in English
3/4) I do not have blank fields
5) With earlier versions, I have never had need to enter anything in the User Defined Fields Products
6) There may be some products linked in different categories
7/8) v_products_model, v_products_name, v_status, v_specials_price, v_specials_price, v_specials_date_avail, v_specials_expires_date, v_products_price, v_products_quantity.

All fields are duplicates with the same values. The problem seems to be "v_products_nam"e which is in two languages

Sorry for my English. I hope I was clear in explaining

Regards

---

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

Quote:

---

Originally Posted by 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

Quote:

---

Originally Posted by 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

Quote:

---

Originally Posted by 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?

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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?

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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

Quote:

---

Originally Posted by 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!!!

Quote:

---

Originally Posted by 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. :)

Quote:

---

Originally Posted by 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

---

Quote:

---

Originally Posted by 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:

Code:

---

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

---

To:

Code:

---

$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/EasyPo...48651b30a62005

Cool ! :smile:

PHP Code:

---

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

PHP Code:

---

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


---

Should'n it be a "global" delimeter ?

Quote:

---

Originally Posted by mesnitu

But is there a reason to make this change ?

PHP Code:

---

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

PHP Code:

---

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

Quote:

---

Originally Posted by chadderuski

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

---

My use of EP4 is with full export and now with bookx files. And in those situations I don't see a reason to re-assign that variable upon categories.
But possibly is related with attributes and stuff that I never used.
Or someother stuff that I'm not seeing .

Quote:

---

Originally Posted by mesnitu

But is there a reason to make this change ?

PHP Code:

---

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


---

Should'n it be a "global" delimeter ?

---

Quote:

---

Originally Posted by chadderuski

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

---

Quote:

---

Originally Posted by mesnitu

My use of EP4 is with full export and now with bookx files. And in those situations I don't see a reason to re-assign that variable upon categories.
But possibly is related with attributes and stuff that I never used.
Or someother stuff that I'm not seeing .

---

Not sure what the confusion/issue is, but let me discuss a little about change control...

Looking back on the history of admin/easypopulate_import.php, one can see that $categories_delimiter was set as:

Code:

---

$categories_delimiter = "^";

---

Somewhere around line 1097 (at one point, ie: https://github.com/mc12345678/EasyPopulate-4.0/blob/37d4428346615d82127117df00b9ceb1e8b69db4/admin/easypopulate_4_import.php)

So, looking through the code, the only place that the variable $categories_delimiter was used, was in the commented out explode function that followed it for those that might still be using latin1.

Okay, so the variable basically wasn't used anywhere in the import code.

Now, the overall goal is that whatever is used to join the categories on export, would be the same as that for separating them on import. Well, on export the variable used was simply a carat "^", no special UTF-8, no mb_implode (assuming function exists), nothing special... Just take the category's root, append the carat, add the next sub-category, add a carat, and in the end have the category path for the product concatenated with the carat between each category.

So... Then on import, the goal was to then take all of those carat's and split them up to go to the appropriate category tree... Well, in an effort to maintain the ability to do that with "foreign" characters, the multi-byte function mb_split was used which is supposed to analyze the string and correctly identify where the cut-offs are at. Well, at the time of writing, it was not discovered on how to split that string into it's pieces using the multi-byte function and the desired character; however, it was known what that character in UTF-8 had to be: \x5e. So to allow things to move forward, the specific UTF-8 equivalent character encoding was supplied to the mb_split function and the variable $categories_delimiter was in a way "left behind"... But.....

Now there are those that have (maybe?) reviewed the code because of some issue and seen the comment in the file... Hey if you're using latin1, then uncomment the one line and comment out the mb_split line... Okay, so they do that and continue on their merry way knowing that $categories_delimiter is set as "^" and is used in the function. So, sure the individuals could have gone and changed other things, but now a modification has been introduced. Namely, if we define the delimiter to be used for any category at the "top" of execution, ie in one place, then it needs to be used in all places..... Well, to accomplish this and not modify too many places of code for too many different users, make the least amount of changes at this time to maintain operation for those that have chosen to use the code as is. Therefore, for those still using latin1 (for the most part suggest moving to UTF-8 as ZC now pushes for all things to be UTF-8), then the $categories_delimiter variable should match whatever is being used on export ($categories_delimiter = $category_delimiter).... Okay, so that would take care of those using latin1; however, those using UTF-8 (otherwise unaltered code), they need to have something consistent... Well, in the import side there is this variable that now is assigned to a relatively appropriate value and is defined locally rather than some far off distant pre-code, so... $categories_delimiter was chosen to be used... This also would support those that may have previously used that variable similar to how it is being used now (preg_quote($categories_delimiter)) therefore, this would have a minimal impact on those users that chose not to share their solution. Will it stay this way? Maybe, maybe not, but it provided some of the minimal changes that could be made to remain possible to follow and logical when reviewing the code. Could the mb_split function have used $category_delimiter, sure, but would you know where to search at that point to identify what it's value was? The other way this could have gone is that everywhere on the export code that $category_delimiter was used it could have been renamed $categories_delimiter, and then the $categories_delimiter in the import code could have been commented out... Considered that.. Didn't make sense...

Plus for those that did any type of comparison in upgrading and saw this change and saw that it didn't work could revert back to what was previously there with great ease... The two of you identified there was a problem, provided alternate solutions; however, neither appeared to accomplish the main goal, divide a string of text that is in UTF-8 format into its UTF-8 components based on a UTF-8 "divider" regardless of the language or information in the string and to ensure that the dividing delimiter was the same for both export AND import through a single assignment... Ie.. Make it easier for those that use this to maintain consistency and to alter the divider as desired...

So, like I said, I don't know what the issue is with the variable $categories_delimiter at least "temporarily" (until a later change) being used and assigned to $category_delimiter is...

No issue or confusion, I was just pointing that out.

Quote:

---

Originally Posted by mesnitu

No issue or confusion, I was just pointing that out.

---

But what was being pointed out?

That in EP4

PHP Code:

---

$category_delimiter = "\x5e"; //Need to move this to the admin panel 


---

on import (before the your last commit ):

PHP Code:

---

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


---

Why not :

PHP Code:

---

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


---

[/PHP]

But has you explain, this was a ongoing process, and I quite understood.

Submitted version 4.0.34.a to include the preg_quote() command for import and address maintaining the category separation for both export and import... That is the only real change, which for those that already have installed 4.0.34 or manually made some of the earlier changes will see the notification on their admin page.

When reviewed and accepted will be available from this download link.

Quote:

---

Originally Posted by Nightfly66

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 !

---

Can i to use new Version ?

Quote:

---

Originally Posted by Nightfly66

Can i to use new Version ?

---

I'm sorry, I don't believe I understand the question. I can take a few guesses, but I'd rather not. :)

Quote:

---

Originally Posted by mc12345678

Submitted version 4.0.34.a to include the preg_quote() command for import and address maintaining the category separation for both export and import... That is the only real change, which for those that already have installed 4.0.34 or manually made some of the earlier changes will see the notification on their admin page.

When reviewed and accepted will be available from this download link.

---

Version 4.0.34.a has been made available for download. Version corrects the issue discussed over the past couple pages about the delimiter for categories.

hi
I've been looking into rewards points. Not sure if already exists in EP4, but if it doesn't , it looks not too complicated to do it, but :
Now that EP4 as all those notifiers, what it's the best approach in terms of logic and performance, to incorporate in the core, or use another class, auto load , etc... ?
In this case, it would only deal with ration for categories that could be attach to categories file, and products... possibly in the full export.


Best Regards

Quote:

---

Originally Posted by mesnitu

hi
I've been looking into rewards points. Not sure if already exists in EP4, but if it doesn't , it looks not too complicated to do it, but :
Now that EP4 as all those notifiers, what it's the best approach in terms of logic and performance, to incorporate in the core, or use another class, auto load , etc... ?
In this case, it would only deal with ration for categories that could be attach to categories file, and products... possibly in the full export.


Best Regards

---

What data is applicable to the rewards point system as it relates to products? Ie, what changes are made to the ZC database to support this added functionality. If the only thing really modified is the products table, then no code changes are required. Would simply add the products table field data to the user defined fields in the admin configuration.

I don't have the updated module, not sure if it is the same, but for what I see, related to products it's only one table, the rewards master, that uses a columns "scope" to define if it is a product or categories, and "scope_id" to relate those cats / products IDs, and the rest to place the rewards ratio.
But I just have a quick look, so I'm talking in the air.
But, for what I understand , if it's outside the "products" tables, the user defined fields, doesn't "work"

edit: There's a global reward ratio, and the categories can all use that one or have there own ratio, but if one doesn't have hundreds of categories they are quite accessible ... but for me, the products it's more significant. That's the reason the I thought on doing it

You are correct the user defined field is good for only products table data. To incorporate something like this where data is being populated in a single table, I would suggest creating an additional link on the main EP4 page using the notifier that is in line with options like full export, categories, attributes, etc. Before that would pull in any definitions needed at EP4_START. Would add a file type/name, export filelayout and sql would be addressed by the default:section of the filelayout module listening for the desired "filetype" then well, I've currently run out of steam on describing the remaining export, but there should be an existing appropriate location to address a "new" filetype export. Import would more than likely be similar to what has been done for bookx, but more than likely be using the primary key of the rewards module table rather than a specifc products_id or category_id.

That last part said, two file types could be created, one for products and one for categories, or maybe three to then have a combined style. The user then could choose which method is easiest for their work method and controls...

I was checking , and the Features File , on import using the 9 status doesn't delete the featured product.
Is there another way ? Or this is not implemented ?

tahnks

Actually the status 1 is not doing anything. And if a date is left blank I'll get the year 2036.

Quote:

---

Originally Posted by mesnitu

I was checking , and the Features File , on import using the 9 status doesn't delete the featured product.
Is there another way ? Or this is not implemented ?

tahnks

---

Quote:

---

Originally Posted by mesnitu

Actually the status 1 is not doing anything. And if a date is left blank I'll get the year 2036.

---

This back to discussions you and I have had about the specificity of EP4. It has to date worked with ZC as one would work with ZC except in large quantities. Are you able to change the status of a product from the featured section of the ZC admin? As for the date, changes had been implemented in the main product area, will take a look at the featured section to see what has or has not been done to account for the absence of entered data/more recent PHP versions, etc... The expectation of a non-date when populating the database is 0001-01-01. The result of 2036 is entering 0000-00-00 which I thought I had seen even that this could be a database setup issue of having a default of 0000-00-00... (Issue brought to light in upgrading to ZC 1.5.5 and sql needed to correct for some date fields in some tables.)

Had the ability to start edting the above, but figured I would run out of time. I expect there to be comments that everything ought to be possible in a single upload, but there are some aspects that when working with multiple tables and many, many, many rows of data at once take an inordinate amount of time to process. Even EP4 has a file split operation to allow upload of multiple products as a result of the breadth and processing power (time) needed to import so many rows into so many tables. Yes some have been able to increase the number of rows by decreasing the number of fields (for other reasons as well) but there are still limits.

Never had used the featured file.
But I thought that would import, cause there's a import button, and all the status fields... so, this file should not be imported ? Or is just to change dates ?

I meant deleting a featured product, not the product itself.... I think the featured as it's own relation.

Nop, sorry for the dumb question, I've check the import section for the featured file, and it's all there.
If I have them active, I can set them to 0 . But from 0 status to 1 .... no.
But, again, has I'm using the books fields, probably something is not right.
I'll check that later.

It's basically date based. Factors involved are starting date, ending date and current date. Other fields are present to aid the "reader". Do YOU know what products_id 189 is? Maybe as one that manages the ZC data all the time you might, but someone that works in "the store" doing inventory or selling an item, more than likely they know it by it's name or description.

At any rate, the code works like this: if the available date for the featured item is less than the current date and the current date is less than the end/expire date, then the product is turned "on" during import with ZC taking over the remaining on/off controls, if the current date is before the start date or after the end date then as written EP4 will turn off the featured item. That said, the test probably should be if it is after the end date but the end date isn't "empty" (0001-01-01) then turn it off, after all if someone wants a product to *always* be featured after some point, then that would seem like the date to use, but probably also need to look at how ZC accomplishes this before making that change.

Anyways, that's a brief description of the operation. This is not "product type" specific meaning that using bookx or not, the core EP4 code works as described above, though it does look like it could use some minor improvements in this area. (More for Version 4.0.35 :) )

Thanks! Actually that cleared a lot up for me. I appreciate the response!

Quote:

---

Originally Posted by tk42one

Thanks! Actually that cleared a lot up for me. I appreciate the response!

---

Welcome, glad I could help at least a little. :) any other things that are "perplexing"?

I've got this installed on a new ZC 1.5.5. When I try to download one of the csv files exports, I get a 403 forbidden error and no download. In the settings, I have:
Upload Directory: admin/temp/
This folder has permissions of 0755

If I change the setting 'Uploads Directory Admin/Catalog' to false, I get no error.

Would anyone have a blank . CSV file with the Canada Post measurement fields that they could share?

Thanks in advance.

Quote:

---

Originally Posted by jeking

I've got this installed on a new ZC 1.5.5. When I try to download one of the csv files exports, I get a 403 forbidden error and no download. In the settings, I have:
Upload Directory: admin/temp/
This folder has permissions of 0755

If I change the setting 'Uploads Directory Admin/Catalog' to false, I get no error.

---

Well, that indicates that there remains a problem with the "auto-fix" for when the admin directory is entered in the folder path. The current expectation is that the admin directory name not appear in the database. To do this I recommend removing admin/ from the start of your folder's definition and changing the catalog/admin switch to pull from admin only...

For further verification, do you have SSL set to true/in your admin/includes/configure.php file does your url for HTTP_SERVER contain http: or https:?

Quote:

---

Originally Posted by llmcdonald

Would anyone have a blank . CSV file with the Canada Post measurement fields that they could share?

Thanks in advance.

---

If you review the installation package for Canada Post, should be able to identify what the field name(s) are by looking for things like alter, insert into or where $db->perform is used and can review the data being provided. There are other methods available as well such as review of the products table in say phpmyadmin and compare the fields to the install sql for a vanilla install.

There's also a plugin that can identify such differences.

Quote:

---

Originally Posted by mc12345678

Well, that indicates that there remains a problem with the "auto-fix" for when the admin directory is entered in the folder path. The current expectation is that the admin directory name not appear in the database. To do this I recommend removing admin/ from the start of your folder's definition

---

Sorry, where is this?

Quote:

---

Originally Posted by mc12345678

and changing the catalog/admin switch to pull from admin only...

For further verification, do you have SSL set to true/in your admin/includes/configure.php file does your url for HTTP_SERVER contain http: or https:?

---

SSL is enabled for the admin (and storefront) so it's https://

Quote:

---

Originally Posted by jeking

Sorry, where is this?


SSL is enabled for the admin (and storefront) so it's https://

---

There is a "use_function" that has been added to the admin/includes/function/extra_functions file that is called when the configuration settings for EP4 have been modified (at least provided the remove/install SQL has been cycled in one of the newer versions.) The function is supposed to take a basic inspection of the entered path, if the catalog option has been selected and the admin path is present, then the catalog switch is to be auto flopped, and the path shortened to remove "admin". (Where admin is for those not fully following a rename of the actual admin directory and used here for privacy.)

I think maybe I was unclear. In Admin>Configuration>Easy Populate 4 the 'Uploads Directory' is set to temp/ What I posted originally was from Admin>Tools>Easy Populate 4 under the Configuration Settings

Quote:

---

Originally Posted by jeking

I think maybe I was unclear. In Admin>Configuration>Easy Populate 4 the 'Uploads Directory' is set to temp/ What I posted originally was from Admin>Tools>Easy Populate 4 under the Configuration Settings

---

So, your actual upload directory is off of the catalog path then and not in the admin directory? The default install now uses the admin directory settings by default, but there are also those that use EP4 to populate from some form of auto-generation process from outside of ZC and therefore it is desired to continue the possibility of referencing that location, but then when it is desired to switch over to the admin folder for other operations, that the actual admin directory name not be stored in the database.

Because the last three posts have been somewhat incomplete, the actual location of the storage folder has not been fully identified in relation to the two settings needed to assign the folder. Folder path and whether admin (true) or catalog (false) is being used.

Ie. Report was admin/temp while on tools->EP4, this implies that in configuration->Ep4 that the directory was identified as temp/ with the admin/catalog switch set to admin (true) and the report was that this folder has write permissions as expected. When switching this to false, the folder name remains the same (temp/) but now off of the catalog, and this was successful, but this doesn't jive with the original post that indicated that the folder admin/temp had the correct permissions and now that it has been identified that admin/temp was showing on the tools screen, and not in the configuration menu, that changing to false worked to reach the directory.

Unless I've collected the above info incorrectly, the temp directory is inside the catalog path and that there is no problem other than not recognizing that upon reinstall (remove/install) the directory is set to the admin folder.

Oh jeez, sorry for the confusion. :(

Quote:

---

Report is admin/temp while on tools->EP4, this implies that in configuration->Ep4 that the directory was identified as temp/ with the admin/catalog switch set to admin (true) and the report was that this folder has write permissions as expected. When switching this to false, the folder name remains the same (temp/) but now off of the catalog, and this was successful

---

Correct for settings and results. I got the error when trying to download the CSV while in the admin/temp folder but was successful when downloading from catalog/temp

Quote:

---

Originally Posted by jeking

Oh jeez, sorry for the confusion. :(



Correct for settings and results. I got the error when trying to download the CSV while in the admin/temp folder but was successful when downloading from catalog/temp

---

Did you happen to load the .htaccess file found in the download folder: htaccess4AdminTempFolder into this "temp" directory in the admin folder location? The admin directory is typically (by default install) locked down and doesn't include *.csv or *.txt type files to be accessed via a web browser. There was a post a little while back suggesting a slightly modified version of that same file (haven't fully reviewed it yet, so also haven't implemented the suggestion, but it is on the list), but either way, it allows the applicable files to be downloaded. I guess the other "cross-check" is if the path provided for the download directory is one that exists/was appropriate (early implementation with ZC 1.5.5 required a little rework, I've been able to validate that the path works as expected and that I can download a file from my upload/download folder that is generated by EP4).

Quote:

---

Originally Posted by mc12345678

Did you happen to load the .htaccess file found in the download folder: htaccess4AdminTempFolder into this "temp" directory in the admin folder location?

---

Nope, I missed that step. I love a simple fix, thanks. :smile:

Quote:

---

Originally Posted by jeking

Nope, I missed that step. I love a simple fix, thanks. :smile:

---

No problem... Much easier to provide the simple fix once fully understood the conditions. :) Merry populating!

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"

Quote:

---

Originally Posted by jeking

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.

Quote:

---

Originally Posted by mc12345678

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.

Quote:

---

Originally Posted by jeking

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?

Quote:

---

Originally Posted by mc12345678

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.

Quote:

---

Originally Posted by jeking

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.

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?

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.

Quote:

---

Originally Posted by mc12345678

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.

---

Never assume...you know what they say. That was the issue, I had not followed the proper naming convention. When I do, it works! Imagine that.

Follow-up question. Is there a way to export/import an product with attributes in one file? As it stands, it's two steps and two files currently.

Quote:

---

Originally Posted by jeking

Never assume...you know what they say. That was the issue, I had not followed the proper naming convention. When I do, it works! Imagine that.

Follow-up question. Is there a way to export/import an product with attributes in one file? As it stands, it's two steps and two files currently.

---

Well, it got me thinking, thought perhaps after the last issue that was discussed in the instructions and overlooked would have prompted reading the instructions. :P

Yes it is possible, but is it truly desireable?
Small example, table 1 has two fields. One is the primary key, the other is the data. Table 2 also has two fields, one field is the primary key, the other is a data field but that field represents rows of data. So:
T1:
f1, f2
1, x
2, y
3, z
4, w

T2:
F1, F2
1, a,b,c
2, d,e,f
3, a,b,c
4, g,h,i

Now the resulting table (spreadsheet) for combining the two:
F1(f1), f2,F2split
1, x, a
1, x, b
1, x, c
2, y, d
2, y, e
2, y, f
3, z, a
3, z, b
3, z, c
4, w, g
4, w, h
4, w, i

Now, which one of these scenarios is easier to address, understand, and not necessarily make a mistake? Also, to accomplish the same functionality as existing, every upload of the attributes would require all attributes to be included every time in their entirety otherwise the absence of an attribute row would cause deletion of that attribute. Further, on each row every piece of data would have to be compared against the applicable table(s) for existence then update or add the additional data applicable. Sure alternatively can bring information into memory and do a comparison from that perspective instead of a sql statement for each evolution with the applicable data eventually applied with an appropriate sql statement.

This particular approach becomes resource and time intensive. If you have looked back a few pages you'll see that there is an add-on to EP4 to support the product type bookx. That code takes an approach like this. The individual that worked hard to put it together. Thing is, as anticipated because of taking this "do it all at once" approach the processing is slow. At one point the thought was expressed that it is somehow ZCs fault, but it has nothing to do with ZC as one can see in review of the EP4 code EP4 more directly interfaces with mySql than it does with ZC and ZC doesn't "control" mySql, just interfaces with it.

The approach that chadderuski took in development of EP4 more closely matches the original database tables and is why such large bulk changes can be made so quickly. There is a "trade-off" of using this approach. For onsey, twosey updates, it may not be worth the effort to split the input to such simple tables and it may be more worth doing the update within ZC. But in mass quantities, EP4 is a huge savings.... just sayin' :P

The first time when I access .../easypopulate_4.php, it show this.
Attachment 16213

Then I edit easypopulate_4.php and remove line 100.
Attachment 16214

And the pages is working now.
Attachment 16215


What wrong actually? Any solution to solve this other than I remove line 100?
Thank you.

The first image didn't provide any useful information to diagnose the problem, but having removed the require for the language file and seeing the results of removing the language's load line, it would appear that you're missing the language file in the admin/languages/YOUR_LANGUAGE/ directory...

Also, the code could be written to check for the existence of the language file and if not found default to the English language like other aspects of ZC. I'll add that to the list of changes for the next change.

I am trying to import a file I exported just to test and which I click import I just get a blank page. I have tried searching this thread but I was unabel to find a similar problem.


Install of Zen Cart and easy populate are both freshly installed yesterday

Contents of the file are as such
for some reason I cannot attach the file so sorry this is the only way I can figure how to display it.

Code:

---

v_products_model        v_products_type        v_products_image        v_products_name_1        v_products_description_1        v_products_url_1        v_specials_price        v_specials_date_avail        v_specials_expires_date        v_products_price        v_products_weight        v_product_is_call        v_products_sort_order        v_products_quantity_order_min        v_products_quantity_order_units        v_products_priced_by_attribute        v_product_is_always_free_shipping        v_date_avail        v_date_added        v_products_quantity        v_manufacturers_name        v_categories_name_1        v_tax_class_title        v_status        v_metatags_products_name_status        v_metatags_title_status        v_metatags_model_status        v_metatags_price_status        v_metatags_title_tagline_status        v_metatags_title_1        v_metatags_keywords_1        v_metatags_description_1
RM1-1043-000B        1                RM1-1043-000B        HP LaserJet 4345mfp Fuser Assembly                                        0        0        0        0        1        1        0        0                4/22/2016 16:18        50                Printers & Printer Parts        --none--        1        0        0        0        0        0

---

Thank you in advance!

From where did you obtain the EP4 fileset?

Is the information above copied from the file itself (.csv file) or from your data sheet editor?

A blank screen should result in an error log being generated in the logs directory. Feel free to post the contents, but also be sure to obscure your admin folder name (replace with admin).

I downloaded from github p[age


the error in log is

Quote:

---

[22-Apr-2016 18:10:35 UTC] PHP Fatal error: Call to undefined function mb_strlen() in /chroot/home/azcompu1/azcomputing.co/html/XXXXX/easypopulate_4_import.php on line 950

---

The information is pulled from the csv file created by an export

Quote:

---

Originally Posted by mc12345678

From where did you obtain the EP4 fileset?

Is the information above copied from the file itself (.csv file) or from your data sheet editor?

A blank screen should result in an error log being generated in the logs directory. Feel free to post the contents, but also be sure to obscure your admin folder name (replace with admin).

---

Would that be from the page referenced in the first post of this thread? If so, good. :) I'm working on a few changes and let's me know that it is a stable version being reported.

Interesting that the last report of a mb_ related function didn't include any issue with that function, but might as well do something to address it.

If you open admin/easypopulate_4_import.php then search for:

Code:

---

if (mb_strlen($v_products_name[$l_id]) > $products_name_max_len) {

---

Replace with:

Code:

---

if ((function_exists('mb_strlen') && mb_strlen($v_products_name[$l_id]) > $products_name_max_len) || (!function_exists('mb_strlen') && strlen($v_products_name[$l_id]) > $products_name_max_len)) {

---

This way, if mb_strlen exists, the comparison will be made using a multi-byte string length function, and if not then the length will be determined by the standard strlen function.

Yes on the first page of this post , that seemed to advance past this line and on to the next!

Quote:

---

[22-Apr-2016 18:44:00 UTC] PHP Fatal error: Call to undefined function mb_strlen() in /chroot/home/azcompu1/azcomputing.co/html/XXXXX/easypopulate_4_import.php on line 979

---

I fixed several errors by using the code you gave, now I get a different error...

Quote:

---

[22-Apr-2016 19:19:43 UTC] PHP Fatal error: Call to undefined function mb_split() in /chroot/home/azcompu1/azcomputing.co/html/XXXXX/easypopulate_4_import.php on line 1112

---

Quote:

---

Originally Posted by AZComp

Yes on the first page of this post , that seemed to advance past this line and on to the next!

---

So I updated one of the branches that I am working on, but the specific code changes (line numbers do not agree with the ZC version) are provided at this commit

Quote:

---

Originally Posted by AZComp

I fixed several errors by using the code you gave, now I get a different error...

---

Comment out line 1112 by adding

Code:

---

//

---

at the beginning of the line then remove that same comment from line 1110 (2 lines above).


Text you are looking for is at line 1112:

Code:

---

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

---

I'll come up with a better solution than that later, but let's get you going. :)

Thank you for all of your help! One more strlen edit and im working, imported 6000 items!

I do get the following errors, and it is missing about 80 lines of products

Quote:

---

File Import Completed.
Warning An SQL error has occured. Please check your input data for tabs within fields and delete these. If this error continues, please forward your error log to the Easy Populate maintainer

---

Quote:

---

[22-Apr-2016 20:34:32 UTC] PHP Warning: mysqli_fetch_array() expects parameter 1 to be mysqli_result, boolean given in /chroot/home/azcompu1/azcomputing.co/html/xxxxxxx/easypopulate_4_import.php on line 765
[22-Apr-2016 20:34:32 UTC] PHP Warning: mysqli_num_rows() expects parameter 1 to be mysqli_result, boolean given in /chroot/home/azcompu1/azcomputing.co/html/xxxxxxx/easypopulate_4_import.php on line 1470

---

Quote:

---

Originally Posted by AZComp

I do get the following errors, and it is missing about 80 lines of products

---

Sorry I didn't see this earlier (last message I had received was the one before this because I had not visited the site between posting of the two recent messages).

Actually the error log that is discussed in that window is the debug.txt file that is now included in your list of files when accessing the admin panel for EP4...

This is most likely a result of data existing in the file that is not "escaped"... Be nice to see what is in that log to understand what was returned to cause this error so that it can be prevented in the future.

Another thing, very minor in nature. When posting code content for example, in the future could you please use the # button instead of the quote (balloon) button? When replying to the above messages the content has been removed, and from past experience, if I try to copy and paste directly from the screen with my current device, it adds a hashtag for each space. Long story short, it would make directly referencing a piece of provided information easier if the code button (#) were used instead. :)

After successfully getting our store online and using easy populate for a good number of years, we had done some core upgrades and got away from using it in 2008. We are now needing to do mass updating to most of our products and we have installed the newest version on our 1.5.4 store as it was packaged.

As a result of our SEO reports we are finding that we not only need to edit product titles but we also need to edit model numbers and descriptions. We noticed that there is the ability to export using our products_ID as the primary key. When selecting just that and exporting various data, what is missing from each of them is the V_products_ID column.

We added products_ID to the custom export field and we are now getting that Collumn in our exports.

However, after editing a couple of products for title name and model number and attempting a test import, the import results in zero products being updated. If we change the primary key back to model number and edit and import, Then the import updates products successfully, however, if we change the model number it creates the product as a new product and duplicates it in our product database.

We now understand that if the primary key is the model number and the model number is changed it will result in a new product being created. Is there something I am missing in the configuration set up or is this a bug that the products_ID export does not import?

Thank you for any time and consideration to this issue…

Side note: we are not getting any errors displayed when trying to import the file that was exported with the products_ID column. Additionally the few changes that we did make did not increase the length of the title or model numbers.

What is the filename of the exported file and the then imported file? What was the method of "testing" the changes?

The name of the file exported was: Full-EP2016Apr27-145307 and we tried an import using the same name as we uploaded and as Full-EP2016Apr27-145307-import

Our attempt to test was simply to attempt a successful upload. No other testing method implemented.

Sorry... our attempt to test was to attempt a successful IMPORT, not upload.

Quote:

---

Originally Posted by Carbonless

Sorry... our attempt to test test was to attempt a successful IMPORT, not upload.

---

Glad you provided that correction, because I was just about to comment on the difference between the upload and import (other versions don't seem to have that "two" step process or it is not understood the difference.

Glad to know that part, but how do you "know" that no changes were made to anything after the import was what I was trying to get at..

As to the "setup", well I consider this new feature potentially hazardous to the "unknowing" and so I did include a little bit of "difficulty" to set it up at least as I have just taken a lap through the code... That being, to export with the products_id included one needs to currently add it to the user defined fields list. For import, the v_products_id field must be present and the admin configuration switch should be set to something other v_product_model... Capitalization does count, so above where V_products_ID was typed, that would be an incorrect field name for the purposes of the code.

Also were the "number" of columns modified between the export and import? (ie. columns removed?)

My steps:
Import/Export Primary Key: products_id
Added:

User Defined Products Fields

products_id

Exported file
Changed ONLY the Product name of 2 items and modified the model names of the same 2 products.
Saved file
uploaded
clicked import

Result:
Finished Processing Import File

Updated records: 0
New Imported records: 0
Errors Detected: 0
Warnings Detected: 0
Memory Usage: 21087176
Memory Peak: 23515400
Execution Time: 0 seconds.

Verified against the actual products online with no changes.

I did verify that "For import, the v_products_id field must be present and the admin configuration switch should be set to something other v_product_model"

Any other item I'm missing?

I just ran an export with user defined field products_id in the admin-configuration (although was using version 4.0.34 not 4.0.34.a), then added three characters to the end of one of my test products, then with the primary key set to products_id, imported the file, every product showed as "updated" (even though technically nothing was to change except for the three characters added to the product name), and when I went to the store, the three characters were added to the product's name as expected...

Let me try modifying the product_model information of my test product to see what happens and if that is somehow associated... It was my expectation that this process would allow modification of the products_model field because that field would no longer be a primary field of concern...

Thank you for your time and feedback. May have to do a reinstall. I'll await your test result.

Okay, so it does appear that the products_model record for some reason is not getting updated, but other related information does... Need to chase that down because someone else that had requested the capability to import by products_id didn't mention this "issue" otherwise it wouldn't be one...

Here are the results of me importing the test products that were exported from my test category (single category only rather than the entire file) where the only change between export and import was the products_model for "model" 277 was to add three characters.:

Quote:

---

Filename: Full-EP2016Apr27-192924.csv

UPDATED! - Model: 275 | prod_attr | 1 | | Test Multi | Trying to | | | | | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 0 | | 2016-03-18 | 10000 | | Test attri | --none-- | 1 | 0 | 0 | 0 | 0 | 0 | | | |
UPDATED! - Model: 276 | test_singl | 1 | | Test Attri | This produ | | | | | 15 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | | 2016-03-28 | 100 | | Test attri | --none-- | 1 | 0 | 0 | 0 | 0 | 0 | | | |
UPDATED! - Model: 277 | test_singl | 1 | Rdog1.jpg | Test Attri | This produ | | | | | 15 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | | 2016-04-01 | 100 | | Test attri | --none-- | 1 | 0 | 0 | 0 | 0 | 0 | | | |
UPDATED! - Model: 278 | test_doubl | 1 | | Test Attri | This produ | | | | | 16 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | | 2016-04-06 | 99 | | Test attri | --none-- | 1 | 0 | 0 | 0 | 0 | 0 | | | |
UPDATED! - Model: 279 | test_tripl | 1 | | Test Attri | This produ | | | | | 17 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | | 2016-04-06 | 100 | | Test attri | --none-- | 1 | 0 | 0 | 0 | 0 | 0 | | | |
UPDATED! - Model: 280 | add_attrib | 1 | | test add a | This is he | | | | | 25 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | | 2016-04-13 | 5 | | Test attri | --none-- | 1 | 0 | 0 | 0 | 0 | 0 | | | |

Finished Processing Import File

Updated records: 6
New Imported records: 0
Errors Detected: 0
Warnings Detected: 0
Memory Usage: 785064
Memory Peak: 1302016
Execution Time: 0 seconds.

---

What is being used to modify the file/store it as a CSV?

To confirm, you have the primary key set as products_id and have it entered in the User defined products field?

here is my configuration
Title Value Action Uploads Directory EPtemp/
Uploads Directory Admin/Catalog true Info
Import/Export Primary Key products_id Info
Upload File Date Format m-d-y Info
Default Raw Time 09:00:00 Info
Upload/Download Prices Include Tax false Info
Verbose Feedback true Info
Show all EP4 Filetypes with Files true Info
Replace Blank Image false Info
Make Zero Qty Products Inactive false Info
Smart Tags Replacement of Newlines true Info
Advanced Smart Tags false Info
Debug Logging true Info
Maximum Quantity Discounts 3 Info
Split On Number of Records 2000 Info
Script Execution Time 60 Info
Convert Curly Quotes, etc. 0 Info
Convert Character 0x92 1 Info
Enable Products Meta Data 1 Info
Enable Products Music Data 0 Info
User Defined Products Fields products_id Info
Export URI with Prod and or Cat 0

I downloaded a new file. I edited one product title by 5 characters.
removed, other than header line, all other unedited lines, saved the file with one record in it, uploaded and imported
the result was the same
Import Results

Filename: Full-EP2016Apr27-184246.csv

Finished Processing Import File

Updated records: 0
New Imported records: 0
Errors Detected: 0
Warnings Detected: 0
Memory Usage: 4867608
Memory Peak: 5363688
Execution Time: 0 seconds.

Huh.. Go figure.. Can add a new product with a new model number, but it looks like the products_model field for "updating" didn't get incorporated in the update section... (looking strictly at the code) even though I have it (products_model) included as a user defined field.

So, in this case? (until I get it fixed as part of my very soon to be released 4.0.35 as I want to test the few changes I made), one would need to or could, duplicate the product information in the import file, while importing by products_id such that the first occurrence deletes the product (status 9), the second occurrence with the same products_id reloads it... But, *shucks* I guess there is a downside to that as if there are attributes and other data "dependent" on the products_id, then they may get removed/reshuffled as well... Okay, should have a fix momentarily for the UPDATE of the products_model when using products_id or blank_new as the import option.. You should still be getting a report of updated product though or some sort of error that either the primary key doesn't exist or there is a problem with the remaining data...

Thank you for pointing out this issue... It's a shame, I guess the update portion hadn't been fully flushed out because the insert works fine... Maybe the priorities on the project changed, I can't recall..

Quote:

---

Originally Posted by Carbonless

To confirm, you have the primary key set as products_id and have it entered in the User defined products field?

here is my configuration
Title Value Action Uploads Directory EPtemp/
Uploads Directory Admin/Catalog true Info
Import/Export Primary Key products_id Info
Upload File Date Format m-d-y Info
Default Raw Time 09:00:00 Info
Upload/Download Prices Include Tax false Info
Verbose Feedback true Info
Show all EP4 Filetypes with Files true Info
Replace Blank Image false Info
Make Zero Qty Products Inactive false Info
Smart Tags Replacement of Newlines true Info
Advanced Smart Tags false Info
Debug Logging true Info
Maximum Quantity Discounts 3 Info
Split On Number of Records 2000 Info
Script Execution Time 60 Info
Convert Curly Quotes, etc. 0 Info
Convert Character 0x92 1 Info
Enable Products Meta Data 1 Info
Enable Products Music Data 0 Info
User Defined Products Fields products_id Info
Export URI with Prod and or Cat 0

---

Would say similar:

Quote:

---

Uploads Directory secret_folder_with_no_end_slash
Uploads Directory Admin/Catalog true Info
Import/Export Primary Key products_id Info
Upload File Date Format m-d-y Info
Default Raw Time 09:00:00 Info
Upload/Download Prices Include Tax false Info
Verbose Feedback true Info
Show all EP4 Filetypes with Files true Info
Replace Blank Image false Info
Make Zero Qty Products Inactive false Info
Smart Tags Replacement of Newlines true Info
Advanced Smart Tags false Info
Debug Logging true Info
Maximum Quantity Discounts 3 Info
Split On Number of Records 2000 Info
Script Execution Time 60 Info
Convert Curly Quotes, etc. 0 Info
Convert Character 0x92 1 Info
Enable Products Meta Data 1 Info
Enable Products Music Data 0 Info
User Defined Products Fields products_id Info
Export URI with Prod and or Cat 0 Info

---

Believe there is still an open question. What is being used to edit the csv file/save it?

If you in fact open the file with a plain text editor does it look correct? (typically quotes around each set of text, that is then separated by a comma, with some form of carriage return at the end of each line.)

Thank you. I will test first thing in the morning.... Using OpenOffice as per suggested!
Thank you for your well used time.

FWIW, I also changed the stored folder name for files to include a / at the end of it, reperformed import with same/similar results as previously reported...

Found and fixed the issue(s) with updating while not using products_model as the primary key. Haven't uploaded the fix quite yet, but will be up soon. Want to also check some of the changes made to the featured products area to address some previously pointed out issues.

Not yet sure about the 0 products updated issue... please check for any log errors in the logs directory...

Great news. I eagerly await your upgrade. Thank you for the time and attention to my request and giving great support.

Quote:

---

Originally Posted by Carbonless

Great news. I eagerly await your upgrade. Thank you for the time and attention to my request and giving great support.

---

While I did notice a minor difference in the provided code and what was on my test site, I hope that it is the smoking gun for why import with product_id as the primary key was an issue. I also was trying to think back on why the problem existed here versus previous testing and development and it appears that in the spanse of local git work that the corrections may have existed on another branch or were incorporated specifically for the requestor and didn't make its way into a specific branch. :/ If nothing else, a reason to identify an issue when discovered rather than walking away. :) Thank you for identifying the issue and working with me to resolve. Of course proof to be seen.

I would have applied the changes to my 4.0.35 path, but I was going to apply it to the changes to improve the featured import. When I went to test the modifications to the featured import at least on ZC 1.5.5, I noticed that featured product control treats dates of 0001-01-01 as a date in 2036, so I need to look into that operation from the ZC side. But, once I get back to my computer I will apply the change of this discussion directly to the master for the branch and deal with the featured issues separately.