EasyPopulate 4.0 Support Thread

[mc12345678]

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.

[nicksab]

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

[mc12345678]

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.

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

[mc12345678]

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.

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.