EasyPopulate 4.0 Support Thread

[jeking]

I have a question about deleting products. My client does not use model numbers, so I've got the "Import/Export Primary Key" set to "blank_new".

In my csv:
v_products_model is left empty
v_products_id is 326001
v_status is 9

When importing this file, I get: NOT FOUND! - Model: 326001 - cant delete...

I tried setting "Import/Export Primary Key" to "products_id" and got the same thing.

I don't understand why it doesn't delete the product with 326001 as the id. I did confirm the product exists by looking in the database.

[mc12345678]

I have a question about deleting products. My client does not use model numbers, so I've got the "Import/Export Primary Key" set to "blank_new".

In my csv:
v_products_model is left empty
v_products_id is 326001
v_status is 9

When importing this file, I get: NOT FOUND! - Model: 326001 - cant delete...

I tried setting "Import/Export Primary Key" to "products_id" and got the same thing.

I don't understand why it doesn't delete the product with 326001 as the id. I did confirm the product exists by looking in the database.

Good question, looks like may need some more information. Seems that the code being used may be a little dated, there had been an update to revise the text response to indicate the primary key setting (in this case would expect to see 'v_products_id' instead of - Model). Sure the update is/was in the language files to an extent, but...

So, information that may further help now that I've looked over the current processing "plan".
- Version number (and/or date downloaded) identified with the software?
- Any observer(s) listening to EP4_IMPORT_FILE_EARLY_ROW_PROCESSING that may have modified what could then be the global variable $continueNextRow to be set to a falsey value?
- Is debug logging turned on in the configuration settings? If so (default) then there should be some record in the generated debug .txt log in the EP4 main screen towards the "bottom" of the list of files. That is unless the admin/includes/functions/extra_functions/easypopulate_4_functions.php is old enough (pre Oct 3, 2016) to still have the typo of write_debug_log($string) instead of write_debug_log_4($string).
- Is there more than one product being deleted in the file, and does at least one other product delete successfully (presumably an earlier listed product)? For that matter is there more than one row of data in the file other than the header row?

[jeking]

Good question, looks like may need some more information. Seems that the code being used may be a little dated, there had been an update to revise the text response to indicate the primary key setting (in this case would expect to see 'v_products_id' instead of - Model). Sure the update is/was in the language files to an extent, but...

So, information that may further help now that I've looked over the current processing "plan".
- Version number (and/or date downloaded) identified with the software?
- Any observer(s) listening to EP4_IMPORT_FILE_EARLY_ROW_PROCESSING that may have modified what could then be the global variable $continueNextRow to be set to a falsey value?
- Is debug logging turned on in the configuration settings? If so (default) then there should be some record in the generated debug .txt log in the EP4 main screen towards the "bottom" of the list of files. That is unless the admin/includes/functions/extra_functions/easypopulate_4_functions.php is old enough (pre Oct 3, 2016) to still have the typo of write_debug_log($string) instead of write_debug_log_4($string).
- Is there more than one product being deleted in the file, and does at least one other product delete successfully (presumably an earlier listed product)? For that matter is there more than one row of data in the file other than the header row?

I did see an updated version was available *after* to posted.

Easy Populate 4.0.36.ZC - 07-05-2016
No observers added.
Debug logging is on but the log file is dated 2/2/2021
I only had on product in the file as I was testing before doing them all (200)

I have since deleted the products via phpMyAdmin but will continue testing with test product(s) as needed.

[mc12345678]

I did see an updated version was available *after* to posted.

Easy Populate 4.0.36.ZC - 07-05-2016
No observers added.
Debug logging is on but the log file is dated 2/2/2021
I only had on product in the file as I was testing before doing them all (200)

I have since deleted the products via phpMyAdmin but will continue testing with test product(s) as needed.

Well, on the "used phpMyAdmin" to delete product, understand that EP4 uses the ZC zen_remove_product function which removes *A LOT* of data and even files from the server. Simply removing product from the products table does not clean up the site the same way.

I'll take a look at what that version does/did as far as processing, but I may also suggest looking at the ZC logs folder to see if there was an issue logged there as one of the actions is to unlink photos and while I wouldn't expect that to be a problem in a setup ZC site, it wouldn't be the first time that I've seen a problem crop up because of that even if the operation is prefixed to prevent generating an error.

As for the potential of generating a debug log entry, I rushed in my review. A log entry would only be made if a variable hard coded in admin/easypopulate_4.php had been changed to true. That issue leads me to consider making a change to allow setting that through the configuration menu by adding an option choice to the existing debug logging variable.

My guess for the issue (as still need to look back at that version) is that the remove product code wasn't updated to handle the alternate key. A work around to that would be to temporarily assign a products_model to those product being deleted (using the same blank_new or products_id setting) then change over to products_model and import a file with those product to be deleted and having those temporary products_model values... The model could be the products_id if models are not otherwise being used or have some sort of "prefix"/"suffix" that would ensure uniqueness...

[jeking]

Well, on the "used phpMyAdmin" to delete product, understand that EP4 uses the ZC zen_remove_product function which removes *A LOT* of data and even files from the server. Simply removing product from the products table does not clean up the site the same way.

My guess for the issue (as still need to look back at that version) is that the remove product code wasn't updated to handle the alternate key. A work around to that would be to temporarily assign a products_model to those product being deleted (using the same blank_new or products_id setting) then change over to products_model and import a file with those product to be deleted and having those temporary products_model values... The model could be the products_id if models are not otherwise being used or have some sort of "prefix"/"suffix" that would ensure uniqueness...

I can update to the current version and try again. Your theory makes a lot of sense. I wish my client would use Model Numbers, but that's another story.

"used phpMyAdmin" - yes, and good point. I removed the products from all of the tables in which I found the product_id.

[shrimp-gumbo-mmmhhh]

Maybe you could make model numbers for them and then upload and then update that field to null after that?

[shrimp-gumbo-mmmhhh]

MC12345678 .... seems like you mentioned to me somewhere that this EZ4.0 could load attributes.... can it also load attribute pictures?




I had an interesting thought for a change in the code.... when you first create a category you assign that product's picture to that products category picture.

Thank you!

[shrimp-gumbo-mmmhhh]

MC12345678 .... seems like you mentioned to me somewhere that this EZ4.0 could load attributes.... can it also load attribute pictures?

Sorry, I forgot that ZC attributes don't have pictures.... I guess I am thinking of a mod I saw?

[DrByte]

Sorry, I forgot that ZC attributes don't have pictures

What?
https://docs.zen-cart.com/user/admin...tribute-images

[mc12345678]

I can update to the current version and try again. Your theory makes a lot of sense. I wish my client would use Model Numbers, but that's another story.

"used phpMyAdmin" - yes, and good point. I removed the products from all of the tables in which I found the product_id.

Note, some tables use product_id, some products_id. Again, an operation best left to zen_remove_product.

Also, I got a little wrapped up in the details, but in the making of a products_model for product deletion, if trust that the products_model to be assigned represents a product to be deleted, then all to be deleted could be made the same products_model and then when using the older ZC version, could upload just one product with that same products_model to have it delete. All items with that products_model will be sought and "destroyed".