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?

So this new patch fixes this issue?

[mc12345678]

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?

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.

[Russalpcs]

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

[mc12345678]

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?

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