EasyPopulate 4.0 Support Thread

nicksab:

i need help using Easy Populate V4

I am trying copy all my product from one store to another.

Easy populate installation was easy on both store.
I choose Complete product as an export but i am getting an error when trying to upload it to the new store.

The error is and goes for all products:

SKIPPED! - v_products_model: FI66 - No category provided for this new product
SKIPPED! - v_products_model: E8-4812P - No category provided for this new product
SKIPPED! - v_products_model: FI86 - No category provided for this new product
SKIPPED! - v_products_model: FD85 - No category provided for this new product
SKIPPED! - v_products_model: FW89 - No category provided for this new product

However the file has a v_category_name_1 and the new store is entirely blank ( see screenshot)

Any ideas on how to fix this? Thank you for your help

Sigh, let's try this a different way since about the last 5 to 6 pages haven't been read. So the file for input has a category designation that ends with a number. Do you know what that number means or what the significance is about it ending with a number? The number represents the language_id of the language that was exported. Now the program has two features, an import and an export. Each have independent controls. Based on the above description I'm pretty sure I know the cause unless information has been purposely withheld. That said, to learn to fish is better than being fed a fish. So export was fine but having an issue with import. Might there be some configuration settings related to the import that might relate to what is being experienced?

More importantly though.... why are you not using a standard zen Cart process to move and or upgrade the store? Why use any bulk product system to only transfer product to a blank store?

Sorry to make statement in the first paragraph with such tone. The mistake I made in my last upload of the software directly relates to this issue, has been described and discussed multiple times and in my opinion should be something easy to spot as a fix by reading just a few posts. It concerns me when the fix is so simple but takes so much. Yes if I upload a corrected copy it will fix that issue but I'm not really ready because I haven't fixed a separate issue yet that really would need a new version so kind of a waste to issue them in such small groups. Of course instead I talk about it lot... so lose lose in that. Anyways, please do the above homework. Post what you discover or what cannot be found. Glad to help figure things out even if it's something in the instructions. As I said, I took a different approach on trying to address this particular issue of what I expect to be related to my mess up with some settings in my last update.

mc12345678:

Sigh, let's try this a different way since about the last 5 to 6 pages haven't been read. So the file for input has a category designation that ends with a number. Do you know what that number means or what the significance is about it ending with a number? The number represents the language_id of the language that was exported. Now the program has two features, an import and an export. Each have independent controls. Based on the above description I'm pretty sure I know the cause unless information has been purposely withheld. That said, to learn to fish is better than being fed a fish. So export was fine but having an issue with import. Might there be some configuration settings related to the import that might relate to what is being experienced?

More importantly though.... why are you not using a standard zen Cart process to move and or upgrade the store? Why use any bulk product system to only transfer product to a blank store?

Sorry to make statement in the first paragraph with such tone. The mistake I made in my last upload of the software directly relates to this issue, has been described and discussed multiple times and in my opinion should be something easy to spot as a fix by reading just a few posts. It concerns me when the fix is so simple but takes so much. Yes if I upload a corrected copy it will fix that issue but I'm not really ready because I haven't fixed a separate issue yet that really would need a new version so kind of a waste to issue them in such small groups. Of course instead I talk about it lot... so lose lose in that. Anyways, please do the above homework. Post what you discover or what cannot be found. Glad to help figure things out even if it's something in the instructions. As I said, I took a different approach on trying to address this particular issue of what I expect to be related to my mess up with some settings in my last update.

No offense or hard feelings but this is a really long thread ( over 340 pages )to digest and go thru. It is not really easy to understand or read some of it either.

And no I am not witholding any information.

I thought the error " no categories provided" related to the " category_name" not being provided in the csv file.

I do know and saw what the number 1 means and that is related to the language. My site is not multilingual so i don t think that s the issue.

I honestly thought using easy populate would be a cleaner way of upgrading/switching a store. I should probably go back to the standard upgrade process and leave easy populate alone until it is fixed.

Thanks for taking the timeto look over my issue.

nicksab:

No offense or hard feelings but this is a really long thread ( over 340 pages )to digest and go thru. It is not really easy to understand or read some of it either.

