EasyPopulate 4.0 Support Thread

[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

[mc12345678]

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.

[mesnitu]

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/mc12345...e-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.

[mc12345678]

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/mc12345...e-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?

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

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

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