Easy Populate 1.2.5.4 support

[shrimp-gumbo-mmmhhh]

This error was caused by server memory limit problem. there is nothing wrong with easy populate CSV and new version of zencart

Be sure and change your admin directory to something other than "admin". I am sure those looking to hack our sites are checking out the information we post .... directory and such. Maybe you have coded over some words... but with the information in the other part.... it doesn't look like it....

[shrimp-gumbo-mmmhhh]

This plugin is no longer able to support the latest version of zencart
Can you upgrade this plugin?

It works fine for me on 157c with php 8.0.3.... maybe you need to post what issues you are having.

[shrimp-gumbo-mmmhhh]

If anyone is the caretaker of this wonderful tool.... I have an issue that just popped up for me. My item name in the file was larger than 64 chars.... It populated in the products table but not the products_description table. So the category showed 1 product but I could not see it. It would be great if you could add some checks to see if any of the data is too long for the database objects to accept and then not process them but put those records into a separate file so they can be worked with.

Thank you!

[shrimp-gumbo-mmmhhh]

If anyone is the caretaker of this wonderful tool.... I have an issue that just popped up for me. My item name in the file was larger than 64 chars.... It populated in the products table but not the products_description table. So the category showed 1 product but I could not see it. It would be great if you could add some checks to see if any of the data is too long for the database objects to accept and then not process them but put those records into a separate file so they can be worked with.

Thank you!

Here is another issue that might want to be looked at: products_price is treated like a character field and cannot accept "$" before the amount. Still works but this gave me a problem at first... had to remove "$"


INSERT INTO products SET products_model = 'SKU501', products_type = 1, products_price = '$72.00 ',

[shrimp-gumbo-mmmhhh]

Here is another issue that might want to be looked at: products_price is treated like a character field and cannot accept "$" before the amount. Still works but this gave me a problem at first... had to remove "$"

INSERT INTO products SET products_model = 'SKU501', products_type = 1, products_price = '$72.00 ',

Okay, here are some other issues I believe I found with this module.... runs great but has some things you might need to clean up to get in:

1) I had measurements (26 13/16") in the metatags_description and the sql failed with error 1366: Incorrect String value
2) I had measurements in the products_description field and they failed if there was only one (") in the enclosed field..... if there were 2(") it seemed to load.

Maybe it needs code to clean up for quotes in strings?


3) I got a bunch of these "SKIPPED! - v_products_model: SHU018 Woodchuck | Woodchuck - specials price higher than normal price..." but the field value for both came from the same place so they were actually the same.... but this error showed up a lot.

[mc12345678]

It works fine for me on 157c with php 8.0.3.... maybe you need to post what issues you are having.

If anyone is the caretaker of this wonderful tool.... I have an issue that just popped up for me. My item name in the file was larger than 64 chars.... It populated in the products table but not the products_description table. So the category showed 1 product but I could not see it. It would be great if you could add some checks to see if any of the data is too long for the database objects to accept and then not process them but put those records into a separate file so they can be worked with.

Thank you!

Here is another issue that might want to be looked at: products_price is treated like a character field and cannot accept "$" before the amount. Still works but this gave me a problem at first... had to remove "$"


INSERT INTO products SET products_model = 'SKU501', products_type = 1, products_price = '$72.00 ',

Okay, here are some other issues I believe I found with this module.... runs great but has some things you might need to clean up to get in:

1) I had measurements (26 13/16") in the metatags_description and the sql failed with error 1366: Incorrect String value
2) I had measurements in the products_description field and they failed if there was only one (") in the enclosed field..... if there were 2(") it seemed to load.

Maybe it needs code to clean up for quotes in strings?


3) I got a bunch of these "SKIPPED! - v_products_model: SHU018 Woodchuck | Woodchuck - specials price higher than normal price..." but the field value for both came from the same place so they were actually the same.... but this error showed up a lot.

Having seen you post the list of plugins installed to your system, the one associated with mass product import is not the same plugin as discussed in this thread. The issues experienced are generally easy to correct when the csv file is properly created and/or escaped. For example, consider this situation:
The file processor (which is a php process) is looking for a double quote to indicate the start of a new field with a matching quote at the end of the field. But, somewhere between the two is a standard quote... without that inner quote identified as just text to be part of the grouping, then an error tends to be generated because after that "extra" quote, there isn't a field separator. This causes "confusion" to php basically and results in an error in that line. So the next line is then attempted... one fix is to escape that "inner" quote. This is done by using the backslash before a quote that is to be shown as text. That backslash looks like: \ so that an escaped quote would be \". Another way is to use the html equivalent of a quote: &quote;. A third thought/consideration though I'm not at a computer to test is that when saving the csv file that text fields get an extra quote added to them. This is an option when saving the CSV file from within open Office if using that software.

