EasyPopulate 4.0 Support Thread

Quote:

---

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.

Hi
Speaking of custom fields, do you think ti would be possible to also add some modifiers to priceqty file layout?
This file is quite good to manage import / export prices / stocks, specials, etc... as the name of the file suggests :)
But with a notifier, one could easily add some more or less fields to it.
Recently I had to do it, and making a new file layout for a couple of fields, would almost duplicate the same file operations, it 's not worth it. I think...maybe I'm wrong, because I have a huuuuuge filelayout for books that takes all the courage of making another one. Actually never try to make a simple one.
Anyway, a suggestion.

Best regards

I maybe missing something but I keep doing something wrong. Using Easy Populate 4.0.28 with v1.5.4.

Download my database - open in Open Office spreadsheet take a few products and alter them - save as a csv to the file name given on the download with just these products - upload - import. Either get errors or get new duplicated files.

The question is do I have to save the whole database again with the same file reference (eg: Full-EP2018Apr13-113512.csv) or do I rename it to something else to import either the complete file or the few amended ones. What format do you rename it to also?

Sorry to be vague but I have read through the instructions so many times and I still can't manage it.

Quote:

---

Originally Posted by stringplayer

I maybe missing something but I keep doing something wrong. Using Easy Populate 4.0.28 with v1.5.4.

Download my database - open in Open Office spreadsheet take a few products and alter them - save as a csv to the file name given on the download with just these products - upload - import. Either get errors or get new duplicated files.

The question is do I have to save the whole database again with the same file reference (eg: Full-EP2018Apr13-113512.csv) or do I rename it to something else to import either the complete file or the few amended ones. What format do you rename it to also?

Sorry to be vague but I have read through the instructions so many times and I still can't manage it.

---

The "important" part of the filename is everything up to and including the letters EP. Anything after that is up to you. (extension needs to be .csv)

The first part of the filename let's EP4 know what types of fields to expect so that it can process properly.

Don't recall the full feature availability of 4.0.28 with the current version being 4.0.36, but the process is basically logic based. The field list basically needs a single anchor point (primary key) and one column of data to be modified. Every row of data is attempted to be processed from top to bottom.

Your edited data file should look very similar in format to the original saved file if you were to look at each with a plain text editor. Be sure to follow the Open Office or Libre instructions to save as/export the file in UTF8 csv format.

Hi again

Thanks very much. I am now getting the hang of it. Just a few more questions.
How do I mark a product on the spreadsheet to delete before importing.
How do I mark a product status to off on the spreadsheet before importing.
If I rearrange the lines of the spreadsheet order of the products does it make any difference when importing (keeping the product on the original lines).
When putting a new product onto the spreadsheet is there anything that has to be done such as the index number etc or does it make its own when imported.
I think that will be it once I have these answers. Much appreciated.

Quote:

---

Originally Posted by mc12345678

The "important" part of the filename is everything up to and including the letters EP. Anything after that is up to you. (extension needs to be .csv)

The first part of the filename let's EP4 know what types of fields to expect so that it can process properly.

Don't recall the full feature availability of 4.0.28 with the current version being 4.0.36, but the process is basically logic based. The field list basically needs a single anchor point (primary key) and one column of data to be modified. Every row of data is attempted to be processed from top to bottom.

Your edited data file should look very similar in format to the original saved file if you were to look at each with a plain text editor. Be sure to follow the Open Office or Libre instructions to save as/export the file in UTF8 csv format.

---

Bolded text should answer the question about sequencing.

Quote:

---

Originally Posted by stringplayer

Hi again

Thanks very much. I am now getting the hang of it. Just a few more questions.
How do I mark a product on the spreadsheet to delete before importing.
How do I mark a product status to off on the spreadsheet before importing.
If I rearrange the lines of the spreadsheet order of the products does it make any difference when importing (keeping the product on the original lines).
When putting a new product onto the spreadsheet is there anything that has to be done such as the index number etc or does it make its own when imported.
I think that will be it once I have these answers. Much appreciated.

---

May I suggest searching the readme.txt file for two different words: the first delete (identifies how to completely delete a product), the second disable (identifies how to disable a product though this also would be easier seen/understood if an export of the database was performed, a product disabled and the export again performed to see what changed and how.)

As adding a product, it still somewhat depends on whether you've upgraded or not, but the primary key (anchor field) basically determines what to do... the historical method of using EP was to use the model field. Each product to have its own model, no 2 products to have the same model. If two products have the same model, then when importing, they would both get updated which could/would cause some undesired issues depending on how much data (number of fields) was updated.

Now as far as deleting. Are you sure you really want to delete the product? Unless you are using the products_id as a primary key, then deleting the product followed by importing a new product (with the same information) will cause a new products_id to be created which is quite literally a new product even if it is called the same thing as before, weighs the same, is described the same, etc...

1.5.5f fresh install with Easy Populate 4.0.37.6 - 02-08-2017

The import button is showing import error instead of the import button.
What could be the cause and fix?

In the meantime I rolled back to an older Easy populate version and it works.

Quote:

---

Originally Posted by wtfbbq

1.5.5f fresh install with Easy Populate 4.0.37.6 - 02-08-2017

The import button is showing import error instead of the import button.
What could be the cause and fix?

---

The reported/expected cause is that the delimiter between fields was either inconsistent or non-matching for the review of the file. There are/were some database updates incorporated into that version that would need to be executed (top right corner would have offered an update option from a previous version).

Would need to know that the database was updated and then would recommend presenting the first few lines of the csv file to further identify the issue.

Almost there. When I enter a jpg from images folder under v_products_image (such as e120.jpg) it does not show. What am I missing.
Thank very much.