And no I am not witholding any information.

I thought the error " no categories provided" related to the " category_name" not being provided in the csv file.

I do know and saw what the number 1 means and that is related to the language. My site is not multilingual so i don t think that s the issue.

I honestly thought using easy populate would be a cleaner way of upgrading/switching a store. I should probably go back to the standard upgrade process and leave easy populate alone until it is fixed.

Thanks for taking the timeto look over my issue.

Well it can be "foxed" by changing a configuration setting... hence why I asked what the import settings were in the configuration menu... add for reading... so in the works would read a thread that is more than 10 years old from the beginning to the end? Especially if using a recent version of the software? Start towards the back and read at most to the last release of it... if the question still can't be answered, then certainly need to ask.

The error did relate to the categories name. Directly so.

mc12345678:

Well it can be "foxed" by changing a configuration setting... hence why I asked what the import settings were in the configuration menu... add for reading... so in the works would read a thread that is more than 10 years old from the beginning to the end? Especially if using a recent version of the software? Start towards the back and read at most to the last release of it... if the question still can't be answered, then certainly need to ask.

The error did relate to the categories name. Directly so.

mc12345678,

I owe you a sincere apology and thank you for pointing me in the right direction.

For anyone facing the same issue, the answer is in post #3294

nicksab:

mc12345678,

I owe you a sincere apology and thank you for pointing me in the right direction.

For anyone facing the same issue, the answer is in post #3294

Well thank you. The issue was though described in a way different than those previously reporting the same type of problem and I know full well how it is always desirable for everything to work with zero additional change or adjustment. I still suggest using the standard zen Cart process to "move" the product though really am more concerned about the customer experience, but hope that you are able to accomplish what is needed.

If you do decide to continue using this to move product and retain product reference for customers or search engines, then there is another configuration switch that I suggest modifying away from default settings on both stores which is to use the Product's ID as the primary key instead of the default products model.

Regarding the import of multiple categories for products, just done a 1000 line import and subsequently discovered errors in the csv that created unwanted categories.

Is there a switch to prevent the creation of new categories/only allow products to be assigned/linked to existing categories?

When I upload a file the column v_categories_name_1 always has a category listed. I've never had a problem with wrong categories. If you have a category for example under men's shoes then sneakers your product category would look like men's shoes^sneakers

I have two languages and in some products the second column for ES had the category name EN so it created those as new categories, as per design.
So if there is no switch to prevent this, I'll add one to prevent this in future.

torvista:

Regarding the import of multiple categories for products, just done a 1000 line import and subsequently discovered errors in the csv that created unwanted categories.

Is there a switch to prevent the creation of new categories/only allow products to be assigned/linked to existing categories?

keith z:

When I upload a file the column v_categories_name_1 always has a category listed. I've never had a problem with wrong categories. If you have a category for example under men's shoes then sneakers your product category would look like men's shoes^sneakers

torvista:

I have two languages and in some products the second column for ES had the category name EN so it created those as new categories, as per design.
So if there is no switch to prevent this, I'll add one to prevent this in future.

Unfortunately, even with the above added information, there are still characteristics that are not identified. For example, did the file itself contain multiple rows that caused the generation of linked product or did the product already exist within the database and the file contained additional rows of data where the category didn't/no longer existed and would become new? There are also considerations to factor in especially with multiple languages such as why was the additional field present to include the new (linked product generating) category?

As has been the case as long as category linking has been incorporated, the control of this has been in the management of the original data. A single column is used as the primary key, having two records in the file that match that primary key offers an opportunity for "undesired" data to be import/modified. Not including the category column would prevent the generation of linked categories though would prevent that file from being used to import new product because of the absence of a category. Could something be added to the file to mark or indicate the need to process or exclude a row, sure. But if editing the file to include or otherwise flag a row to do something special, why have the row in the file to begin with instead of an additional file needed to perform that particular action?

