EasyPopulate 4.0 Support Thread

[mc12345678]

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

[marcopolo]

I'm still on v1.5.4

[mc12345678]

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.

[marcopolo]

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.

[mc12345678]

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_admint...r19-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...

[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

[mc12345678]

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?

[mc12345678]

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...

[Nightfly66]

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
5) With earlier versions, I have never had need to enter anything in the User Defined Fields Products
6) 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

[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.