EasyPopulate 4.0 Support Thread

[mc12345678]

[HTML][HTML]

hmmm... I do have the primary key as model and entered the model as NEW PRODUCT! - Model: blank_new | | 1 | einsteins- | Colombian | Not just t | | | | | 55 | 6 | 0 | 25 | 1 | 1 | 0 | 1 | | | 0 | Coffee | Coffee^Pre | --none-- | 1 | | | | | | | | | 
No product yet that I can fine.  I will experiment some further.  Thank you!

[/HTML][/HTML]

Although the data returned from that view can be difficult to decipher, it appears that a new product was added that has the products_model of 'blank_new'. If the columns line up to what I might expect, this new product is expected in the sub-category Pre under the category Coffee. Though it may also be that the product has been added to the category of Coffee even though that category has sub-categories. In a standard store, this will cause problems on the front end if the product is active. Some sort of modification to the applicable header_php.php file would be necessary to support product and categories both co-existing and active. The easier way to offer help would be to provide the first line along with the line in question from the csv file.

[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

[mc12345678]

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.

[gohealth]

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

[mc12345678]

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.

[gohealth]

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

[mc12345678]

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.

[gohealth]

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

[mc12345678]

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.