EasyPopulate 4.0 Support Thread

Russalpcs:

I think I found the problem - on my old website the value of Categories_description in the NULL column is set to NO, on the new website it is set to YES?

Russalpcs:

So this new patch fixes this issue?

Right question for the wrong issue.

The patch will eliminate the blank screen that was received because of the programming error (missing a character). It will eliminate the debug log provided earlier about not having a default value for categories_description.

The "issue" described by the two above posts was the difference between the settings of the categories_description between the old and new sites. The value or setting in question is whether the field categories_description can or can not be set to null. Neither of those settings identifies a default value, just the allowance of the value to be null or not.

The patch provided ensures that when creating a row of category data that the categories_description field will have content. Under the "old" database that content had to be something other than null. Now in the new database it could be null. In both cases, basically there should have always been something sent. The value being sent now with the patch is an empty set of quotes: ''.

So, will the patch change the settings of your database? No, that was never the intent. The patch is to provide some default value for new categories because Zen Cart doesn't need to have such a default value during normal operation, therefore there hasn't been one assigned.

My host changed the setting of "STRICT_TRANS_TABLES" off, now it uploads perfectly!

Russalpcs:

My host changed the setting of "STRICT_TRANS_TABLES" off, now it uploads perfectly!

So was that executed with the patch installed or the originally distributed 4.0.36 version?

Hi
Warning: Feature Request

Wouldn't be nice to public declare the EP4 version so other modules could know what version is installed ?
Right now, it's only declared var $curver, but only available inside easypopulate_4.php ( as I can tell)

I'm working on getting update info from git latest releases using the git api. But to compare, I don't know what version is presently installed ( without of course, editing manually the file).
Because I use Bookx -> that uses ep4bookx -> that uses ep4, it's a way to know if git updates are available, also choosing the fork ro branch ( and pretending that I don't know the updates on ep4book)

...actually, it would be a good practice for every module to announce "publicly" to others, that is there ( just the version) ... I think.

Some define() or database-> configuration only in "read mode"...

Thanks

mesnitu:

Hi
Warning: Feature Request

Wouldn't be nice to public declare the EP4 version so other modules could know what version is installed ?
Right now, it's only declared var $curver, but only available inside easypopulate_4.php ( as I can tell)

I'm working on getting update info from git latest releases using the git api. But to compare, I don't know what version is presently installed ( without of course, editing manually the file).
Because I use Bookx -> that uses ep4bookx -> that uses ep4, it's a way to know if git updates are available, also choosing the fork ro branch ( and pretending that I don't know the updates on ep4book)

...actually, it would be a good practice for every module to announce "publicly" to others, that is there ( just the version) ... I think.

Some define() or database-> configuration only in "read mode"...

Thanks
Not entirely sure what the need is.

The version information is kept up in the base file: admin/easypopulate_4.php, that when processed provides a local notification of an update being available from the ZC site. There is a notifier that follows the version information where it would be possible to determine what the current installed version is and whether a new version is available based on $new_version_details ¡== False.

It sounds like though that the ep4bookx module requires ep4, so as I said, I'm not sure I understand the need of adding something to the database that is available during normal operation. If some other software somewhere is to know about the version change outside of the use of EP4, then sure would think a database field would be the "easiest" to maintain and make available. Both that or a file with a define generally involve loading that information with each page load, regardless of the application being loaded. It's of little impact with a single item, but many single items make a big item.

Now, if want to understand more about how to capture that information during the use of EP4, can easily offer that information. Last I looked at the EP4bookx portion of the mod, there were some areas of potential coding improvement to make it a little easier to maintain and to modify.

mc12345678:

Not entirely sure what the need is.
The version information is kept up in the base file: admin/easypopulate_4.php, **that when processed **

That's it. When is not processed, there's no way to know what version is installed.

Example: I can check https://api.github.com/repos/mc12345678/EasyPopulate-4.0/releases
And get / chose all that info about release updates or even use a different fork url, etc...
But with no zencart information about what version is installed ( file or database), I can't compare if there's a update or not.
I'm working on Bookx module that doesn't process ep4, but (in my case) uses ep4 heavily through ep4bookx, it's a way to know on bookx tools panel IF there's some changes on the modules he uses.

"ep4": {
"installed": "",
"url": "",
"html_url": null,
"last_release": null
},
I can get all the other info, but I can't compare.

mesnitu:

That's it. When is not processed, there's no way to know what version is installed.

Example: I can check https://api.github.com/repos/mc12345678/EasyPopulate-4.0/releases
And get / chose all that info about release updates or even use a different fork url, etc...
But with no zencart information about what version is installed ( file or database), I can't compare if there's a update or not.
I'm working on Bookx module that doesn't process ep4, but (in my case) uses ep4 heavily through ep4bookx, it's a way to know on bookx tools panel IF there's some changes on the modules he uses.

"ep4": {
"installed": "",
"url": "",
"html_url": null,
"last_release": null
},
I can get all the other info, but I can't compare.

So let me ask this, can the bookx tools panel exist without EP4 being installed?
Where is the above additional array being kept, if at all?

