EasyPopulate 4.0 Support Thread

I think it's working now. I just did a quick import test. I'll test further.
Thanks - Henry

henry3:

I think it's working now. I just did a quick import test. I'll test further.
Thanks - Henry

Glad that at least appears to have it working. Please do report test result/issues.

mc12345678:

[So, here is what I understand in “date” order and therefore remain perplexed if there is an issue or not:
At point A a backup of the database was made.

At point B an export was made, the file modified to only include the primary reference key and user defined fields that were to be updated with whatever was in the import file.

At point C, the import file with the primary key and user defined data fields was imported causing the product identified by the primary key to be updated with whatever was present (or “absent”) in the user defined fields. The data for each field had been updated as desired/requested and all fields were present in the file. This included a field called products_ordered.

At point D (call it today), a comparison of the live database to the backup made at point A shows that everything is the same except for the data that was stored at point C. But the data in the products_ordered field is now zero instead of the quantity identified in the file at point C.

So question(s) are:

1. Did the import file at point C actually include the products_ordered field or not?
   1.a) If it did, how do the values identified there relate to what is/was in the database?
2. If you were to again upload just a single row of data that included the products_ordered field and information for that field, what happens to the information of that product and field?
3. When uploading are the user defined fields still present even when the involved import file doesn't have data for the applicable field?

OK I just tested to confirm the issue and it DOES delete the products_ordered.

Here is want I did to test:

In phpmyadmin I modified the products_ordered for two items entering 100 for each. I saved and verified it was populated.
I then imported a csv file in EP, see below:

v_products_model,v_products_length,v_products_width,v_products_height,v_products_ready_to_ship,v_products_quantity
10,9.5,3.5,3.1,0,5289
20,9.5,3.5,3.1,0,5766

Import was successful but when I went back in phpmyadmin the products_ordered on both items were 0

So indication here is that if a user defined (custom) field is identified in the admin, then if the field is not included in the file it will be treated as being blank and therefore cleared of it's value. Further, until this issue is corrected it would be advised that a custom field not be listed in the admin field unless that field is to be modified by an import...

mc12345678:

So indication here is that if a user defined (custom) field is identified in the admin, then if the field is not included in the file it will be treated as being blank and therefore cleared of it's value. Further, until this issue is corrected it would be advised that a custom field not be listed in the admin field unless that field is to be modified by an import...

Yes that seems to be the issue would you like me to test again BUT without the products_ordered field in admin?

Just tested again without the products_ordered in admin and it did NOT delete the products_ordered this time so yes confirmed that is the issue.

marcopolo:

Yes that seems to be the issue would you like me to test again BUT without the products_ordered field in admin?

marcopolo:

Just tested again without the products_ordered in admin and it did NOT delete the products_ordered this time so yes confirmed that is the issue.
Looking at a remnant of code in the import file it appears that I had begun adding the protection to prevent the issue you were experiencing. Looks like that needs to be completed/rectified still.

The goal being that the custom field could remain populated, but the data not cleared if the field is absent from the import file.

FYI, I believe I fixed the above problem, but still need to upload the changes to github... Wanted to run a couple more tests as well. Did find that the solution for the date/time issue was partially incomplete as I found cases of 0000-00-00 00:00:00 entered for the date_available related field instead of NULL, but at least it doesn't "seem" like it causes a problem by being there... Still to be incorporated/updated regardless of what it "seems". :)

Have pushed version 4.0.33 to github at: https://github.com/mc12345678/EasyPopulate-4.0

Here is the changelog:

4.0.33 02-29-2016 Added a filter to prevent custom field entries from being overwritten on import if
the import file doesn't include the field. If the field is in the import file,
but the data for the row is blank, then the data for that field will be cleared. If
the field is not present, then any data that exists for that field will remain
intact whether the admin->configuration->Easy Populate 4->User Defined Fields is
populated or blank.
Added some "folder" functionality to force the selection of the import file being in the
admin directory if catalog was selected and the entered path really points to
the admin directory. This functionality occurs in the configuration window as
well as when accessing EP4 for any operation.
Removed the bypassed code in admin/includes/functions/extra_functions that previously
was used for export formatting. This code was incorporated into a module file
in 4.0.32.
Added notifiers throughout to support extending the code to support other bulk related
data. Specifically targeted bookx.
Corrected the use of importing date_available and date_added as this had been affected
by use of bindVars without consideration of potential values.
Added a .htaccess file that only includes permission for .csv and .txt files based off
of the admin/.htaccess file available from ZC 1.5.4.
Updated instructions to add some additional considerations.

