EasyPopulate 4.0 Support Thread

[mesnitu]

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

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

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.

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