EasyPopulate 4.0 Support Thread

[SPython]

Also deleted Zencart and the mysql database, Reinstalled Zencart and a new mysql database. Then installed Easy Populate 4.0 Same segfault. Is there a manual way to initialize Easy Populate or is there a more recent version?

[mc12345678]

The update check in Zen Cart works as does everything else. When I click on Tools/Easy Populate it throws a series of this in the main server error logs:
[core:notice] [pid 14902:tid 3086542528] AH00052: child pid 17380 exit signal Segmentation fault (11)
A thought - where does Easy Populate store its keys? In the user's zencart directory, in the mysql database, or elsewhere on the server? When I reinstalled zencart and then Easy Populate I did not remove the keys from the previous configuration. (I was unable to access the admin.) Could this be the problem?

The only database edit made by installing the files to the server for EP4 is the registration of the admin page as provided by admin/includes/functions/extra_functions/reg_easypopulate_4.php

The next database editing performed is what is done when the install link is selected at the top of the screen once the EasyPopulate v4 tools menu option has been selected. From the sounds of it, this action was previously performed on the database when the error was presented regarding the category name length being too long (an issue identified several times in the last couple of pages with a solution also given).

If the store files were rebuilt on the same database, and EP4 reuploaded, then all of the database data would still be in place to support continued use.

The database install script (run the first time EP4 was installed to whatever database was used) is found in the admin/includes/functions/extra_functions/easypopulate_4_functions.php file. There is also a function that does a remove in the same file. Assuming that nothing in admin/easypopulate_4.php is causing the error on this system before the install/remove code in that file, then the remove option could be put on the url to try to execute the removal code.

That said, there are no files stored to the system by the code other than export of a csv that contains database information or a debug text file when attempting to process information in or out of the database. All settings are stored in the configuration table (with applicable database prefix) other than the registration of admin windows like in the first file mentioned. All initial database modifications are covered in that install function of the file described above. There are two functions adjacent to that one which will "monitor" the location of the temporary file to attempt to not have the admin directory name stored in the database.

If more detailed instruction/description is desired, I'll have to dig deeper, but it would also help to understand more about the history of the current database and if there is anything more direct that can be provided as to the log(s) of issues.

Lastly, I just did an Internet search on "exit signal segmentation fault (11)" and things pointed back to server setup, php.ini, thread/child node behavior, and a number of other things, but typically not the original php code. :/

As to "more recent" the patches identified here in the thread related to the version downloadable from the ZC website have been applied to the github version that I maintain while I continue to work on a few other branches to apply the next set of features.

[SPython]

Thank you for your advice and taking time with this. When I run strace on easypopulate_4.php it throws this error:
write(1, "ERROR: admin/includes/configure."..., 89ERROR: admin/includes/configure.php file not found. Suggest running zc_install/index.php?) = 89

Should I assume that it does not know where the (renamed) admin directory is? configure.php is there in the includes directory. What permissions should it be?

[mc12345678]

Thank you for your advice and taking time with this. When I run strace on easypopulate_4.php it throws this error:
write(1, "ERROR: admin/includes/configure."..., 89ERROR: admin/includes/configure.php file not found. Suggest running zc_install/index.php?) = 89

Should I assume that it does not know where the (renamed) admin directory is? configure.php is there in the includes directory. What permissions should it be?

Typical permissions upon install are 644 for the admin/includes/configure.php file, with suggestion to set to 444 to prevent writing/rewriting. EP4 doesn't modify this file and is only pulled for use by including application_top.php which loads the admin configure.php file. Perhaps something is amiss with the file? But this also further doesn't exactly make sense if this plugin is the only admin tool that is causing this issue. :/

One of the suggestions I came across was to tie to the parent process that appears to be causing the issue and as part of that tie to include a back trace logged error to identify where in execution the error is truly occurring. :/

[mc12345678]

While this may come as a shock to some/many and with considerable thought, today a different plugin that performs the same actions as EP4 has been submitted as well a different plugin with no collaboration to develop or consider as a straight replacement for EP4. As some of the heavy hitting plugins have previously gone with multiple variants, I do not see that such a thing should continue to occur. While I have not performed any testing of this new plugin, I have no doubt that any issues (if they exist) will be rectified. I have already notified the original author of EP4 of my concerns. I am further aware that it doesn't include the SBA added functionality of EP4, but that can and will be addressed separately as well as other developed plugins.

Because that plugin has been so developed and it offers additional fields the ability of which is not built into EP4 at this time, I call to you the user community about the specific need of EP4 although some of the other features identified in that plugin can and were to be added to EP4.

For those long-term Zenners, think back on the history of Stock-by-Attributes and the multiple variants that existed... This history doesn't need to be repeated.

I expect that plugin to be available by the end of the weekend. Meanwhile I probably will submit a final version that incorporates the bug fixes of the last couple of pages and continue to support the community in other ways unless some compelling reason exists for two individuals to support two different plugins that ultimately do the same thing.

[Zean]

While this may come as a shock to some/many and with considerable thought, today a different plugin that performs the same actions as EP4 has been submitted as well a different plugin with no collaboration to develop or consider as a straight replacement for EP4. As some of the heavy hitting plugins have previously gone with multiple variants, I do not see that such a thing should continue to occur. While I have not performed any testing of this new plugin, I have no doubt that any issues (if they exist) will be rectified. I have already notified the original author of EP4 of my concerns. I am further aware that it doesn't include the SBA added functionality of EP4, but that can and will be addressed separately as well as other developed plugins.

