Manually deleted add-on package; now "Add Block" doesn't work
So now when I try to edit my site pages by adding a block, I get:
Warning: require_once(/home2/summite4/public_html/packages/gnt_mathjax/blocks/gnt_mathjax/controller.php): failed to open stream: No such file or directory in/home2/summite4/public_html/updates/concrete188.8.131.52_updater/concrete/core/libraries/loader.phpon line 217 Fatal error: require_once(): Failed opening required '/home2/summite4/public_html/packages/gnt_mathjax/blocks/gnt_mathjax/controller.php' (include_path='/home2/summite4/public_html/libraries/3rdparty:/home2/summite4/public_html/updates/concrete184.108.40.206_updater/concrete/libraries/3rdparty:.:/usr/php/54/usr/lib64:/usr/php/54/usr/share/pear') in/home2/summite4/public_html/updates/concrete220.127.116.11_updater/concrete/core/libraries/loader.phpon line 217
Clearly the Concrete5 installation I have still thinks the package is there, tries to look for it, can't find it, and gives up.
What to do?
As can be seen from the above snippet, I am currently running 18.104.22.168 - if I update to 22.214.171.124, would that fix my issue? I am wary of getting my hands any further involved and really mucking things up, so I am hoping for a relatively easy solution that is not too complicated to implement.
Any tips or advice appreciated ~
After putting it back - you 'should' be able to uninstall the package - failing that you can track the blocks down and remove them perhaps...
Is there any way to clean things up manually? What do I look for in trying to eliminate whatever is necessary so Concrete5 will quit looking for components that no longer exist?
the add on is this one by the looks of it:
Grab a copy and put it in your /packages directory. This should get you to the point where you can add blocks normally.
If, at that point there are issues with uninstalling that add-on then that will need looking into - but at least your site will be working.
You could manually try and delete references to this package and blocks etc from the db but you might end up in a worse state.
If the db actually had referential integrity in it (foreign keys), that would be a breeze, but it doesn't... which is very curious to me why they decided to keep the data in a totally unrelated state. was it for speed or some other 'good' reason? It would have to be a pretty good reason to disregarding the integrity of the data. Can anyone shed light on this?
As of now, I have no idea where to look for clues as to why it will not unintiall. Nothing the the server or db logs, no error messages. Especially with packe installations and upgrades, many fatal errors are not reported, so I kind of stuck as to how to debug this. Any suggestions?
I ended up poking around in my c5 database and locating tables related to the manually deleted package. This made it so the "add block" script quit looking for the non-existent package, and now I have no further problems to add blocks.