EasyPopulate v4 4.0.33 has been submitted to the ZC forum as a plugin that if accepted can be found at https://www.zen-cart.com/downloads.php?do=file&id=2068

In an upcoming version would expect to add version checking based on that file location.

Thanks for the update. I don't know if anyone else would be interested in having you adding an ISBN to the supported mods. I just copied the code from the UPC mod and used v_products_isbn and inserted it right after the UPC mod. Just a fyi you can also use <FilesMatch "(?i).*.(?i:csv|txt)$"> in the .htaccess

henry3:

Thanks for the update. I don't know if anyone else would be interested in having you adding an ISBN to the supported mods. I just copied the code from the UPC mod and used v_products_isbn and inserted it right after the UPC mod. Just a fyi you can also use <FilesMatch "(?i).*.(?i:csv|txt)$"> in the .htaccess

So I can't recall where I had seen ISBN "incorporated", I thought it was in the german version of the program and I had done some form of research on it to see what was expected/proposed or something and thought that there was some idea to "remove" it, but I certainly wouldn't hang my hat on that. :P

It is the relative "simplicity" of this plugin that has the ability to do so much/save time that has kept me with it. As can be seen it is relatively easy to add other "supported" mods to it. Even without the "support" indication, having the user defined field populated with products_isbn is sufficient to "support" the mod.

Must say "What a GREAT addon.. set up my zen cart with over 4500+ products in under 3 hours converting an xml feed from my supplier.. saved me weeks of work.....

question.. if I need to update product descriptions can I do it with a csv using just the v_products_model and v_products_description_1 ....and have nothing else change in the database???

hivtop:

Must say "What a GREAT addon.. set up my zen cart with over 4500+ products in under 3 hours converting an xml feed from my supplier.. saved me weeks of work.....

question.. if I need to update product descriptions can I do it with a csv using just the v_products_model and v_products_description_1 ....and have nothing else change in the database???

That has become the expectation (if using version 4.0.33+). Version 4.0.29 may be able to work that way, but I can not recall at the moment. As suggested, backup the database before trying, then if it doesn't work, post here and restore the database. As always suggested such "new process" attempts should be tested on a development site first, then when proven good to use on the live site.

If it doesn't work, it will not work in a major way that will be obvious, like all product_names being blank. But, other data, like price, quantity, etc. Ought to remain untouched/unmodified.

Do remember that model # must be unique, otherwise the last version of the text will replace any previous for that model #.

mc12345678:

EasyPopulate v4 4.0.33 has been submitted to the ZC forum as a plugin that if accepted can be found at https://www.zen-cart.com/downloads.php?do=file&id=2068

In an upcoming version would expect to add version checking based on that file location.

The link did not work. Is there another link for the updated download?

katrobb:

The link did not work. Is there another link for the updated download?

Absolutely, it's posted several times throughout this thread in the last several pages, if you're familiar with github, then one could find it by following the link on the first page, and the reason that the above link doesn't yet work is that the plugin moderator(s) haven't yet approved EP4 for it's first release as a ZC plugin. All in due time.

As for a directish link to download that current version, https://github.com/mc12345678/EasyPopulate-4.0.

Just installed the latest version Easy Populate 4.0.33 - Beta 02-29-2016

In admin when I goto Tools/Easy Populate 4

The below error gets logged:

[11-Mar-2016 19:34:24 America/New_York] PHP Warning: in_array() expects parameter 2 to be array, null given in /var/www/zencart/includes/functions/plugin_support.php on line 42

marcopolo:

Just installed the latest version Easy Populate 4.0.33 - Beta 02-29-2016

In admin when I goto Tools/Easy Populate 4

The below error gets logged:

[11-Mar-2016 19:34:24 America/New_York] PHP Warning: in_array() expects parameter 2 to be array, null given in /var/www/zencart/includes/functions/plugin_support.php on line 42

I would expect that to be because the plugin has not received approval yet. Therefore. The code as written for plugin_support receives null when trying to reach that download location and that. Throws off the code... A little surprised that condition isn't directly addressed, but having it logged. Does at least provide the store owner with some information to investigate.

Ok thanks for the quick reply, hopefully it gets approved soon it's a great mod!

marcopolo:

Ok thanks for the quick reply, hopefully it gets approved soon it's a great mod!

Had reached out to the software approvers earlier this week, been busy, but is on the list for review (and as necessary comment). I partially expect concern about the query method not consistently using the ZC standard queries, but in a large majority of cases it is so that error handling is "on-screen" rather than in a tucked. Away. File/folder. But hopefully will receive either feedback or see it approved soon.