Posted by beeradb on February 26, 2010 at 6:56pm
3 followers
| Project: | Sections |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
I've got a site which is exhibiting a strange bug. Sections works fine except for one specific instance, which is after a user logs in. Although I've been able to confirm that sections_in_section() returns the correct section, and the global $custom_theme variable is overwritten, the site default theme is displayed rather than theme returned by sections_in_section().
I've found that moving the code which overwrites the global $custom_theme into a hook_init implementation rather than doing it in hook_menu does cause the correct section to be displayed. Is there any reason this code isn't in hook_init() in the first place? I'd be happy to supply a patch if not.
Comments
#1
There was a reason, but I cannot remember it...
#2
Ok, this one was fun to track down. It's dependent on quite a few modules, so bear with me while I explain the situation.
After a user login securepages.module triggers a menu rebuild through its use of menu_get_active_item(). I'm not sure why this only effects securepages after a login, but it definitely does. That menu rebuild sets off a chain of events which will prevent sections from properly initializing the correct theme. That chain of events goes something like this:
I know this is an interesting mix of interactions, but sections, securepages, actions, and workflow are all fairly popular modules. It seems to me if hook_menu is going to be used for this, which it wouldn't be without architectural issues in D5, it makes sense to ensure this gets ran as early as possible in the page request. This is already done by setting the weight to -10, but I think it makes sense to also ensure this code gets ran before (nearly) anything else in hook_menu has a chance to initialize the theme system.
I've attached a patch which uses a static to ensure this fires on the first call of hook_menu. It's an ugly fix, but so is doing this kind of stuff in hook_menu in the first place. I don't see a good way around this, but I'm definitely open to input.
#3
bump. Have you had any chance to look at this yet? We've been using it in production for nearly a week now, and it looks to solve our issues.
#4
If it's a question of order, why not changing the modules order? Can you try this?
#5
Ok, I hope I remember correctly why I have not used hook_init().
In past i tried to make sections as much compatible with other modules as possible. The core "admin theme" feature was one reason. Over long time I learned how buggy the current core $custom_theme implementation is and... so often people like you had issues with themes not switching. I guess others have also understood this and this is why some people changed it in D7 (#553944: Define hook_menu_get_item_alter() as a reliable hook that runs before the page is doomed).
Debugging this type of issues is not really fun and very difficult and in december I decided to go a different way. The D6 version of sections has been changed to fire init_theme() in hook_init(). By this - I make sure that sections *always* wins, whatever any other modules does - I do not care any longer. If you need a module that works 100% reliable on theme switching you can only have one module that changes the themes or you may end in compatibility issues between modules like you. For this reason I implemented the core admin theme feature as a special "section" in sections module. If other modules like to switch, they need to create a section in sections module or they are not able to switch.
Before I was able to go this hard way I disabled the core admin theme feature if sections is enabled, see http://drupal.org/cvs?commit=301594 and http://drupal.org/cvs?commit=302012. In past it was required for some strange compatibilty reasons to set the $custom_theme variable in menu no cache section. As we no longer care about module compatibility we could move it now to hook_init() in D5, too. I guess we may see some people reporting this as bug, but who cares.
#6
Could you give this patch a try, please?
#7
The patch submitted by beeradb at #2 has fixed an ongoing issue I've had with Sections and other theme switching modules. Basically default theme keeps showing through - particularly after editing or submitting nodes - but sometimes randomly. After applying beeradb's patch these issues appear to be gone.
Thank you beeradb !!!!
I did try patch #6 but I get WSOD.
#8