EasyPopulate 4.0 Support Thread

[amiablesoul]

Just a guess here, maybe v_products_model should be v_products_id?

[jiji2018]

I added a field to the product, and I want to add the value of this field through the batch table, which files do I need to modify？
Where do I need to modify this plugin and add this field

[mc12345678]

I added a field to the product, and I want to add the value of this field through the batch table, which files do I need to modify？
Where do I need to modify this plugin and add this field

Product table fields desired to be exported and imported that are not part of the base code are addressed in the user defined field in configuration->easy populate v4. Simply add the field's name into the text box. If multiple are used, then separate them by a comma. This is covered in the instruction.

[jiji2018]

Product table fields desired to be exported and imported that are not part of the base code are addressed in the user defined field in configuration->easy populate v4. Simply add the field's name into the text box. If multiple are used, then separate them by a comma. This is covered in the instruction.

I added fields in the background, but the batch table still cannot be imported.
Is there a need to modify the program elsewhere?

[mc12345678]

I added fields in the background, but the batch table still cannot be imported.
Is there a need to modify the program elsewhere?

If the field `products_family` exists in the product's table and the row contains the primary key that has been chosen, then import of that data should work or a message is provided about it not working.

To further test, I would recommend exporting one or more product that already have information in that field to see that it is exported and to provide a sort of example.

There is no other code modification necessary to support that in an otherwise functional system.

[jiji2018]

If the field `products_family` exists in the product's table and the row contains the primary key that has been chosen, then import of that data should work or a message is provided about it not working.

To further test, I would recommend exporting one or more product that already have information in that field to see that it is exported and to provide a sort of example.

There is no other code modification necessary to support that in an otherwise functional system.

This field is exported but cannot be imported

[mc12345678]

This field is exported but cannot be imported

If not I would expect some reason to be provided. Perhaps the CSV file is not formatted properly, perhaps the primary key used (default is products_model) is listed for more than one product such that an update is not going to the correct product. In this case would suggest changing the primary key to products_id.

[jiji2018]

If the field `products_family` exists in the product's table and the row contains the primary key that has been chosen, then import of that data should work or a message is provided about it not working.

To further test, I would recommend exporting one or more product that already have information in that field to see that it is exported and to provide a sort of example.

There is no other code modification necessary to support that in an otherwise functional system.

The import did not prompt any errors, but there was no value in the database.

[mc12345678]

The import did not prompt any errors, but there was no value in the database.

And after the file was uploaded to the server, the file was then imported? (upload places the file on the server, import processes the file to push the content to the database.) this part has been misunderstood by some before.

[mc12345678]

Hi, I am having a little problem with EP4.

I have ZC1.5.6c, installed from that version, not upgraded. I also have Ultimate URLs and Dynamic Filter installed.

EP4 is installed, and I have imported a bunch of products, no problem, all worked great. It is when I have come to add some attributes that the problem has occurred. I have created a one line/product file for ease of testing, I upload & import the file and I get the following 2 error messages at the top of the page:

1. File Import Completed with issues.

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



Then at the bottom of the page the error is listed thusly:


SKIPPED! - Primary key: v_products_model:bcard - Not Found! Unable to apply attributes.

The product does exist, it has a master category assigned correctly, and I have opened the file in Notepad++ and checked for any tabs, and also made sure the file is converted to UTF8.

Here is the contents of the file (which is named "attrib-basic-ep-test.csv"):

v_products_model,v_products_options_type,v_products_options_name_1,v_products_options_values_name_1
bcard,1,First Name,TEXT

Can anybody shed any light on this?

Just a guess here, maybe v_products_model should be v_products_id?

Really, really sorry for not responding sooner. I have no reason, only excuses.

While there is a lot of good information in the above post and as a result I would like to say that the issue is fully on the code, I have come to realize that there are a few things possibly missing and as a result I am asking questions to try to gain information not to doubt anything provided.

So the below are in no particular order but each could be either the single cause or in combination with other things.

As pointed out by amiablesoul, there is an option in the software to change the primary_key from the default products_model to products_id. It is also possible that the error message is incomplete and inaccurate identifying the desire to use the products_model instead of properly identifying that the products_id is the item to be found. This issue is corrected in an upcoming release.

The statement about "converting to UTF8" does not identify in what program the conversion was made. If Excel was used to specifically save the csv data as utf8, then it is a "known" issue that it adds a BOM character to the beginning of the file and that actually will cause the field to not be readable. Please, for those that wish to blame this software, there simply are too many ways that data can be incorrectly provided to be able to then evaluate all of the possibilities (and still not identify how the data was incorrectly formatted) instead of following recommended processes or just keeping it simple. In fact I have yet to find a way to discover by review of the import file whether the csv file was generated by Excel or other programs such as Open Office or similar consistently. Yes, there are occasions where a character may be found that signifies the data coming from Excel, but even those are addressed in this code by converting such characters to standard utf8 equivalent.
As part of the processing of the data, a message was generated indicating that there was a problem with the sql statement. This program generates a debug log of its own in the associated import/export file. The contents of that file may be helpful in determining the cause/issue.
Another thing which is suggested in the start of the instructions is to basically initially work with unedited data. This will help step through the process that works in your environment to consistently get the desired results. So. Suggestion would be to export some amount of data, open it with your preferred editor, save it with a new filename and no changes and then attempt import (after upload) of that data. Then review the results. If there are issues, then would suggest simply reimporting the original file to validate operation.

So, what appears correct? I see that the filename matches the expected format to support processing the attributes correctly. I "see" the proper columns and what appears to be correct dividers between data; however, the issue may be with other data inserted by the conversion that is not visible but instead is electronic data not displayed as visible characters. I do see that text is not bounded by quotes, though this is not required it can have an effect *if* that internal text had special characters in it as well... (meaning in this case it does not appear to be an issue)
There doesn't appear to be any spaces in any of the headings nor field data, but that would require review specifically of the file itself.

So... while there may be some initial "setup" of concern, perhaps can see that there are a lot of ways things can go wrong, but reproducibility of it going right is actually easy.