Well.... the world could live happily without this, but for some reason, I've went this way ( complicating again) , but this is want I want to achieve, and I'm achieving, but to compare releases, I need to know what version is install.
Note: Of course I cant write the version, using ftp, notepad++
For the thousands and thousands of bookx users, the universe needs this :laugh::laugh:

For now, if there's a new release, it's a link to the relelase link... but it couls also download the zip tarball or , ( since ep4 / ep4bookx) don't change any admin files, it could be extended to install ... but that's not my goal for now.
Just to know if there's an update and why.

I'm thinking that I could create a file that could be commonly pulled from outside software as well as EP4 to provide the version information instead of a database or always loaded define. That way there is no additional burden to the remainder of the site other than the existence of an additional file. Would likely place as a module file. Consider the use of

admin/includes/modules/easypopulate_4_version.php

With the processing contents of something like the existing line in the base module:

<?php
/**
 * Header related information to describe the relationship to EasyPopulate 4
 * @author mc12345678 https://mc12345678.com
 **/

$curver_detail = '4.0.36';

And then the easypopulate_4.php file where that line exists to be changed to:

require DIR_WS_MODULES . 'easypopulate_4_version.php';

Yeap, that would be nice, Thanks.
Like I said, I actually haven't dig into how or if other modules declared that they are present, but I think it's nice.
No need to add extra info all over the place, but saying: module x.x.x is present.
ok thanks.

mesnitu:

For now, if there's a new release, it's a link to the relelase link... but it couls also download the zip tarball or , ( since ep4 / ep4bookx) don't change any admin files, it could be extended to install ... but that's not my goal for now.
Just to know if there's an update and why.

Oh, so you're wanting to know when there is a github update without concern about a Zen Cart update?

If using the github information, understand that while I've been using that as a feature to provide information to those following github, at least when I use the release section, it is to identify a version that is provided to Zen Cart, typically with the same content as was submitted to Zen Cart (basically keeping the same information in two places). But that doesn't mean that such an action will always occur and doesn't really resolve the issue of updates of some minor level being provided before a release... Seems it would be better for you if that is the goal to possibly track the commit number that was used to download/compare your software and whatever information is available about the difference in that and the master to see if there is an update that was made in github...

The name used in the github release is different than the version information made available through the ZC download, and while the goal is to maintain consistency, there is no requirement at least on the github side.