Because that plugin has been so developed and it offers additional fields the ability of which is not built into EP4 at this time, I call to you the user community about the specific need of EP4 although some of the other features identified in that plugin can and were to be added to EP4.

For those long-term Zenners, think back on the history of Stock-by-Attributes and the multiple variants that existed... This history doesn't need to be repeated.

I expect that plugin to be available by the end of the weekend. Meanwhile I probably will submit a final version that incorporates the bug fixes of the last couple of pages and continue to support the community in other ways unless some compelling reason exists for two individuals to support two different plugins that ultimately do the same thing.

Thanks for the heads-up. I'm excited to see it since you seem to be saying the "different plugin" "offers additional fields."
I'm hoping it offers the SORT ORDER fields I had to give up on as explained here

https://www.zen-cart.com/showthread....54#post1312654

[mc12345678]

Thanks for the heads-up. I'm excited to see it since you seem to be saying the "different plugin" "offers additional fields."
I'm hoping it offers the SORT ORDER fields I had to give up on as explained here

https://www.zen-cart.com/showthread....54#post1312654

Don't know. Unfortunately I had a detailed response for you, but in reply to someone else I lost it and didn't go back to recreate it. One of the sort orders though is already available in the categories import/export if I remember correctly, just not in the products list. As I recall also, one of the desired sort orders to be included/listed in conjunction with other data would have caused a sequencing issue without extensive rewrite for something covered in a separate area that is/was specifically designed to address that aspect.

For more information about the other plugin look through recent posts and maybe even reach out to lankeeyankee. As has come customary of most recent public plugins, the code can be previewed/downloaded from github.

The biggest difference I have seen is 1) good luck writing your own set of code to accomplish larger tasks, 2) get to know your specific import file because you will have to "choose" between various import options based on how the file was generated which may not be a big issue if one always follows the same process for each file, 3) supposedly the export auto_expands to include multiple fields rather than them being considered/added to the filter(s).

Haven't looked deeply at the import process but did seem some limiting factors related to number of fields, so hoping for those that like to otherwise limit the number of fields on which they upload that they can still do that.

One thing that really shouldn't surprise me is that one question has already been asked from the perspective of an action to be "incorporated" and pointed out as a "problem" of EP4, but has not as I have seen it been a requested feature or modification of EP4. Too bad, like many of the other improvements that were going to be made, such an additional option could have been added to EP4 upon request. My plan is to document possible improvements or the planned mods for EP4 in the original developers area. As said before I took this up because it had great promise, was functional, and support could not be provided by the original author because of other commitments. Further other EP products were non-functional out-of-the-box, didn't offer the same breadth of options, and were too rigid in their construct. This plugin has been around for 4 years, although only recently uploaded to ZC and apparently there remain mainy users that don't read the documentation and have gotten their sites into some trouble as a result (mostly related to the CHAR_SET being wrong between EP4 (strictly has been using UTF-8) and the site (possibly likely latin1) which was also something that was going to be addressed, but another no-need at this point).

Floor is still open on the topic of EP4, but other than the absence of SBA related items, which I seriously doubt would be included by the author because of a conflict of interest in their own commercial product, it seems to me to be the same thing just another variant. Such variants are expected to be minimized in and by the ZC community.

[mesnitu]

Hi
Is the manufactures_info getting the same ID's that manufactures ID table ?
This has been reported here ( well....more or less )

https://www.zen-cart.com/showthread....ML-v-2/page168

After doing some checking , I'm getting different ID's ....
so the $v_manufacturers_id = ($ep_uses_mysqli ? mysqli_insert_id($db->link) : mysql_insert_id()); is getting a higher number

Anyone else with this issue ?
(Note to mc12345678 : in this case, I'm importing the full EP4 file, no books )

[mesnitu]

Well , the only way I can get this to work is like this :
around line 1668

 $v_manufacturers_id = ($ep_uses_mysqli ? mysqli_insert_id($db->link) : mysql_insert_id()); // id is auto_increment, so can use this function

            if ($result) {
              zen_record_admin_activity('Inserted manufacturer ' . addslashes($v_manufacturers_name) . ' via EP4.', 'info');
            } 

I guess the record_admin_activity is inserting also, and probably that's the ID that the manufacturer_info gets....
So the mysqli_insert_id($db->link) should be above that zen_record_etc function,,,,

[mc12345678]

Well , the only way I can get this to work is like this :
around line 1668

 $v_manufacturers_id = ($ep_uses_mysqli ? mysqli_insert_id($db->link) : mysql_insert_id()); // id is auto_increment, so can use this function

            if ($result) {
              zen_record_admin_activity('Inserted manufacturer ' . addslashes($v_manufacturers_name) . ' via EP4.', 'info');
            } 

I guess the record_admin_activity is inserting also, and probably that's the ID that the manufacturer_info gets....
So the mysqli_insert_id($db->link) should be above that zen_record_etc function,,,,

Correct. The collection of the insertid should always be before any potential access of the database, which of course was supposedly already corrected, but apparently not. Will try to modify the location today, but if done earlier rather than later it will be directly in github which has the potential of being incorrectly typed because there is no copy and paste capability when directly entered. The fix path will be posted here for those stil using this.