The specials prices issue, well, a determination is made when importing prices associated with specials. The determination is to evaluate the price being imported against the resulting price of applying the special. The point of the special is generally to provide a price that is "better" than the product's price. If the special price is higher than the standard price, why would that be considered a "special" in a properly managed site? If the special and the product price were the same, why would *that* be considered a special? While the Zen Cart store allows these conditions, the version of bulk product software you have reported using prevents it. Considering that normally such a situation would exist/occur for a limited number of product, it should be something easily/quickly corrected through manual operation.

Now I say that, the comment was that they both came from the same place... that is not very descriptive which is why I provided the above general description of expectations. Might there be an issue in the code? Maybe, but I don't have enough information to say that there is/is not a problem with the code so would need more information and preferably at the thread associated with the plugin you are using. The thread path should be in the plugins documentation.

[shrimp-gumbo-mmmhhh]

Having seen you post the list of plugins installed to your system, the one associated with mass product import is not the same plugin as discussed in this thread. The issues experienced are generally easy to correct when the csv file is properly created and/or escaped. For example, consider this situation:
The file processor (which is a php process) is looking for a double quote to indicate the start of a new field with a matching quote at the end of the field. But, somewhere between the two is a standard quote... without that inner quote identified as just text to be part of the grouping, then an error tends to be generated because after that "extra" quote, there isn't a field separator. This causes "confusion" to php basically and results in an error in that line. So the next line is then attempted... one fix is to escape that "inner" quote. This is done by using the backslash before a quote that is to be shown as text. That backslash looks like: \ so that an escaped quote would be \". Another way is to use the html equivalent of a quote: &quote;. A third thought/consideration though I'm not at a computer to test is that when saving the csv file that text fields get an extra quote added to them. This is an option when saving the CSV file from within open Office if using that software.

The specials prices issue, well, a determination is made when importing prices associated with specials. The determination is to evaluate the price being imported against the resulting price of applying the special. The point of the special is generally to provide a price that is "better" than the product's price. If the special price is higher than the standard price, why would that be considered a "special" in a properly managed site? If the special and the product price were the same, why would *that* be considered a special? While the Zen Cart store allows these conditions, the version of bulk product software you have reported using prevents it. Considering that normally such a situation would exist/occur for a limited number of product, it should be something easily/quickly corrected through manual operation.

Now I say that, the comment was that they both came from the same place... that is not very descriptive which is why I provided the above general description of expectations. Might there be an issue in the code? Maybe, but I don't have enough information to say that there is/is not a problem with the code so would need more information and preferably at the thread associated with the plugin you are using. The thread path should be in the plugins documentation.

Thank you for looking into this MC! I apologize for not being clearer. When I said that the value came from the same place I was meaning that when I built the datafeed I used the product.price for the price and for the special price so that they were exactly the same.... so something got messed up somewhere for it to say that the specials price was more than the products price. Could the holding values or fields differ in some way so that one had higher precision? Not sure why it happened. I will try using null for the special price and see if that clears up this one error.

[mc12345678]

Thank you for looking into this MC! I apologize for not being clearer. When I said that the value came from the same place I was meaning that when I built the datafeed I used the product.price for the price and for the special price so that they were exactly the same.... so something got messed up somewhere for it to say that the specials price was more than the products price. Could the holding values or fields differ in some way so that one had higher precision? Not sure why it happened. I will try using null for the special price and see if that clears up this one error.

Still the wrong forum, but based on the report of what information was entered, I can confirm that the message received is specifically because the "specials" price entered was greater than or equal to the product price... Could the words be better or different? Perhaps. I almost question the existence of the "restriction". I mean, a store may want to operate where they mark a product as a "special" even if there is no change in price... why should the software offer that restriction at all times? At any rate, that's why there was a "note" about that portion of the import. If everything else was reported as ok, then that other data should have been fine with just this special affected. As I see it there are basically three possible solutions. 1) change the wording response so it says greater than or equal 2) Change the test to only be concerned with values grater than, not reporting an issue if the special price is the same as the products price, 3) remove the test/check as a part of the routine code.

[shrimp-gumbo-mmmhhh]

Still the wrong forum, but based on the report of what information was entered, I can confirm that the message received is specifically because the "specials" price entered was greater than or equal to the product price... Could the words be better or different? Perhaps. I almost question the existence of the "restriction". I mean, a store may want to operate where they mark a product as a "special" even if there is no change in price... why should the software offer that restriction at all times? At any rate, that's why there was a "note" about that portion of the import. If everything else was reported as ok, then that other data should have been fine with just this special affected. As I see it there are basically three possible solutions. 1) change the wording response so it says greater than or equal 2) Change the test to only be concerned with values grater than, not reporting an issue if the special price is the same as the products price, 3) remove the test/check as a part of the routine code.

Sorry, will find correct forum for future bugs of other version.

[pixelpadre]

Today I spent 6 hours trying to make easypopulate 4 working.....Fail

SO I found easypopulate csv......another fail....sql patch in admin fail, and importing .sql in myphpadmin file failed with "column count wrong" error.

I could have populated my site in less time that I wasted trying to debug these plugins.