EasyPopulate 4.0 Support Thread

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

[mc12345678]

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';

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

[mc12345678]

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);

from the EP4 file would be the way to pull the desired information. This information would become available when using EP4, which could be used to populate whatever is desired to use for tracking:
"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.

[mc12345678]

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

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

[mc12345678]

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)

[wtfbbq]

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?

[mc12345678]

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.

[mc12345678]

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.