EasyPopulate 4.0 Support Thread

[waterbender]

It looks like the problem is resolved when I changed these column titles:
v_categories_name_1
v_category_path_1
v_categories_description_1
v_metatags_title_1
v_metatags_keywords_1
v_metatags_description_1

to

v_categories_name_en
v_category_path_en
v_categories_description_en
v_metatags_title_en
v_metatags_keywords_en
v_metatags_description_en

[waterbender]

Another question on importing attributes. Currently, I first use the Attrib-Basic-EP file to import attributes, then use the Attrib-Detailed-EP file to revise attributes that cost extra. However this seems tedious as I have to manually find and match the corresponding products_attributes_id one by one. Is this the only way to it?

[mc12345678]

Another question on importing attributes. Currently, I first use the Attrib-Basic-EP file to import attributes, then use the Attrib-Detailed-EP file to revise attributes that cost extra. However this seems tedious as I have to manually find and match the corresponding products_attributes_id one by one. Is this the only way to it?

So population of attributes to a product requires at least two "levels" of data population: existence to a product, and detail about that existence.
Perhaps some of that could be done all in one file, but it certainly wouldn't be pretty.

The current process, also described in the instructions, basically has the basic file get populated with product, option name type, option name, and option values associated to that option name.
Export a detailed report.
Update the details of the detailed report
Import the detailed report to refresh the values.

So, I'm not entirely sure what "manual matching" issue is... I say that to get some further information, just because I don't understand doesn't mean it isn't an issue.

On the export of the detailed file, the products_model is included along with *some* other "human readable" content that should make it easier to locate the row to update. Certainly other data could be added for inclusion such as products_name, though that also shouldn't be necessary if "default settings" are used for operation as products_model should refer to a unique product... (Yes a little tongue in cheek there too, because there are additional settings that allow more freedom in using the software.)

[waterbender]

Hi,

What I meant was to find out the corresponding attribute id of the imported product which has an additional cost.
There are many products on the site. When attributes are exported, can we be selective? If not, the file will be very big as the attributes of every single product will get exported.

[mc12345678]

Hi,

What I meant was to find out the corresponding attribute id of the imported product which has an additional cost.
There are many products on the site. When attributes are exported, can we be selective? If not, the file will be very big as the attributes of every single product will get exported.

Much more understandable. :)

Correct, at the moment it is a full or no basic/detailed attribute export. Incorporating the use of the dropdowns across the top is possible; however, would require some additional code in:
admin/easypopulate_4.php
admin/includes/languages/english/easypopulate_4.php
admin/includes/modules/easypopulate_4_filelayout.php
and
admin/includes/easypopulate_4_export.php

The thought is that in the filelayout, would incorporate an additional "string" to substitute before the "ORDER BY" statement.
In the language file(s), would incorporate the word(s) for the option(s) that would be in the dropdown (considering adding just the two "features" of basic/detailed attributes).
In the base file, adding the new language defines to support dropdown expansion.
In the export file adding the "control" to substitute the string added before the "ORDER BY" statement either with the desired filtering or to just make it blank as would be expected for the "default" export.

So, yes, doable and I'll look to initiate the change/addition of the feature/option. Thank you for clarifying.

Now, last part to that, the above does not add/offer the ability to specifically target just a single product nor the ability to enter in a list of specific/designated product, but would allow selection through existing selection options (category, manufacturer, enabled/disabled, etc...). So a "closer" range to select product, but perhaps not as unique as desired(?).

[wtfbbq]

I'm getting an import error upon exporting the entire catalog and cannot import any changes to the csv file.

Version Easy Populate 4.0.37.13 - 05-03-2021 On 1.5.7
php7.4

[mc12345678]

I'm getting an import error upon exporting the entire catalog and cannot import any changes to the csv file.

Version Easy Populate 4.0.37.13 - 05-03-2021 On 1.5.7
php7.4

Please read over the last 10-15 posts. Feel free to answer the questions asked about settings of some of the specific configuration options.

[mc12345678]

Much more understandable. :)

Correct, at the moment it is a full or no basic/detailed attribute export. Incorporating the use of the dropdowns across the top is possible; however, would require some additional code in:
admin/easypopulate_4.php
admin/includes/languages/english/easypopulate_4.php
admin/includes/modules/easypopulate_4_filelayout.php
and
admin/includes/easypopulate_4_export.php

The thought is that in the filelayout, would incorporate an additional "string" to substitute before the "ORDER BY" statement.
In the language file(s), would incorporate the word(s) for the option(s) that would be in the dropdown (considering adding just the two "features" of basic/detailed attributes).
In the base file, adding the new language defines to support dropdown expansion.
In the export file adding the "control" to substitute the string added before the "ORDER BY" statement either with the desired filtering or to just make it blank as would be expected for the "default" export.

So, yes, doable and I'll look to initiate the change/addition of the feature/option. Thank you for clarifying.

Now, last part to that, the above does not add/offer the ability to specifically target just a single product nor the ability to enter in a list of specific/designated product, but would allow selection through existing selection options (category, manufacturer, enabled/disabled, etc...). So a "closer" range to select product, but perhaps not as unique as desired(?).

Almost have it. Forgot that the attribute exports don't use the products to categories table so having to generate the product list based on products in categories. I plan to create two export options for each basic and detailed to support of linked product and the second to exclude linked product.

[waterbender]

Almost have it. Forgot that the attribute exports don't use the products to categories table so having to generate the product list based on products in categories. I plan to create two export options for each basic and detailed to support of linked product and the second to exclude linked product.

Great thanks. Looking forward to the newer version with this feature that can selectively export a range of attributes (either by categories, manufacturers or date if possible).

[mc12345678]

It looks like the problem is resolved when I changed these column titles:
v_categories_name_1
v_category_path_1
v_categories_description_1
v_metatags_title_1
v_metatags_keywords_1
v_metatags_description_1

to

v_categories_name_en
v_category_path_en
v_categories_description_en
v_metatags_title_en
v_metatags_keywords_en
v_metatags_description_en

First of all, glad that were able to perform the import.
Second, simply changing the title of the fields became a "one time" correction because it is obvious that 1) the export file was generated using the language_id for export but import was ignoring the language_id and instead was using the language_code... So, please, please, please, review almost any number of pages back about changing the import/export settings so that they match... Please....
Third this appears to have revealed a condition that was to be prevented. Basically when it would not be possible to import content it was to provide a message. The current check for doing that simply validated that at least *some* field exists even if the current settings wouldn't have imported the content. So thank you for identifying that issue.