EasyPopulate 4.0 Support Thread

[utefan]

Is anyone else having an issue where the upload feature in Easy Populate 4.0.19 isn't working? I'm wondering if it is a firewall or a timeout issue.

[mc12345678]

Is anyone else having an issue where the upload feature in Easy Populate 4.0.19 isn't working? I'm wondering if it is a firewall or a timeout issue.

I wouldn't be surprised if it is far more than EP4 that is affected. What file size(s) have been tried? Have you also tried setting up a catalog product that allows uploading a file and seeing if the same file can be uploaded via that route? What environment is this operating on (ie. Php and ZC versions?) just to name a few things to check. :)

[utefan]

I ran into a very odd issue tonight with a brand new install of 1.5.1. I installed EP4.0.19 and everything was working great. However, after installing a bunch of other mods (37), it appears that EP4 was broken somewhere along the way. All I am getting now is a blank white page when I try to go the EP4 via the admin panel. I am getting the following message in my error logs:

PHP Fatal error: Function name must be a string in /home/corg/public_html/admin/includes/functions/extra_functions/easypopulate_4_functions.php on line 512.

Here is what line 512 looks like in that file:

$string = ($ep_uses_mysqli ? "MySQLi" : "MySQL") . " error ".($ep_uses_mysqli ? mysqli_errno($db->link) : mysql_errno() ) . ": ".($ep_uses_mysqli ? $mysqli_error($db->link) : mysql_error())."\nWhen executing:\n$query\n";

If I remove the dollar sign in front of "mysqli_error($db->link)" above, the white page goes away and EP4 comes up in the admin panel, but there is an error message that says, "Warning An SQL error has occured. Please check your input data for tabs within fields and delete these. If this error continues, please forward your error log to the Easy Populate maintainer".

I have seen other posts in here with the same message, but different error logs. I'm thinking this must be a different issue. Any ideas about what might be happening on this one? Thank you.

[utefan]

Thanks for your response. I'm running I'm running ZC 1.5.1 and PHP 5.6.16. This is a very odd case. Not only was I having trouble loading files via the file upload utility in EP4, but I was also having the same issues from my laptop via filezilla. File transfers through the cpanel were working fine. I shut off my antivirus software and suddenly my computer was able to upload fine through Filezilla. That is what got me thinking about maybe there being a firewall issue. I'm curious what would happen if I moved my temp folder out of my admin directory. I'm going to test that next. I'll share if I find anything of interest. Thanks again.

[utefan]

BTW, this is a different build than the one where I was having the upload issue. Thank you.

[utefan]

I wouldn't be surprised if it is far more than EP4 that is affected. What file size(s) have been tried? Have you also tried setting up a catalog product that allows uploading a file and seeing if the same file can be uploaded via that route? What environment is this operating on (ie. Php and ZC versions?) just to name a few things to check. :)

I've tried different sized files with the same upload result. I haven't tried the catalog product upload. Thanks for the suggestion.

[mc12345678]

Have you also tried a more recent version? There are/were reasons why the software was updated. Particularly PHP versions were at play and you are likely to run into other troubles running PHP 5.6 with ZC 1.5.1. Why didn't you install a more recent version something released less than 4 years ago?

Yes in 4.0.19 there was that dollar sign issue, as well as a number of other things that have been addressed or corrected since then. I would suggest the version available at https://github.com/mc12345678/EasyPo...e/v4.0.35.ZC.1. It is compatible as far back as at least ZC 1.3.9 up to at least ZC 1.5.5 (hasn't been tested on ZC 1.6 yet)

[utefan]

I just bought a store from someone else that was on 1.3.9. I decided to move the store to 1.5.1 initially because that is the latest 1.5.1 version that supports all of the mods that replicate existing functionality. I'm hoping to upgrade from there once I get the 1.5.1 store working as expected. I'll try a newer version of EP. Thanks for the heads up.

[mcevoli]

Hello,

looking in files I saw the v_status could have the "7" value.
What is the use of 7 value?

Thanks.

[mc12345678]

Hello,

looking in files I saw the v_status could have the "7" value.
What is the use of 7 value?

Thanks.

It was a feature that was added back in v4.0.31 August 2015 to allow reassigning the master_category for a row of data to the category of that row for that product. It is discussed in here, but hasn't been highly advertised because of the effect it can have on your store if used improperly or even in some cases properly. :)

So the original vision for it was to not modify the export file as those using ZC have come to "enjoy" but allow modification/removal of say linked product. Linked product provided when a products_id is applied to a category that is not the master_category. In a default EP4 install, two rows that have the same products_model data but have different category information will result in generating a linked product for that products_model because the "second" instance will get the product added to the products_to_categories table if it is not present. All product in order to appear in the cart need to have at least one instance of a record in that table. So new product as well as modification of existing product should be covered by the EP4 code.

Thing is that there was not previously a "delete a linked item" option... Further, there wasn't exactly a clear cut way to suggest how best to do that, considering a lot of *that* issue relates to what products_model record is read first while processing the file, and which record was updated by the user.

Any rate, the following was logic was applied but look at bullet 3 for the short and skinny:
If the status is 7,
1. check to be sure that the product does or does not have a master_category assigned. If it does not, then assign the current product the master_category associated with that record, no further action required. (Unfortunately there have been those that have processed data or manually modified their database at one point and neglected to associate product to a category/master_category and therefore their product doesn't appear as expected/designed.
2. If there is a master_category assigned, and the current row category is not the master_category, then attempt to make the current row category the master_category, attempt to delete the product from the category represented by its previous master_category and then report the results of those actions based on the success of trying to do the two above actions. If the product's master_category couldn't be updated, then a linked product would exist/be generated (the delete operation isn't supposed to fire, because otherwise the next action would cause a product to not have a master_category) with a link being generated to the category identified on the row. If the product's master_category did get updated, then attempt to delete the product from the category that it used to belong. If unsuccessful at deleting that item, then again would have a linked product but this time the link would be to the old master_category with the product having a new master_category. If successful at deleting the item from the old category, then the product would have been successfully moved from the old category to the new category and no link generated. If unable to update the product's master_category, but able to delete the product from it's master category then the code reported deleting the product from the category (which would unfortunately leave it with an unassigned master_category, but that would be because the code was unable to properly execute an update command. Additional "action" could be built in to then try a delete followed by an insert, or to use the replace command, but it seemed that if that caused an issue, then there was probably something bigger going on that would need to be addressed).

3. So, summary: status of 7 is to move the master_category to the category on the row and if able delete the product from the previous category represented by its former master_category and if not previously assigned to a master_category to update the master_category to be the category of the current row. With this operation and proper sequencing of import data rows, all links for a product could be removed leaving behind the product in a single category, or the master_category could be changed without having to delete the product and add it back (previously not something easily maintained/managed but other edits have made something like that possible without losing uniqueness of the product's identifier).