Posted by redijedi on June 15, 2009 at 9:49am
Jump to:
| Project: | me aliases |
| Version: | 6.x-2.7 |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
I disabled the me module and now my site is completely unresponsive. Goes directly to a blank screen. I can access the install.php, update.php, etc. Everything else is just blank white. This is the most terrible bug ever.
Comments
#1
I'm going to need more information than this. I turn the module on and off all the time during development, and I've never come into a problem.
What do your error logs say? Is there any errors messages there?
#2
There are no messages. I've found that I had to truncate all the cache_x tables, then go to the update page. Oddly, simply truncating the tables is not enough. I have to run the update. After the update runs everything is back to normal. I've tried this multiple times now and it is consistent. It could be a bad interaction with another module, but I have too many modules to go through every possible combination.
#3
Ok. If you ever figure it out, I'd be curious to know. It is strange that it gives a white screen with no indication of error. Have you set "log_errors" in your php.ini?
In any event, I don't think this is a problem with me. Seems more like another module is running some code or gathering information from the menu system before it is actually re-built and not caching it properly. That's about the only thing I think it can be.
#4
I had a client report the same behavior on a site and found that clearing the menu cache once me.module is resolves the problem. In the php error log we have
Call to undefined function me_uid_optional_to_arg() in menu.inc on line 608.
It seems like me_menu_alter's actions need to be undone in an implementation of hook_disable. We can't simply do a cache_clear all in me_disable because this will happen while the module is still enabled, thus leaving behind the same invalid menu links.
#5
Thanks. I'll certainly try and look into this very soon.
#6
yup, same errors and running update.php fixes it.. my guess is update must do a menu_rebuild which clears all the me_to_arg like entries from the menu_router table.
#7
It's an interesting issue, and I'd call it either a core bug, or something that module maintainers should be made aware of, especially when using hook_menu_alter(). The issue I think stems from the fact that when a module is disabled, the menu is rebuilt on the same request, however at this point, the disabled module is still loaded in memory, so it's hooks run and adjust the menu system, and then once drupal does its redirect, the menu cache is actually invalid, and should be built again.
I haven't confirmed that this is the problem, but it is the only thing that makes sense. Perhaps a solution similar to what node access modules need to use when they are being disabled needs to be employed for the menu system also.
#8
For the record, I got this on 7.x beta2. The error message was "Fatal error: Call to undefined function me_to_arg() in [...]\includes\menu.inc on line 799"
Additionally, the solution mentioned in #2 is not working in my case and right now I'm not sure how to get the site working.
#9
For the record (again) I solved my problem above like this:
UPDATE menu_router SET to_arg_functions = '' WHERE path LIKE 'user/\%%'#10
I disabled the me module using drupal, had no issues. But when I disabled it using drush, I got
Call to undefined function me_to_arg() in /home/rahul/d7/includes/menu.inc on line 797. The error seems to be with drush. You should rundrush updbafterdrush dis me#11
I don't use Drush so it can't be Drush solely.