EasyPopulate 4.0 Support Thread

gohealth:

Hi,
I'm using the Attrib-Basic-EP file to try and get my attributes loaded. I have used the tool to load a number of products and am now using the Attrib-Basics-EP file I exported as a template to populate (it does have some good entries as my store does have some products with attributes already). Before editing and adding more, I thought I would test the update. The upload of the exported file, unchanged, returned the message:

MySQLi error 1054: Unknown column 'p.products_model' in 'where clause'
When executing:
SELECT * FROM products WHERE (
p.products_model = '1392')

I see the syntax error in that products was not referenced as 'p', but the upload has created the SQL as p.products_model. Is this a bug?

Note, I originally tried this with products_id still the primary key. However, I have changed products_model to be the primary key and still get the same error.

Running ZC 1.5.6c on PHP 7.3

It is a bug resulting from streamlining the code a little where the query operating against a single table did not use a table name alias and reference to the desired field did include the table alias.

In the file admin/easypopulate_4_attrib.php

At line 29, if you change:

$query ="SELECT * FROM ".TABLE_PRODUCTS." WHERE (" . $chosen_key_sql . ")";

To:

$query ="SELECT * FROM ".TABLE_PRODUCTS." p WHERE (" . $chosen_key_sql . ")";

That issue will be addressed for either/both primary key choices.

BTW, thank you for the identification and research performed. Apologies for the discrepancy. I'll be updating github when I get a chance and also search for other queries that might have been generated the same way of using a single table and not using a table alias.

mc12345678:

It is a bug resulting from streamlining the code a little where the query operating against a single table did not use a table name alias and reference to the desired field did include the table alias.
BTW, thank you for the identification and research performed. Apologies for the discrepancy. I'll be updating github when I get a chance and also search for other queries that might have been generated the same way of using a single table and not using a table alias.