The above is a little bit of an explanation of why such hasn't been previously developed and some of the issues or ways to work around them. Can a switch be added to prevent the generation of linked categories? Yes. So can one to use only the first row of data encountered, the last row, or anywhere in between. That bit of a facetious statement comes from trying to see the benefit and/or how adding such a feature would help others (with minimal further explanation/engagement). I made a mistake already and was concerned that there was an issue with the use of language_code versus language_id; however, the above says that it was all within a given language identifier (language_code), but in this case two languages were included and specifically a single field had data that was not desired to be at least "fully" included/considered. Interested in further understanding the situation so that can figure out incorporation in addition to responding to the items that were recently brought up.

For example, did the file itself contain multiple rows that caused the generation of linked product or did the product already exist within the database and the file contained additional rows of data where the category didn't/no longer existed and would become new?

The products already existed.
The categories already existed.
The import was to link the products to multiple other categories.

The problem-causing rows had the same category name (EN) in both the EN and ES column.
As that EN category-name did not exist in spanish, a new category was created having the same name in both languages.

I mainly use DBIO, which does not have category imports. That uses a command column for optional functionality, like expressly allowing creation or not.

eavinu:

So I am happy to say that finally the Unknown CSV Delimiter issue was solved.
I don't know why I didn't try this before...
At first, since this was an upgraded website and had previous versions of EP (1.2....), there was a temp folder in the root and I left it there, changed in the EP4 configuration to false under Uploads directory Admin/Catalog.
Now I decided to move it to the Admin folder and changed the configuration to True and the Unknown CSV Delimiter indication turned to a "CSV ," indication.

Thank you so much for posting this solution!
I had the same problem ("Unknown CSV Delimiter" error although everything looked good to me) and initial setup.
Luckily I found your post, it would have taken me quite a long time to realize it otherwise, since the error message is quite misleading in this case.

marcopm:

Thank you so much for posting this solution!
I had the same problem ("Unknown CSV Delimiter" error although everything looked good to me) and initial setup.
Luckily I found your post, it would have taken me quite a long time to realize it otherwise, since the error message is quite misleading in this case.

The real fix can be found in this post: https://www.zen-cart.com/showthread.php?190417-EasyPopulate-4-0-Support-Thread&p=1385080#post1385080
Changing the setting to access files off of the admin directory has its benefits, but for some that would mean they would have to provide that path name to another vendor. Again, unfortunately it had been developed to be too protective.

I'm running in to the following error.

I am running ZC1.5.7d and Easy Populate 4.0.37.13 - 05-03-2021.

I just did a fresh install (with some mods for a custom product type). (Had problems with the install until I hit the "Install EP4" link but that's another problem :)).

I managed to get the files to be created however, I tried to import the file that was just created and was thrown this error.

[28-Apr-2022 03:13:10 America/New_York] PHP Fatal error:  Uncaught Error: Call to undefined function mysql_query() in E:\xampp\htdocs\yyyy\easypopulate_4.php:819
Stack trace:
#0 E:\xampp\htdocs\yyyy\index.php(11): require()
#1 {main}
  thrown in E:\xampp\htdocs\yyyy\easypopulate_4.php on line 819

[28-Apr-2022 03:13:10 America/New_York] Request URI: /yyyy/index.php?cmd=easypopulate_4, IP address: 127.0.0.1
--> PHP Fatal error: Uncaught Error: Call to undefined function mysql_query() in E:\xampp\htdocs\yyyy\easypopulate_4.php:819
Stack trace:
#0 E:\xampp\htdocs\yyyy\index.php(11): require()
#1 {main}
  thrown in E:\xampp\htdocs\yyyy\easypopulate_4.php on line 819.

So here's where things get weird... I found the line that was referenced and it's part of a block that is testing for mysql vs. mysqli. For some reason, EP4 isn't seeing that mysqli should be used. (I'm running PHP 7.4.20.) I tried everything at this point... hell, I even tried setting line 62 to always true using:

$ep_uses_mysqli = TRUE;

