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