EasyPopulate 4.0 Support Thread

Thanks! Actually that cleared a lot up for me. I appreciate the response!

tk42one:

Thanks! Actually that cleared a lot up for me. I appreciate the response!

Welcome, glad I could help at least a little. :) any other things that are "perplexing"?

I've got this installed on a new ZC 1.5.5. When I try to download one of the csv files exports, I get a 403 forbidden error and no download. In the settings, I have:
Upload Directory: admin/temp/
This folder has permissions of 0755

If I change the setting 'Uploads Directory Admin/Catalog' to false, I get no error.

Would anyone have a blank . CSV file with the Canada Post measurement fields that they could share?

Thanks in advance.

jeking:

I've got this installed on a new ZC 1.5.5. When I try to download one of the csv files exports, I get a 403 forbidden error and no download. In the settings, I have:
Upload Directory: admin/temp/
This folder has permissions of 0755

If I change the setting 'Uploads Directory Admin/Catalog' to false, I get no error.

Well, that indicates that there remains a problem with the "auto-fix" for when the admin directory is entered in the folder path. The current expectation is that the admin directory name not appear in the database. To do this I recommend removing admin/ from the start of your folder's definition and changing the catalog/admin switch to pull from admin only...

For further verification, do you have SSL set to true/in your admin/includes/configure.php file does your url for HTTP_SERVER contain http: or https:?

llmcdonald:

Would anyone have a blank . CSV file with the Canada Post measurement fields that they could share?

Thanks in advance.

If you review the installation package for Canada Post, should be able to identify what the field name(s) are by looking for things like alter, insert into or where $db->perform is used and can review the data being provided. There are other methods available as well such as review of the products table in say phpmyadmin and compare the fields to the install sql for a vanilla install.

There's also a plugin that can identify such differences.

mc12345678:

Well, that indicates that there remains a problem with the "auto-fix" for when the admin directory is entered in the folder path. The current expectation is that the admin directory name not appear in the database. To do this I recommend removing admin/ from the start of your folder's definition
Sorry, where is this?
mc12345678:

and changing the catalog/admin switch to pull from admin only...

For further verification, do you have SSL set to true/in your admin/includes/configure.php file does your url for HTTP_SERVER contain http: or https:?

SSL is enabled for the admin (and storefront) so it's https://

jeking:

Sorry, where is this?

SSL is enabled for the admin (and storefront) so it's https://

There is a "use_function" that has been added to the admin/includes/function/extra_functions file that is called when the configuration settings for EP4 have been modified (at least provided the remove/install SQL has been cycled in one of the newer versions.) The function is supposed to take a basic inspection of the entered path, if the catalog option has been selected and the admin path is present, then the catalog switch is to be auto flopped, and the path shortened to remove "admin". (Where admin is for those not fully following a rename of the actual admin directory and used here for privacy.)

I think maybe I was unclear. In Admin>Configuration>Easy Populate 4 the 'Uploads Directory' is set to temp/ What I posted originally was from Admin>Tools>Easy Populate 4 under the Configuration Settings

jeking:

I think maybe I was unclear. In Admin>Configuration>Easy Populate 4 the 'Uploads Directory' is set to temp/ What I posted originally was from Admin>Tools>Easy Populate 4 under the Configuration Settings

So, your actual upload directory is off of the catalog path then and not in the admin directory? The default install now uses the admin directory settings by default, but there are also those that use EP4 to populate from some form of auto-generation process from outside of ZC and therefore it is desired to continue the possibility of referencing that location, but then when it is desired to switch over to the admin folder for other operations, that the actual admin directory name not be stored in the database.

Because the last three posts have been somewhat incomplete, the actual location of the storage folder has not been fully identified in relation to the two settings needed to assign the folder. Folder path and whether admin (true) or catalog (false) is being used.

Ie. Report was admin/temp while on tools->EP4, this implies that in configuration->Ep4 that the directory was identified as temp/ with the admin/catalog switch set to admin (true) and the report was that this folder has write permissions as expected. When switching this to false, the folder name remains the same (temp/) but now off of the catalog, and this was successful, but this doesn't jive with the original post that indicated that the folder admin/temp had the correct permissions and now that it has been identified that admin/temp was showing on the tools screen, and not in the configuration menu, that changing to false worked to reach the directory.

Unless I've collected the above info incorrectly, the temp directory is inside the catalog path and that there is no problem other than not recognizing that upon reinstall (remove/install) the directory is set to the admin folder.

Oh jeez, sorry for the confusion. :(

Report is admin/temp while on tools->EP4, this implies that in configuration->Ep4 that the directory was identified as temp/ with the admin/catalog switch set to admin (true) and the report was that this folder has write permissions as expected. When switching this to false, the folder name remains the same (temp/) but now off of the catalog, and this was successful

Correct for settings and results. I got the error when trying to download the CSV while in the admin/temp folder but was successful when downloading from catalog/temp

jeking:

Oh jeez, sorry for the confusion. :(

Correct for settings and results. I got the error when trying to download the CSV while in the admin/temp folder but was successful when downloading from catalog/temp

Did you happen to load the .htaccess file found in the download folder: htaccess4AdminTempFolder into this "temp" directory in the admin folder location? The admin directory is typically (by default install) locked down and doesn't include *.csv or *.txt type files to be accessed via a web browser. There was a post a little while back suggesting a slightly modified version of that same file (haven't fully reviewed it yet, so also haven't implemented the suggestion, but it is on the list), but either way, it allows the applicable files to be downloaded. I guess the other "cross-check" is if the path provided for the download directory is one that exists/was appropriate (early implementation with ZC 1.5.5 required a little rework, I've been able to validate that the path works as expected and that I can download a file from my upload/download folder that is generated by EP4).

mc12345678:

Did you happen to load the .htaccess file found in the download folder: htaccess4AdminTempFolder into this "temp" directory in the admin folder location?

Nope, I missed that step. I love a simple fix, thanks. :smile:

jeking:

Nope, I missed that step. I love a simple fix, thanks. :smile:

No problem... Much easier to provide the simple fix once fully understood the conditions. :) Merry populating!

