
Originally Posted by
djdavedawson
Thank you for the quick response.
I will start digging into the export for some ideas and to get a feel for how it's written.
As a related followup question, is there a simple way to change the "User Defined Products Fields" to use v_products_description instead of v_products ?
Thanks Again MC
~D
Clarification of "language", the prefix of v_, as used within Easy Populate, is associated with a field within a table. It appears though by context that the question is if the User Defined *Products* Fields can instead be User Defined *Products Description* Fields. So, the "direct" way would be to modify the use/assignment of the table to the User defined ($custom_fields) in both the export and import routines, though currently because the products_description table is language dependent such queries are done within a separate loop when a products_description related field is needed/used instead of pulling in all of the associated data when querying for product specific information. Would need to add a little more to the applicable section of code to actually make use of those custom fields (User defined) against the products_description.
So for example to support the export, the query related information to generate the "header" of the file is located in admin/includes/modules/easypopulate_4_filelayout.php, the custom_fields would still need to be included in $file_layout relatively as they currently are, though would need to be addressed as part of a language dependence and be further generated to support the language identifier. Hhowever, within the same file the custom_fields are assigned against the products table through code similar to below, such that in the full product export (if not most of the areas) look for this or something like it where the actual field data is pulled/identified:
Code:
if (count($custom_fields) > 0) { // User Defined Products Fields
foreach ($custom_fields as $field) {
if ($chosen_key != 'v_' . $field) {
$filelayout_sql .= 'p.'.$field.' as v_'.$field.',';
}
}
unset($field);
}
Basically, and without a truly deep dive the above code would need to be commented out because the associated fields would no longer be a part of the product table.
Then in the export file the additional field(s) would need to be addressed as part of the language loop(s). All of the fields from the products_description table are retrieved; however, not all are specifically used (but because they are available they could be tapped into somewhere at/around line 375 of admin/easypopulate_4_export.php within the foreach loop. doing something like this:
Code:
foreach ($custom_fields as $custom_field) {
$row['v_' . $custom_field . '_' . $lid2] = $row2[$custom_field];
}
This would then be processed such that the array key would be verified against the file_layout records and pushed to the export file... Then a similar reverse process would be needed for the import. But, "unfortunately" it is not as quick of a fix as I had originally considered, but it is still doable.
Hope that helps at least a little.
Bookmarks