EasyPopulate 4.0 Support Thread

Quote:

---

Originally Posted by Russalpcs

Maybe the error is that I used Softaculous to load the new site? After I have updated the stock on my old site to list new adverts on Bid or Buy for the next week I will load another v156 from a direct download and see if I get the same errors

---

Well, that method doesn't exactly help things other than allowing those in the forum to possibly discover more quickly the errors with their installation package. One thing of note, whenever a screen goes blank there is likely an error message related to it in the logs folder. While total time to move an existing installation out of the way to discovery of a missing parentheses by execution of the code (would have likely been faster just to look at the patch itself) was about 20 minutes, I have pushed the revised patch to: https://github.com/mc12345678/EasyPo...n_import_patch

The issue is definitely a missing sql assignment when adding a new category. Again it was something that has existed in this software since before I started helping with it, but systems had generally been flexible enough to understand what to do and not cause a problem, but now are becoming stricter (which is good overall). Unfortunately users had not been making the issue known so changes could not be made for a problem not described... It has been addressed in an upcoming release and the above patch has been verified to work. Of course there are a number of things to be done with that code to tighten it up, but that's addressed in the next release.

Quote:

---

Originally Posted by 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?

Quote:

---

Originally Posted by 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?

---

Quote:

---

Originally Posted by 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!

Quote:

---

Originally Posted by 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

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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/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.

Quote:

---

Originally Posted by 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/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?

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:
Attachment 18253