Importing attributes is the topic. A client has two identical sites, one wholesale and one retail.

Trying to simplify product additions for them so they:

1. add a new item to the wholesale site
2. Do a 'Complete Product' export
3. Do a 'Basic Products Attributes' export
4. Import the 'Complete Product' csv on the retail site (good so far)
5. Import the 'Basic Products Attributes' on the retail site - problem.
   The new product does not have attributes. The Import Results at the bottom of the page on the retail site show:

UPDATED! - Model: JimJim | 23997 | Todler Siz | 3-T,4-T |

The problem is that the attribute name is Todler Size: This is the csv content:

v_products_model,v_products_options_type,v_products_options_name_1,v_products_options_values_name_1
JimJim,23997,Todler Size:,"3-T,4-T"

Just for fun, I also tried:

"v_products_model","v_products_options_type","v_products_options_name_1","v_products_options_values_name_1"
"JimJim",23997,"Todler Size:","3-T,4-T"

jeking:

Importing attributes is the topic. A client has two identical sites, one wholesale and one retail.

Trying to simplify product additions for them so they:

2. add a new item to the wholesale site

3. Do a 'Complete Product' export

4. Do a 'Basic Products Attributes' export

5. Import the 'Complete Product' csv on the retail site (good so far)

6. Import the 'Basic Products Attributes' on the retail site - problem.

The new product does not have attributes. The Import Results at the bottom of the page on the retail site show:

UPDATED! - Model: JimJim | 23997 | Todler Siz | 3-T,4-T |

The problem is that the attribute name is Todler Size: This is the csv content:

v_products_model,v_products_options_type,v_products_options_name_1,v_products_options_values_name_1
JimJim,23997,Todler Size:,"3-T,4-T"

Just for fun, I also tried:

"v_products_model","v_products_options_type","v_products_options_name_1","v_products_options_values_name_1"
"JimJim",23997,"Todler Size:","3-T,4-T"

Issue is the v_products_options_type value (23997), this normally would be a value between 0 and 5 for a blank/fresh store... So would need to know what "type" of option is being used on each store and adjust accordingly... The products_option_type number is the option value as found from the admin screen when using the option name manager that corresponds with the particular option type, ie. dropdown is typically 0, Text is 1, Radio 2, Checkbox 3, File 4, Read Only 5... Depending on how other plugins add the values and sequence of adding the plugin(s)/values, the option value could be almost any number.

mc12345678:

Issue is the v_products_options_type value (23997), this normally would be a value between 0 and 5 for a blank/fresh store... So would need to know what "type" of option is being used on each store and adjust accordingly... The products_option_type number is the option value as found from the admin screen when using the option name manager that corresponds with the particular option type, ie. dropdown is typically 0, Text is 1, Radio 2, Checkbox 3, File 4, Read Only 5... Depending on how other plugins add the values and sequence of adding the plugin(s)/values, the option value could be almost any number.

In looking at that page, the id looks to be correct:

This list is the same on both sites.

jeking:

In looking at that page, the id looks to be correct:

<option value="0" selected="selected">Dropdown</option> <option value="1">Text</option> <option value="2">Radio</option> <option value="3">Checkbox</option> <option value="4">File</option> <option value="5">Read Only</option> <option value="23997">Grid</option>

This list is the same on both sites.
What is/was the method of verifying no attributes applied to product?

mc12345678:

What is/was the method of verifying no attributes applied to product?

The A icon is black, not teal. Going to Attributes Controller also confirms no attributes exist.

jeking:

The A icon is black, not teal. Going to Attributes Controller also confirms no attributes exist.

@jeking,
‎
Having difficulty reproducing the issue identified.
Here is the testing that I performed:

1. Created a new product (used ZC admin to do this for testing expediency.) gave the product the following unique Model#: ##add_attributes_EP4
2. Exported a basic attributes file.
3. Deleted all but one entry within a text editor, changed the model# of the one entry to the above Model#.
4. Imported the file.
5. Uploaded the file and had the following results:

NEW ATTRIBUTE! - Model: add_attributes_EP4, Option: Size,Values: S,M,L,XL,XXL,XXXL

Updated records: 0
New Imported records: 1
Errors Detected: 1
Warnings Detected: 0
Memory Usage: 745496
Memory Peak: 1930920
Execution Time: 0 seconds.
‎
6. Then tried using a model # that didn't exist in the database with all of the same information:

SKIPPED! - Model: add_attributes_EP4_2 - Not Found! Unable to apply attributes.

7. Then tried using the original file from above (no modification to the existing attributes before import) but changed the##v_products_options_type field to a value that didn't exist:

UPDATED ATTRIBUTE! - Model: add_attributes_EP4 Option: Size, Values: S,M,L,XL,XXL,XXXL‎
‎
8. Then added a new option value to the same entry that had a non-existent option name type:

NEW ATTRIBUTE! - Model: add_attributes_EP4, Option: Size,Values: S,M,L,XL,XXL,XXXL,XXXXL

So, I'm a smidge at a loss about what's going on. Can't be an admin/catalog database discrepancy, because EP4 uses the same database as the admin. There is a report that some of the error catching/data reporting does need some work, but the above report(s) of checking the data indicates that the assignment of attributes did not occur. Might want to look at the database directly as well, but not sure what action(s) would need to be attempted to identify the update (which sounds like the product already had attributes assigned) as being performed but it not making any change.