Easy Populate 1.2.5.4 support

salvo72:

hi
i use the plugin on zencart 154

but i cant download and create the examples csv file

to click this the website go in blankpage

thanks
In any recent version of Zen Cart, a blank screen has an accompanying myDebug-xxxx log file in the logs directory. That said, more than likely the software of this version has not been updated to support newer PHP versions and requires some work/effort to bring it up-to-date. There are other options available if unable to address/fix the problems. Out of respect for this thread and software I don't wish to post those other options here as there may be those that will fix this when the issues are identified...

vandiermen:

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

jiji2018:

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.

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.

shrimp-gumbo-mmmhhh:

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:

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:

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;

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.

mc12345678:

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;

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

shrimp-gumbo-mmmhhh:

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.

mc12345678:

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.

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.

I added a simple description field on the product detail page, how to add this field to the batch table function.
Which places need to be modified?

got this installed and downloaded my products, now im trying to make the data match whats expected by zen on the suppliers website and im not sure what "v_product_type" would be refering to so i can pick the corresponding data field to map with the "v_products_type" everything else seems obvious.

flappingfish:

got this installed and downloaded my products, now im trying to make the data match whats expected by zen on the suppliers website and im not sure what "v_product_type" would be refering to so i can pick the corresponding data field to map with the "v_products_type" everything else seems obvious.
Not sure if the above post was made to the correct thread, but the products_type field is associated with things such as if this is a product - general, a product - music, document - general, document - product, product - free shipping, etc... The number that corresponds to the products_type can be found by accessing your store's admin, navigating to a category that has no sub-categories and also doesn't restrict the addition of product to a specific product type, then viewing the page source (F12 on your keyboard). You should be able to navigate/find the dropdown menu associated with new product. The value="" portion of the dropdown list item corresponds with the products_type. So, in a default store you should see that value="1" for product - general...