Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
shrimp-gumbo-mmmhhh
MC12345678 .... seems like you mentioned to me somewhere that this EZ4.0 could load attributes.... can it also load attribute pictures?
It can load the *path* to the pictures, but pictures are not "loaded" to the store via EP4. The detailed attributes import file would be used to identify to the store the path to use to identify the attribute picture(s).
Quote:
Originally Posted by
shrimp-gumbo-mmmhhh
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!
Certainly possible, though also may make it difficult to track down which category/categories need "updating". I mean, ideally, before uploading a file that would generate a category that category would actually already be fully identified and either ready for upload or already fully exist. Some don't even use the category picture(s) so that feature may not be of significant value to those. That said, I'll look to see what options are or can be made available at that point in the code to support that possibility if desired.
Quote:
Originally Posted by
shrimp-gumbo-mmmhhh
Sorry, I forgot that ZC attributes don't have pictures.... I guess I am thinking of a mod I saw?
Quote:
Originally Posted by
DrByte
Definitely with DrByte on this one. Not sure where or what led to disbelieving that attributes can have images. Certainly there are possibly issues with templates and/or configurations, presence of images where the path expects, problems in one's includes/configure.php file, etc... but the system supports their existence.
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
mc12345678
It can load the *path* to the pictures, but pictures are not "loaded" to the store via EP4. The detailed attributes import file would be used to identify to the store the path to use to identify the attribute picture(s).
Certainly possible, though also may make it difficult to track down which category/categories need "updating". I mean, ideally, before uploading a file that would generate a category that category would actually already be fully identified and either ready for upload or already fully exist. Some don't even use the category picture(s) so that feature may not be of significant value to those. That said, I'll look to see what options are or can be made available at that point in the code to support that possibility if desired.
Definitely with DrByte on this one. Not sure where or what led to disbelieving that attributes can have images. Certainly there are possibly issues with templates and/or configurations, presence of images where the path expects, problems in one's includes/configure.php file, etc... but the system supports their existence.
Great news! I understand what you are saying between load and point to....
My live site which is 1.5.7c actually does not have the swatch image available option..... I do see this option in my new test site though.
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
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.
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.
Re: EasyPopulate 4.0 Support Thread
If those items are already in the database it will just update them....
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
shrimp-gumbo-mmmhhh
If those items are already in the database it will just update them....
But I'm using a v_status of 9, shouldn't that delete them?
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
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:
1. 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)
2. 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:
Code:
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):
Code:
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.
Re: EasyPopulate 4.0 Support Thread
That's a lot of digging, thanks! I'm not comfortable testing the untested code on this live site. But I do understand the problem much better. I'll get back with my client with some options for him. I'll try again to convince him to use Model Numbers.
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
jeking
That's a lot of digging, thanks! I'm not comfortable testing the untested code on this live site. But I do understand the problem much better. I'll get back with my client with some options for him. I'll try again to convince him to use Model Numbers.
Model number won't specifically resolve the issue and is not specific to causing the observed response(s).
Does the store perhaps use products_sku and applied a suggested implementation that was posted earlier in this thread? Basically, if search for EP4_DB_FILTER_KEY to see if it is used outside of the core files in the root of the admin, the extra_functions folder of the admin and/or the admin's modules folder.
Note for others, the plan is/was that if an alternate filter option were desired/to be used, then it be added to the selection list in the configuration menu. The earlier "add-on" was just that, an additional set of code to show that it could be possible and how it might be implemented.
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
mc12345678
Model number won't specifically resolve the issue and is not specific to causing the observed response(s).
Does the store perhaps use products_sku and applied a suggested implementation that was posted earlier in this thread? Basically, if search for EP4_DB_FILTER_KEY to see if it is used outside of the core files in the root of the admin, the extra_functions folder of the admin and/or the admin's modules folder.
Note for others, the plan is/was that if an alternate filter option were desired/to be used, then it be added to the selection list in the configuration menu. The earlier "add-on" was just that, an additional set of code to show that it could be possible and how it might be implemented.
The store does not use EP4_DB_FILTER_KEY nor products_sku. I appreciate the suggestions though. I'll remove them manually again.
Re: EasyPopulate 4.0 Support Thread
Long story behind this, but if I were to import into the products table with product_id that were not consecutive, would that be a problem? In other words, I might import product_id 5442, skip 5443, and then next use 5444.
Would Zen Cart have a problem with these gaps in the product_id?