But... either way, after the page refreshes... the script resets itself to FALSE. (I can tell because I added the following to the "tests" under Configuration Settings on line 717(-ish):

echo "Are you using MySQLi?: " . ($ep_uses_mysqli ? "TRUE" : "FALSE") . '<br />';

Before I try to import a CSV file this line tests TRUE. But afterwards and the page refreshes after an import attempt, this line sets itself to false. I am lost as to why that is or how to fix it. (Again, hardcoding this test to TRUE somehow sets it back to false :/)

Any help would be appreciated.

retched:

:snip:

This attached post can be ignored. Evidently, I copied over code from an older EP4 that was always reverting $ep_uses_mysqli to FALSE. And it override the hard setting. Everything is working swimmingly for now.

retched:

This attached post can be ignored. Evidently, I copied over code from an older EP4 that was always reverting $ep_uses_mysqli to FALSE. And it override the hard setting. Everything is working swimmingly for now.
Glad it has been sorted... I had looked through many portions of code and couldn't find what would have caused it in the above described version...

Easy Populate is working great for me, with the exception of 1 issue. I can not get it to update the metatags_keywords_1 field. I am able to use EP4 to toggle the status (0/1) on the other Metatag fields (v_metatags_products_name_status,v_metatags_title_status) fine. It just seems to be the field where I can enter longer text that is the issue (metatags_keywords_1, metatags_description_1).

We recently upgraded to 1.5.7d and made sure all themes and modules are updated. I am able to manually enter the information for each item, and it does show when I download the store from EP4.

Any thoughts on where to start?

Thanks in advance for any help/thoughts.

Dan

DanMickle:

Easy Populate is working great for me, with the exception of 1 issue. I can not get it to update the metatags_keywords_1 field. I am able to use EP4 to toggle the status (0/1) on the other Metatag fields (v_metatags_products_name_status,v_metatags_title_status) fine. It just seems to be the field where I can enter longer text that is the issue (metatags_keywords_1, metatags_description_1).

We recently upgraded to 1.5.7d and made sure all themes and modules are updated. I am able to manually enter the information for each item, and it does show when I download the store from EP4.

Any thoughts on where to start?

Thanks in advance for any help/thoughts.

Dan

See if the content at or further referenced back in the following post resolves the issue and please post back: https://www.zen-cart.com/newreply.php?do=newreply&p=1381450

I went back through those threads and tried a few changes (language ID/Code, etc.) but they did not resolve the issue. I double-checked to make sure the "use products metadata" was enabled as well.

I did also verify because I thought I may have been mistaken when I first attempted a product update. I am able to update the following correctly (as well as the other standard fields):

v_metatags_products_name_status v_metatags_title_status v_metatags_model_status v_metatags_price_status v_metatags_title_tagline_status

however

v_metatags_title_1 v_metatags_keywords_1 v_metatags_description_1

will not update.

Maybe I am missing something in the past posts, so I am going back through them again. Thank you for taking the time and suggesting the post to start with.

DanMickle:

I went back through those threads and tried a few changes (language ID/Code, etc.) but they did not resolve the issue. I double-checked to make sure the "use products metadata" was enabled as well.

I did also verify because I thought I may have been mistaken when I first attempted a product update. I am able to update the following correctly (as well as the other standard fields):

v_metatags_products_name_status v_metatags_title_status v_metatags_model_status v_metatags_price_status v_metatags_title_tagline_status

however

v_metatags_title_1 v_metatags_keywords_1 v_metatags_description_1

will not update.

Maybe I am missing something in the past posts, so I am going back through them again. Thank you for taking the time and suggesting the post to start with.

To ensure a full understanding, could you please identify the version of EP4 installed and then possibly the configuration settings (don't need to know anything about the path used for the upload/download folder)? Please be specific about identifying the version by its reported value.

Additionally, have you been successful with updating other records that are language based but not Metatag related?

mc12345678:

To ensure a full understanding, could you please identify the version of EP4 installed and then possibly the configuration settings (don't need to know anything about the path used for the upload/download folder)? Please be specific about identifying the version by its reported value.

Additionally, have you been successful with updating other records that are language-based but not Metatag related?

I just tested with a record with two language-based (v_products_name_1) and (v_metatags_keywords_1) fields. The products_name_1 worked and the keywords_1 did not.

We are on versions:

• Easy Populate 4.0.37.13 - 05-03-2021
• Zen Cart 1.5.7d
• PHP 7.4.30 (Zend: 3.4.0)

I have attached screenshots.