EasyPopulate 4.0 Support Thread

mc12345678:

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.

I imagine they are so busy with 1.55! But congrats on getting to the submission phase. Finally be able to take "beta" out of the name!

And thanks again for picking up the project and keeping it alive with your additions and support. I would have hated to see it fall to the side since I've been too busy to continue supporting it.

-chadd

chadderuski:

I imagine they are so busy with 1.55! But congrats on getting to the submission phase. Finally be able to take "beta" out of the name!

And thanks again for picking up the project and keeping it alive with your additions and support. I would have hated to see it fall to the side since I've been too busy to continue supporting it.

-chadd

Dang straight. :) there actually is a little bit of submission confusion at the moment. It is posted in the plugins, but there are a few administrative things to rectify, but all in good time. :) I will say that without either posting a yet more updated version or help from the software team that the version checking portion isn't going to work right at the moment. I expect to hear back on that in the next day or so and will take the next appropriate action.

There likely remains improvements on things like instructions that can continue to be improved, but it's gotten this far with what exists. :) glad to see that you're still around. :)

mc12345678:

Dang straight. :) there actually is a little bit of submission confusion at the moment. It is posted in the plugins, but there are a few administrative things to rectify, but all in good time. :) I will say that without either posting a yet more updated version or help from the software team that the version checking portion isn't going to work right at the moment. I expect to hear back on that in the next day or so and will take the next appropriate action.

There likely remains improvements on things like instructions that can continue to be improved, but it's gotten this far with what exists. :) glad to see that you're still around. :)

Heard back... Suggestion is to resubmit to the existing location with the update(s) desired/necessary. Current plan is once at an appropriate computer to package up what is now 4.0.33a and submit. Current change is simply to the download location which is https://www.zen-cart.com/downloads.php?do=file&id=2069. Been going through the issues posted in github to see if there is anything that can be addressed relatively quickly as well to maybe offer a real version modification, but for those that have downloaded 4.0.33 and would like to receive notification of an updated version submitted on ZC, open admin/easypopulate_4.php, goto line 84 and change:

  $new_version_details = plugin_version_check_for_updates(2068, $curver);

to:

  $new_version_details = plugin_version_check_for_updates(2069, $curver);

Otherwise, depending on your version of ZC, an error may get logged as a result of no file data existing on the other end of the query.

I just installed EP 4 into zc 1.5.5, running on my windows pc with xampp. everything works fine until i try to download a generated file in the temp folder. I get this:
https://localhostdir_ws_https_admintemp/Full-EP2016Mar19-030356.csv

Anyone know why and if there is a fix?

Thanks in advance.

I just installed EP 4 into zc 1.5.5, running on my windows pc with xampp. everything works fine until i try to download a generated file in the temp folder. I get this:
https://localhostdir_ws_https_admintemp/Full-EP2016Mar19-030356.csv

Anyone know why and if there is a fix?

Thanks in advance.

wtashby:

I just installed EP 4 into zc 1.5.5, running on my windows pc with xampp. everything works fine until i try to download a generated file in the temp folder. I get this:
https://localhostdir_ws_https_admintemp/Full-EP2016Mar19-030356.csv

Anyone know why and if there is a fix?

Thanks in advance.

