jeking:
I'm back, my client made the same mistake in importing so I have the same problem.
This time I am using version: Easy Populate 4.0.37.12 - 12-24-2020'
"Import/Export Primary Key" is set to products_id
I'm importing a csv file with just one row. Only difference is the v_products_id is now 326004
When I import, this is the result:
Import Results
Filename: Full-EP20-Book1.csv
Finished Processing Import File
Updated records: 0
New Imported records: 0
Errors Detected: 0
Warnings Detected: 0
Memory Usage: 50819040
Memory Peak: 87319616
Execution Time: 0 seconds.
Even though no error was mentioned, I checked anyway and found no error log.
So as you can tell I'm trying to get to a point to release a new version here in Zen Cart. Unfortunate "history" is that I began a "sub-version" by increasing the wrong version identifier (.37). At any rate, here is what I've found.
The attempt to delete a product will not execute if:
- obvious: The identifier from within the main key doesn't exist anywhere in the database (E.g. products_id = 5001 but there is no record with products_id = 5001)
- Less obvious and not so sure that was intentional, looking into it: the item in question is not populated in ALL of the products table, if the products_id is not in the products_to_categories table with a matching/associated categories table record to the record in the products_to_categories table...
Now, how this may have been possible? Well, I had found (testing solution as much as possible) that if I attempted to import product with a v_categories_name_(language_code) instead of the traditional/historic v_categories_name_(language_id) that the product would not be placed how/where it was expected. While I haven't yet uploaded all that I did yesterday to resolve this, I want to make a consistent approach to the operation.
For more "power" users I have/had started to implement a process where it was possible to import with either the language_id (1, 2, 3, etc..) or the language_code (e.g. en, de, es, etc...). At a point, I realized the possibility that someone may import with one but not the other, or "worse" import with both fields populated... So I created a "preference" option (language_id or language_code) such that if both were provided then the method indicated as a preference would be the one that would "dominate". I later discovered though that I had also incorporated that if only one of those fields/columns were included and not the one that was preferred, then the remaining column would cause changes. So... I've added two additional options such that import could/would be limited to the style designated (language_id_only or language_code_only). In this way, regardless the columns present, only the column(s) ending with that designator will be processed.
Now, in this exercise I also found a number of issues with how Zen Cart 1.5.7 "limits" operations... For example, if a product was assigned to categories_id of 0 and not linked elsewhere, then it was extremely difficult to relocate it. It couldn't be moved (Move said something about not placing it in the same place that it was along with some other information). The products link manager identified that it didn't have a master category set, but then wouldn't offer/allow any other category to be set because it seems that it wasn't yet linked to anything else (sort of defeats the purpose of using the link manager if can't establish another link). I think what I ended up doing was copying the product as a linked product and placed it in some other category (that didn't have sub-categories) and then went through one or another process to delete the product from the top category (categories_id of 0).
Now as far as the data indicating 0 action performed for all rows, the "primary" issue that might cause that report is that the desired/expected primary key field is empty in such a way that no action is to be taken (e.g. not set to blank_new and a delete action isn't performed or there isn't sufficient fields to encourage/do anything) with the secondary being as commented out in the code that in some way the associated category may not be found. I found on my test site that I too was having difficulty using any other primary key than products_model. For me I found the reason was that I had hard coded the primary key (EP4_DB_FILTER_KEY) in admin/includes/extra_configures to be something not in the standard list and without an observer to handle it.
So, what to do? There's options... Possibly the "easiest" assuming that action is quickly taken is to assign a products_id, categories_id into products_to_categories that points to a category that exists for the products_id in question. Alternatively the sql query in admin/easypopulate_4_import.php at/around lines 256-258 be changed from/to something like:
from:
TABLE_PRODUCTS . ' as p, ' .
TABLE_PRODUCTS_TO_CATEGORIES . ' as ptoc,' .
TABLE_CATEGORIES . ' as subc ';
$zco_notifier->notify('EP4_IMPORT_PRODUCT_DEFAULT_SELECT_TABLES');
$sql .= "WHERE
p.products_id = ptoc.products_id AND
ptoc.categories_id = subc.categories_id AND ";
to (untested):
TABLE_PRODUCTS . ' as p LEFT JOIN ' .
TABLE_PRODUCTS_TO_CATEGORIES . ' as ptoc ON (p.products_id = ptoc.products_id) LEFT JOIN ' .
TABLE_CATEGORIES . ' as subc ON (ptoc.categories_id = subc.categories_id) ';
$zco_notifier->notify('EP4_IMPORT_PRODUCT_DEFAULT_SELECT_TABLES');
$sql .= "WHERE ";
In this way, if there is/was a database problem with the other tables, if the item appeared in the products list, then it would at least be identified as being in the database. Note that commas in particular places have been removed, that additional text has been added as well (along with appropriate spacing to prevent text incorrectly being joined together and to remove constraints in the WHERE to ensure a satisfactory LEFT JOIN. I don't yet know what/if any other issues might result from this query change where information will be collected about product that do not have a matching or do not have an appropriate category.
Note also, that the upcoming version update is being tested on PHP 8.0 and updated where necessary to address the associated additional strictness.
