EasyPopulate 4.0 Support Thread

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

[torvista]

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.