Just thinking that using ```
$new_version_details = plugin_version_check_for_updates(2069, $curver_detail);

"ep4": {
        "installed": "", 
        "url": "",
        "html_url": null,
        "last_release": null
    },
... If the program is installed and the field is not populated, then direct user to access the program one time and come back to the "panel".  Now the panel is up-to-date because the program was accessed and populated the desired field.

Or using the thought above of an admin/easypopulate_4_version.php file can reproduce the operation performed in admin/easypopulate_4.php to pull from the ZC server if an update is available.  That is unless the "direction" of ZC plugin version information is expected to be in the database then... I've just been trying to keep this to have a relatively low profile with interface to the database only necessary to support it's database operations.

mesnitu:

Yeap, that would be nice, Thanks.
Like I said, I actually haven't dig into how or if other modules declared that they are present, but I think it's nice.
No need to add extra info all over the place, but saying: module x.x.x is present.
ok thanks.

No problem.

Note though that the simple string like '4.0.36' is not the same as the github title of: EasyPopulate V4 4.0.36 ZC Release, or the tag of: v4.0.36.ZC

Will have to account for those differences in your comparison if using the github information...

Yeap, I see what you mean. I've add a section to change the git api urls to track fork updates. So it's up to the user ( me ) to choose.
So it simple gathers the latest release from the release page of his ( my ) choice.

However, while giving the information that one can use ep4 to facilitate products management, IF ep4 is not installed or git url is empty, it's silent.

About zencart plugin download section.... yes, if someone downloads from there and the version name (don't know how it works), ( tag_name in git), is different, it will say that there's an update... and that's wrong info, or wrong source info. So a no no situation.

That's why I want to start with a empty json file (except for bookx it self).
If a module git api url is posted ( in a form), I guess it means that a user ( me ), wants to use that repository. Then I guess it makes sense to say there's a update, even if that info is not entirely correct, but server the purpose of change to that repository track.

But, yes, not very good.

I'll have to check that plugin_version_check_for_updates function to see what comes up.

mesnitu:

Yeap, I see what you mean. I've add a section to change the git api urls to track fork updates. So it's up to the user ( me ) to choose.
So it simple gathers the latest release from the release page of his ( my ) choice.

However, while giving the information that one can use ep4 to facilitate products management, IF ep4 is not installed or git url is empty, it's silent.

About zencart plugin download section.... yes, if someone downloads from there and the version name (don't know how it works), ( tag_name in git), is different, it will say that there's an update... and that's wrong info, or wrong source info. So a no no situation.

That's why I want to start with a empty json file (except for bookx it self).
If a module git api url is posted ( in a form), I guess it means that a user ( me ), wants to use that repository. Then I guess it makes sense to say there's a update, even if that info is not entirely correct, but server the purpose of change to that repository track.

But, yes, not very good.

I'll have to check that plugin_version_check_for_updates function to see what comes up.

Easiest way to check its output, is to change the version number in your EP4 file to less than the current, then possibly add say at line 89:

trigger_error('version response data: ' . print_r($new_version_details, true), E_USER_WARNING);

then could change it back to 4.0.36 and run it to see what the resulting log file has, then remove the content from that line. (Line 89 was blank in version 4.0.36)

I'm still getting this error from a freshly exported csv. The database was updated and I tried uninstalling and reinstalling the plugin.
Any ideas to fix this?

Can you show at least the first two lines of your raw csv?

The "import error" is a result of not finding that the csv has "consistent" separators matching those supported by the code. By separator I mean comma, tab, semi-colon, etc... between each field.

Note also, if I remember correctly that detection was only added to the github repo where there may still be an issue with importing categories. I've been trying over the last couple of weeks to flush that out; however, the distribution of ZC 1.5.6 has taken up much of my time. :(

v_products_model,v_products_type,v_products_image,v_products_name_1,v_products_description_1,v_products_url_1,v_specials_price,v_specials_date_avail,v_specials_expires_date,v_products_price,v_products_weight,v_product_is_call,v_products_sort_order,v_products_quantity_order_min,v_products_quantity_order_units,v_products_priced_by_attribute,v_product_is_always_free_shipping,v_date_avail,v_date_added,v_products_quantity,v_manufacturers_name,v_categories_name_1,v_tax_class_title,v_status,v_metatags_products_name_status,v_metatags_title_status,v_metatags_model_status,v_metatags_price_status,v_metatags_title_tagline_status,v_metatags_title_1,v_metatags_keywords_1,v_metatags_description_1
"1T8302 MSP","1","engine/aclbearings.jpg","ACL Thrust Washer Set Mazdaspeed Protege","","","","","","4","1","0","0","1","1","0","0","","2017-10-28 08:28:00","8","ACL Bearing","Mazdaspeed^Mazdaspeed Protege 2003-03.5^Engine^Engine Bearings","Taxable Goods","1","0","0","0","0","0","","",""
"4B8300 MSP","1","engine/aclbearings.jpg","ACL Rod Bearing Set Mazdaspeed Protege","ACL Aluglide aluminum.","","","","","26.43","1","0","0","1","1","0","0","","2017-10-28 08:28:00","8","ACL Bearing","Mazdaspeed^Mazdaspeed Protege 2003-03.5^Engine^Engine Bearings","Taxable Goods","1","0","0","0","0","0","","",""
"5M8302 MSP","1","engine/aclbearings.jpg","ACL Main Bearing Set Mazdaspeed Protege","ACL Aluglide aluminum.","","","","","50.5","1","0","0","1","1","0","0","","2017-10-28 08:28:00","8","ACL Bearing","Mazdaspeed^Mazdaspeed Protege 2003-03.5^Engine^Engine Bearings","Taxable Goods","1","0","0","0","0","0","","",""

wtfbbq:

v_products_model,v_products_type,v_products_image,v_products_name_1,v_products_description_1,v_products_url_1,v_specials_price,v_specials_date_avail,v_specials_expires_date,v_products_price,v_products_weight,v_product_is_call,v_products_sort_order,v_products_quantity_order_min,v_products_quantity_order_units,v_products_priced_by_attribute,v_product_is_always_free_shipping,v_date_avail,v_date_added,v_products_quantity,v_manufacturers_name,v_categories_name_1,v_tax_class_title,v_status,v_metatags_products_name_status,v_metatags_title_status,v_metatags_model_status,v_metatags_price_status,v_metatags_title_tagline_status,v_metatags_title_1,v_metatags_keywords_1,v_metatags_description_1
"1T8302 MSP","1","engine/aclbearings.jpg","ACL Thrust Washer Set Mazdaspeed Protege","","","","","","4","1","0","0","1","1","0","0","","2017-10-28 08:28:00","8","ACL Bearing","Mazdaspeed^Mazdaspeed Protege 2003-03.5^Engine^Engine Bearings","Taxable Goods","1","0","0","0","0","0","","",""
"4B8300 MSP","1","engine/aclbearings.jpg","ACL Rod Bearing Set Mazdaspeed Protege","ACL Aluglide aluminum.","","","","","26.43","1","0","0","1","1","0","0","","2017-10-28 08:28:00","8","ACL Bearing","Mazdaspeed^Mazdaspeed Protege 2003-03.5^Engine^Engine Bearings","Taxable Goods","1","0","0","0","0","0","","",""
"5M8302 MSP","1","engine/aclbearings.jpg","ACL Main Bearing Set Mazdaspeed Protege","ACL Aluglide aluminum.","","","","","50.5","1","0","0","1","1","0","0","","2017-10-28 08:28:00","8","ACL Bearing","Mazdaspeed^Mazdaspeed Protege 2003-03.5^Engine^Engine Bearings","Taxable Goods","1","0","0","0","0","0","","",""

Are you able to tell when you downloaded the software? The above content visually looks right. I'm wondering if there was a logic error in the version obtained where the error was displayed for a file that met the conditions and not when it didn't.