BobRay
I will try your suggestion later today. This is a really strange matter.
Will keep you informed – thanks a lot.
By the way, your book is great, thanks a lot for that too.
Thanks BobRay
your suggestion worked. I've replaced these folders/documents then cleared the cache and the manager was working again. However somehow a bad feeling remains. I would love to know what caused this problem.
Thanks again!
I think you are probably on safe ground. Some file was missing and it's not missing any more. Except for the core/config, core/cache and core/components directories, those directories never change except during upgrades to a new version, so you shouldn't have to worry that something in them will cause trouble later.
I've never had this happen with an uninstall of any component, so hopefully you'll never see the problem again.
Out of curiosity, do you still have a google-analytics directory (not sure what it's called) under core/components or assets/components?
Thanks for buying the book.
BobRay
there is now such directory anymore. I am actually convinced it was that component I installed. So on right click delete, there must something have gone wrong. I have not deleted any files or directories manually. When I have the time I will install that thing again to see what it does.
Thanks again!
-
☆ A M B ☆
- 1,780 Posts
Well hey...
This is the exact problem I created for myself last night after uninstalling Google Analytics. The login page is now showing this error:
Fatal error: require() [function.require]: Failed opening required 'C:/xampp/htdocs/mapleleaf/manager/controllers/analytics/security/login.php' (include_path='.;C:\xampp\php\PEAR') in C:\xampp\htdocs\mapleleaf\core\model\modx\modmanagerrequest.class.php on line 104
I've re-run setup as was suggested (and worked for bbeer). No change. It's still trying to call up the analytics theme for login, which doesn't exist because I uninstalled the package.
Thank you for any assistance.
Edit:: This seems to have been solved by editing manager_theme field in the manager_settings table. It was still pointing to "analytics". I changed it to "default" and have been granted access to the manager again. I don't know much if anything about packages or how they're uninstalled but it would seem to be that there's something missing from the uninstall process that would remove "analytics" from the field and replace it with "default".
?
[ed. note: frogabog last edited this post 14 years, 10 months ago.]
-
☆ A M B ☆
- 1,780 Posts
Unfortunately, that did not solve the problem. I was very hopeful when I found this thread and applied your solution, but nothing changed.
What worked was editing manager_theme field in the manager_settings table back to "default" (see "Edit::" in my post above).
As to why it occurs... it seems that in my case at least, something in the uninstall forgot to tell MODx to set the field back to "default". Leaving "analytics" in the manager_theme field, which of course after uninstall MODx could not locate.
This particular MODx installation is less than a week old on my local server, running 2.1.5-pl. What version did you use to re-run setup? Someone with more knowledge about package management might be able to shed some light on why the uninstall process isn't complete. I guess my question is, does MODx control uninstall of packages or does the package itself control it? Why did you succeed with simply re-loading the setup, yet I had to manually edit the setting? Did I even need to re-load?
Did you run Setup? That might be the difference.
As for packages, there's no practical way to police what happens during uninstallation, so we just have to rely on people to report bugs and encourage the package author to fix them.
-
☆ A M B ☆
- 1,780 Posts
Quote from: BobRay at Dec 01, 2011, 01:19 PMDid you run Setup? That might be the difference.
Yep. That's why I posted to this thread in the first place. Running setup made absolutely no difference. It kept the theme setting which I expect is sop. One wouldn't want to have a pre-set manager theme revert back to default every time they upgrade of course.
I do wish I'd thought to check the setting in the db before running setup. I don't know if the setting was the only problem or if setup actually did need to be run. dangit...
My guess is that just changing the setting and clearing the cache would have done it.