That is intended to be generated by combining several parts of the definitions in the admin/includes/configure.php file (or possibly in the admin/includes/local folder if so used...

It would appear that DIR_WS_HTTPS_ADMIN is not defined on the admin side and that the page is loaded while using https:

As for use on ZC 1.5.5? Well, hasn't been tested yet, though was just about to do so.. Problem is that the current ZC 1.5.5 setup that I have is experiencing a problem that I have yet to be able to explain but it nearly seems like it is related to a database that I upgraded from 1.3.8 to 1.5.5...

So, it may be that ZC 1.5.5 doesn't have that definition... If that's the case, possibly an easy fix... But more to come in the next day or so...

Temporary solution as posted here is to set ENABLE_SSL_ADMIN to false and as desired for the admin website definition either use or don't use https... Will have to incorporate something as I was really hoping to prep/verify prepped this software for ZC 1.5.5 in its entirety...

mc12345678:

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.

This is still being generated even though it is now approved and available in plugins?

marcopolo:

This is still being generated even though it is now approved and available in plugins?

Approval in the plugins was for up to ZC 1.5.4 and there is no issue when used in that environment.. Had not been tested on ZC 1.5.5. I'll be looking at how this is reproduced and a resolution to maintain functionality for both the current ZC as well as versions before ZC 1.5.5.

Oops, right answer to the wrong question.

The patch is available above requiring a change in one line.

I haven't provided the plugin management team with the corrected file. Until I do my part or the above mod is made, the issue will persist

I'm still on v1.5.4

marcopolo:

I'm still on v1.5.4

Sorry, perhaps you noticed that I answered the wrong question related to the release of the plugin to the ZC site. I would say that I did a lot which caused the issue, so in my opinion it's on me to correct. The approval team did their part even though some admin issues remain to be completed.

As referenced above see post 2285.

Got it I missed that post, I changed it as you outlined to:

$new_version_details = plugin_version_check_for_updates(2069, $curver);

and it works now without generating any error log.

wtashby:

I just installed EP 4 into zc 1.5.5, running on my windows pc with xampp. everything works fine until i try to download a generated file in the temp folder. I get this:
https://localhostdir_ws_https_admintemp/Full-EP2016Mar19-030356.csv

Anyone know why and if there is a fix?

Thanks in advance.

Perhaps a rehash, but the real why is that in ZC 1.5.5, the admin configure.php "structure" was simplified and the DIR_WS_HTTPS_ADMIN define was removed... It is now expected that the admin "path" will be either all http: or all https: as set in the admin/includes/configure.php file. I have made some code changes and haven't been able to test them yet, but if you could take a look at the master path of https://github.com/mc12345678/EasyPopulate-4.0 and specifically at the admin/easypopulate_4.php file, there is a change made in two lines that ought to correct/address this issue for ZC 1.5.5 and previous supported versions. Again, I didn't get a chance to test it over the weekend, but it looks correct. Would appreciate the feedback incase I don't get to it before another.

For anyone wondering, the issue occurs/occurred in EP4 4.0.33 used on ZC 1.5.5 when the current page was loaded with SSL and the admin was the storage location. I had taken a slightly different approach to this line of code instead of simply observing the settings in the includes/configure.php file in the event that someone had chosen to load their admin (for that page) using SSL even though it wasn't fully enabled, at least the associated file(s) would also then be served using SSL... I have since gone back to a more "custom" method that adheres to the file settings rather than the chosen path at the time of loading the page.

Further it is my plan to submit this modification to the ZC forum which will/should correct a few other minor administrative issues, but it needs to be tested first.. Not going to submit something that just "looks" good...

Zen Cart v1.5.4 (PHP Version: 5.6.17 - MySQL 5.6.29)
Localization -> Languages: Italian/English

Easy Populate 4.0.33a - Beta 02-29-2016
Model/Price/Qty (with Specials)

I export two "v_products_model" and two "v_products_name"
I correct the stocks ("v_products_quantity" and "v_status"

I import the file and i see: "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"

Debug Log: "MySQLi error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'WHERE products_id = *** AND language_id = 3' at line 1
When executing: UPDATE products_description SET WHERE products_id = *** AND language_id = 3"

*** They are different ID

Why ? Any suggestions ?

Regards

Nightfly66:

Zen Cart v1.5.4 (PHP Version: 5.6.17 - MySQL 5.6.29)
Localization -> Languages: Italian/English

Easy Populate 4.0.33a - Beta 02-29-2016
Model/Price/Qty (with Specials)

I export two "v_products_model" and two "v_products_name"
I correct the stocks ("v_products_quantity" and "v_status"

I import the file and i see: "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"

Debug Log: "MySQLi error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'WHERE products_id = *** AND language_id = 3' at line 1
When executing: UPDATE products_description SET WHERE products_id = *** AND language_id = 3"

*** They are different ID

Why ? Any suggestions ?

Regards

Request a little clarification and some additional information.

1. two v_products_model, does this mean two products that have a v_products_model or are there two fields along the top of the export file that have v_products_model as a field?

2. I understand two v_products_name to mean v_products_name_1 and v_products_name_2 are/might be fields though the second number could be other than 2. Please verify this is to what you were referring.

3. When exporting the product, what is/was the admin setting for the primary key, is it products_model, products_id or blank_new?

4. Same question for when importing.

5. What field(s) are in the user defined entry under admin/configuration/ep4?

6. The exported product, were there two or more rows that contained the same data in the v_products_model field? (Ie. either linked product or the same model applied to two different product?)

7. What fields are along the top of the export file?

8. What fields are along the top of the import file?

Nightfly66:

Zen Cart v1.5.4 (PHP Version: 5.6.17 - MySQL 5.6.29)
Localization -> Languages: Italian/English

Easy Populate 4.0.33a - Beta 02-29-2016
Model/Price/Qty (with Specials)

I export two "v_products_model" and two "v_products_name"
I correct the stocks ("v_products_quantity" and "v_status"

I import the file and i see: "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"

Debug Log: "MySQLi error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'WHERE products_id = *** AND language_id = 3' at line 1
When executing: UPDATE products_description SET WHERE products_id = *** AND language_id = 3"

*** They are different ID

Why ? Any suggestions ?

Regards

Almost on second thought, how complete is the above SQL as compared to what was logged?

UPDATE products_description SET  WHERE products_id = *** AND language_id = 3

Other than the products_id being removed, was there anything else that was removed?

If the answer is no, then the solution is in modifying lines 2006-2009 from:

$result = ep_4_query($sql); 
                 if ($result) { 
                   zen_record_admin_activity('Updated product ' . (int) $v_products_id . ' description via EP4.', 'info'); 
                 } 
    

to:

            if ($update_count == true) {
                 $result = ep_4_query($sql); 
                 if ($result) { 
                   zen_record_admin_activity('Updated product ' . (int) $v_products_id . ' description via EP4.', 'info'); 
                 } 
            }
      

The reason for that "issue" is that in permitting the omission of the four fields associated with this section, the omission of all data in that section will result in a query that does not do anything. Because of the multi-language aspect, it is not "easy" to test for the need to run any of the insert/update in this section in advance to have the effort duplicated again within the section. But, if there is no data to be updated, then the query should not be executed. This should be accomplished by the above code change which will skip the update if there is nothing to be updated that relates to that section of the code...

mc12345678:

Request a little clarification and some additional information.

1. two v_products_model, does this mean two products that have a v_products_model or are there two fields along the top of the export file that have v_products_model as a field?

2. I understand two v_products_name to mean v_products_name_1 and v_products_name_2 are/might be fields though the second number could be other than 2. Please verify this is to what you were referring.

3. When exporting the product, what is/was the admin setting for the primary key, is it products_model, products_id or blank_new?

4. Same question for when importing.

5. What field(s) are in the user defined entry under admin/configuration/ep4?

6. The exported product, were there two or more rows that contained the same data in the v_products_model field? (Ie. either linked product or the same model applied to two different product?)

7. What fields are along the top of the export file?

8. What fields are along the top of the import file?

I will try to explain better with some examples:

1. Each product has a unique code (v_products_model) but each product has a unique code but this code is duplicated for the product name in English and the name of the product in Italian language (v_products_model)
2. I have twice the same product code associated with the same product model one by the name in Italian is the second with the name in English
   3/4) I do not have blank fields
3. With earlier versions, I have never had need to enter anything in the User Defined Fields Products
4. There may be some products linked in different categories
   7/8) v_products_model, v_products_name, v_status, v_specials_price, v_specials_price, v_specials_date_avail, v_specials_expires_date, v_products_price, v_products_quantity.

All fields are duplicates with the same values. The problem seems to be "v_products_nam"e which is in two languages

Sorry for my English. I hope I was clear in explaining

Regards

One quick, perhaps dumb question. Why did you move from v_category_name_1, v_category_name_2, etc. to using the caret? That, to me just complicates things having to use formulas and such instead of the old way.

wtashby:

One quick, perhaps dumb question. Why did you move from v_category_name_1, v_category_name_2, etc. to using the caret? That, to me just complicates things having to use formulas and such instead of the old way.

You mean, way back when why did chadderuski change up the method of assigning categories?

Well, there were two things at play from what I have seen throughout the thread and from looking at how it works. One was that there was the concept of multiple languages, so there had to be a method to apply that, then there was the "stack-up" of categories.. How many v_categories_name_x fields need to be added to address the multiple layers in which a product can exist? Then on top of that applying a second+ language at the same time...

So, as to the use of the caret (or other character as so desired), v_category_name_1 is the category name for the product in the row that is to be in the first language of the store (having language_id = 1), the category that it resides is main_cat1^sub_cat1^sub_sub_cat1^sub_sub_sub_cat1 Thus the product's category is fully defined in a single field.

This has been this way with EP4 for as long as I've known it (4+ years), so I'm curious about to what "old way" this is being compared.

Nightfly66:

I will try to explain better with some examples:

1. Each product has a unique code (v_products_model) but each product has a unique code but this code is duplicated for the product name in English and the name of the product in Italian language (v_products_model)
2. I have twice the same product code associated with the same product model one by the name in Italian is the second with the name in English
   3/4) I do not have blank fields
3. With earlier versions, I have never had need to enter anything in the User Defined Fields Products
4. There may be some products linked in different categories
   7/8) v_products_model, v_products_name, v_status, v_specials_price, v_specials_price, v_specials_date_avail, v_specials_expires_date, v_products_price, v_products_quantity.

All fields are duplicates with the same values. The problem seems to be "v_products_nam"e which is in two languages

Sorry for my English. I hope I was clear in explaining

Regards

No, your English is fine, I was however able to consider multiple ways that the information could be understood. I did not want to try to guess too much. :)

I have taken a look at the code and I have tested the changes. I have uploaded some more changes to 4.0.34 to https://github.com/mc12345678/EasyPopulate-4.0