Thanks for the update. That makes sense. I made the change and had some further issues that I can't debug. The update didn't complete at all (says 'waiting for website.com...' at bottom left for about a minute then goes to a blank screen on 'admin/easypopulate_4.php' page) so I reverted back my code change in case I stuffed it and ran it again. Same error in the log file regarding the missing reference, but i also noticed the message at the top of the screen "An SQL error has occured. Please check your input data for tabs within fields and delete these. If this error continues, please forward your error log to the Easy Populate maintainer". Noting, that I did a simple "Basic Products Attributes" export, did not touch the file (has just a single model in it) and then did the import. So, not sure there is a TAB in the untouched 'export' file (in other words, I did't add it or allow Excel/Open Office open the file).

Any thoughts? No debug file produced.

Thanks,
Chris

gohealth:

Thanks for the update. That makes sense. I made the change and had some further issues that I can't debug. The update didn't complete at all (says 'waiting for website.com...' at bottom left for about a minute then goes to a blank screen on 'admin/easypopulate_4.php' page) so I reverted back my code change in case I stuffed it and ran it again. Same error in the log file regarding the missing reference, but i also noticed the message at the top of the screen "An SQL error has occured. Please check your input data for tabs within fields and delete these. If this error continues, please forward your error log to the Easy Populate maintainer". Noting, that I did a simple "Basic Products Attributes" export, did not touch the file (has just a single model in it) and then did the import. So, not sure there is a TAB in the untouched 'export' file (in other words, I did't add it or allow Excel/Open Office open the file).

Any thoughts? No debug file produced.

Thanks,
Chris

How many records are supposedly included (that plays a factor in the software timing out after running for a period of time).

The error message about checking for tabs is/was a issue that has been identified as common and is not the cause 100% of the time. In fact, the export/import test is one of the recommended actions in troubleshooting something like this.

Now, as to why the screen went blank, again the size of the file plays a factor, as well any sorts of timeouts set for execution, and then there is also an option attempted to be used by the software to keep processing alive; however, some systems do not support it and the "whitescreen" may still occur.

For actions complete, should be able to review the admin activity log at least in part to see what the last operation was that completed in using this plugin.

Note, it is also possible that the raw data has some issues that may need addressing.

mc12345678:

How many records are supposedly included (that plays a factor in the software timing out after running for a period of time).

Now, as to why the screen went blank, again the size of the file plays a factor, as well any sorts of timeouts set for execution, and then there is also an option attempted to be used by the software to keep processing alive; however, some systems do not support it and the "whitescreen" may still occur.

For actions complete, should be able to review the admin activity log at least in part to see what the last operation was that completed in using this plugin.

Note, it is also possible that the raw data has some issues that may need addressing.

Thanks for the update. Unfortunately, I just have the single row (that was extracted via the export), so don't think it would be a filesize or timeout issue, or an issue with the data as it has come from the export.

Let me do another few tests and see what i can find.

Cheers,
Chris

gohealth:

Thanks for the update. Unfortunately, I just have the single row (that was extracted via the export), so don't think it would be a filesize or timeout issue, or an issue with the data as it has come from the export.

Let me do another few tests and see what i can find.

Cheers,
Chris
Actually, in absence of response I went through and identified the issue(s). I've also made some other updates to improve the basic attribute import operation. I'll be pushing the updates shortly, just need to finish something else within the next 20 minutes or so.

mc12345678:

Actually, in absence of response I went through and identified the issue(s). I've also made some other updates to improve the basic attribute import operation. I'll be pushing the updates shortly, just need to finish something else within the next 20 minutes or so.
I've updated the master branch with the correction to the above identified issue and a few other things identified while reviewing that file. There are certainly additional improvements possible and some more alignment with other existing code that can be done.

Note that the update does change the first option value sort number from what was a 1 to now a 0 when dealing with the basic attribute update. Also, while others hadn't really explained what issue they had with sort orders, but I found that in an update situation that the sort order was only incremented by one instead of by 10 as expected. I have corrected that issue so that when performing a basic attribute upload of existing option values within an option name group that the sort order is incremented by 10 with 0 being the first sort order.

I've also added a few "screen" notifications to try to address a few potential issues (no primary key field included in the upload file for example) that ideally will not occur, but inevitably may... Also added the ability to reassign an option name to a new products_option_type and a few associated modifications.

mc12345678:

I've updated the master branch with the correction to the above identified issue and a few other things identified while reviewing that file. There are certainly additional improvements possible and some more alignment with other existing code that can be done.
Thanks for the quick turn around. I'll try and figure out how to access this branch and the changed files and give it a try. I'm might need to message you to figure out how to get the latest code changes you have made.

Thanks again...

gohealth:

Thanks for the quick turn around. I'll try and figure out how to access this branch and the changed files and give it a try. I'm might need to message you to figure out how to get the latest code changes you have made.

Thanks again...

Https://github.com/mc12345678/easypopulate-4.0 should take you to the master branch. From there, on the right side of the screen is a green button allowing download of the zip file which includes all of the latest updates. While to fix this issue I only modified the admin/easypopulate_4_attrib.php file, there may have been a few updates included that I had not yet pushed.

I appreciate the feedback. Sometimes don't know a problem exists until someone says something.

Trying to import some attributes and it's not working, how could I spit out the SQL to try to manually run it? I've tried about 4 of the last build versions...

wolfderby:

Trying to import some attributes and it's not working, how could I spit out the SQL to try to manually run it? I've tried about 4 of the last build versions...
As with all issues in the forum, a little more information is always helpful.

In this case, what type of operation with Attributes, what was the filename being used to import, and because there recently were some issues identified with the basic attribute import, has the latest github version been attempted? Also, depending on the exported file, there may be duplicate data that causes expected changes to be overwritten. But deal with that once more info is made available.

wolfderby:

Trying to import some attributes and it's not working, how could I spit out the SQL to try to manually run it? I've tried about 4 of the last build versions...

Fyi, the above was something of a two part question/issue. The first associated with the operation of the code, the second associated with the needed sql...

To the second part, the complexity of attributes to a product involves a number of sql statements and tables. The tables involved are: products, products_attributes, products_attributes_downloads, products_options, products_options_types, products_options_values, and products_options_values_to_products_options. So the addition/modification of attributes can be involved. The code is expected to address/handle these. There are also some other "helper" tables such as the languages table to identify what languages are installed and further support database population.

mc12345678:

As with all issues in the forum, a little more information is always helpful.

In this case, what type of operation with Attributes, what was the filename being used to import, and because there recently were some issues identified with the basic attribute import, has the latest github version been attempted? Also, depending on the exported file, there may be duplicate data that causes expected changes to be overwritten. But deal with that once more info is made available.

Yes I've tried chaddro's and yours. The MC git repo seems to only export 6 products for a basic line import, if I'm recalling correctly. Chaddros' exported all but doesn't see my delimiter for import. Yours seemed runs the import but doesn't actually import the values. I've also tried putting echos and print_r's in the easypopulate_4_attrib.php and I never seem to see them, to the point where I was wondering if the required blocked them, or if cloudflare's caching the file? if I throw an echo in easypopulate_4.php I see it though?

At some point I'd like to upload a table header click and sort for the date I have on one of my versions. (:

Ah snap I think I was just messing up the filename on upload. Forgot the prefix!

wolfderby:

Ah snap I think I was just messing up the filename on upload. Forgot the prefix!
That at least addresses the import (after upload) portion. What again is/was the issue though with export... is there an issue?

So I searched this thread and couldn't find anything on the nose of my issues.

** Imported products display fine, but will not open to product details view when you click on them **

I first created all my store categories.
Then I created some new products
Then exported to get a template
I filled in the template with a bunch of new products
I imported the template

Everything imported fine and reported no errors. I can see the couple hundred items on the back and front ends of the store. When you click on one though it just displays the title of the product instead of going into it. If you click on the Quick view you can see the product and even add to cart but it will not let you view the product any other way.

I had not done attributes yet and thought that might be why they weren't displaying since they are all priced by attributes. But when I assigned attributes, still the same issue. If I create a new product in the back end it opens just fine as it should so it had to be something with the import.

I have compared the products imported with ones I created and no differences when I go into edit them, and I have also tried deleting the attributes and re-assigning, and I've tried disabling the product and re-enabling, still will not open from when you click on the product, only shows the title then the category listings below it.

I'm using ZC 1.5.6c, and Yourstore theme

eric47905:

So I searched this thread and couldn't find anything on the nose of my issues.

** Imported products display fine, but will not open to product details view when you click on them **

I first created all my store categories.
Then I created some new products
Then exported to get a template
I filled in the template with a bunch of new products
I imported the template

Everything imported fine and reported no errors. I can see the couple hundred items on the back and front ends of the store. When you click on one though it just displays the title of the product instead of going into it. If you click on the Quick view you can see the product and even add to cart but it will not let you view the product any other way.

I had not done attributes yet and thought that might be why they weren't displaying since they are all priced by attributes. But when I assigned attributes, still the same issue. If I create a new product in the back end it opens just fine as it should so it had to be something with the import.

I have compared the products imported with ones I created and no differences when I go into edit them, and I have also tried deleting the attributes and re-assigning, and I've tried disabling the product and re-enabling, still will not open from when you click on the product, only shows the title then the category listings below it.

I'm using ZC 1.5.6c, and Yourstore theme

What version of EP4 is being used? What is being used to generate the csv file? Someone has recently identified having a similar issue where the source file contained character codes that did not convert to utf8 properly and content was not being fully populated. Unfortunately I didn't receive the associated files to be able to review/provide direction, but they resolved it by installing Libre (open source spreadsheet program) and ensuring to save their csv file as utf8 before attempting to upload and then import.

Could be other things, but would need to know information related to the above to be able to provide more guidance.

Easy Populate 4.0.37.10 - 02-08-2017 - Using Open Office Calc - I did find out what the issue seems to be from someone though. When I import the file the 2nd column v_products_type is changing form a 1 I have entered in to a zero when I re-download the full products list.

It being a zero appears to be causing you not to be able to open the product and in some cases causing ERR_TOO_MANY_REDIRECTS error page when you try to click on certain categories. One such product I deleted and then the category opens without the redirect error, so I re-uploaded just the one product in a file and it stayed as v_products_type of 1 and works fine now when it previously did not.

So the question appears to be why is the upload changing what I have in the cell from a 1 to a zero when uploaded?

eric47905:

Easy Populate 4.0.37.10 - 02-08-2017 - Using Open Office Calc - I did find out what the issue seems to be from someone though. When I import the file the 2nd column v_products_type is changing form a 1 I have entered in to a zero when I re-download the full products list.

It being a zero appears to be causing you not to be able to open the product and in some cases causing ERR_TOO_MANY_REDIRECTS error page when you try to click on certain categories. One such product I deleted and then the category opens without the redirect error, so I re-uploaded just the one product in a file and it stayed as v_products_type of 1 and works fine now when it previously did not.

So the question appears to be why is the upload changing what I have in the cell from a 1 to a zero when uploaded?

And have confirmed that the csv file (intermediate between the spreadsheet and the database) shows a 1 and not a 0?

Yes, the spreadsheet (.csv, seperated by Coma, Text delimiter double quote) that I am uploading shows a 1 in all cells for the v_products_type. However, when I do a full download with meta tags of all products, the .csv I get shows a zero for the same v_products_type for every product I have uploaded.

I also just downloaded the uploaded file I did to make sure it is still showing correct and it is. Not sure where else I would be able to check it at.

Is the current download for EasyPopulate 4.0 compatible with v157 Stock_By_Attributes?