Conflicts with contrib modules that call theme() too early

sections.module does not work for me too
but I can't confirm that this patch fixes the problem

still does not work for me with the patched version from cvs

Drupal 4.7.0b6
sections.module v 1.14 (2006/02/22)

I have sections working in 4.7b6. However, if I activate the acidfree module, sections no longer works.

I need more information.

sentences like «it CAN work in 4.7» are not very usefull for debugging.

* What does not work
* What errors does one get
* Where doe errors or other problems occur
* What is probably causing the errors.

NOTE that sections has issues with some other modules that call themes in the wrong place. Known collide with event.module.

Sections isn't working for me either. Running 4.7rc. No errors are being thrown, it just doesn't work.

I've done a little investigation and it looks like the $custom_theme global is being set properly (at line 242 in sections.module), but it just isn't having any effect. It's as if hook_menu is too late to change the theme.

@jmiccolis are you running any third party modules? And did the patch fix anything?

no, I didn't apply the patch - it looks like that change is already fixed in the module (v 1.14) and anyhow it looks like it was a contrib module -> img_assist. The new version from benshell http://www.benjaminshell.com/demo/img_assist.htm

Any tips on what to look for? Also, any idea why taxonomy_theme would work and sections wouldn't?

I'm sure alot of people are having similar problems using sections with other contrib modules - In my case, the problem stemmed from a line in img_assist which was using drupal_set_html_head() to add a stylesheet. By using theme_add_style(), which is what should be used anyhow, I was able to get sections working again.

So if you are having issues, keep your eyes out for drupal_set_html_head() .

Node(key)words module was conflicting with Sections. The issue has been recently fixed, maybe this can help ;)

Changing the title.

Following the discussion on development@drupal.org, here is a patch that for me fixes the conflict with other modules initializing the theme system to early. The patch moves setting $custom_theme into a newly introduced hook_init().

Bèr, thank you for your critique :-)
Olav

We once moved all theme-switching stuff from hook_init to hook_menu (here is why http://drupal.org/node/19590). I dont think its a good idea to move back now, just because some modules call to theme() too early. But whatever we do, all theme-switching modules should be at the same level. Take a look at core (block.module). Even this module calls init_theme in hook_menu. Switching theme in hook_init from a contributed module breaks at least configure-blocks-per-theme feature in many cases (esp. with a theme assigned to admin/* pathes).

(P.S. I am maintainer of taxonomy_theme)

Well, at least it solves another lot of problems. Thing is, that hook_init is rather heavy, but hook_menu is IMO not very much lighter, since that is called just as often, afaiks.

using hook_init again, has the benefit that hardly any modules invoke the theme in that hook, but a lot of modules do invoke the theme in the menu already.

I am all for committing this patch, but would love some feedback.

Bèr

reviewed and tested.
This does solve about 80% of the conflicts, but there are some modules that want to do stuff in _init. Besides, as profix898 in #13 points out, we moved the switching to _menu on purpose. having it in _init is horrible for performance.

We need to hunt for a real solution instead. Something in lines of setting the weight of sections to bery low (that sections comes first) or maybe something else. I don't really know what.

Current version of advuser seems to fall in this category. Enabling advuser disabls sections.

Sometimes i should really read all issues first and not reinvent the wheel :-(((. Damn - this took me days to figure out again.

I reported this in detail as a Drupal 5.x Bug in http://drupal.org/node/142791. I think we can solve this only by changing the weight of sections to -100 or so and tell other module developers to not to use theme placeholder or theme() functions in menu at all. I'm not sure if this is possible everytime, but it looks like the only working solution and the only way to get the correct value in $custom_theme var on a init_theme.

Aside this patch looks like already committed!? Should this stay open as reference or should we close now?

I just ran across this problem. The fix that worked for me is to set the sections module weight, in the system table, to some large negative number so that sections_menu runs before any of the other hook_menu functions.

I'd prefer to have this run in hook_menu as that will work with caching. hook_init runs on all pages, including cached pages. I don't think it would be good for performance.

Would a patch that simply adds an update and step to the install process that sets the weight to -999 work? If so, I can roll the patch.

Added weight=-10 to the section module. This will rank sections higher then taxonomy_theme as a side note and fix some side effects if both modules are used, too.

But as said above - module developers should NEVER use theme placeholder or theme() functions in menu at all... after such a call we are unable to switch the theme...

can someone please review this patch and test it?

Are you talking about the patch in #12? If so, I don't know if setting the custom theme in hook_init is the best way to go. That would cause another database call to fire on every page.

If there is going to be a patch maybe have one in a sections.install file that sets the weight to some negative number so it fires before the other modules. This would work better for caching.

I think he is talking about #20 that have already been committed and released in 5.x-1.1 and 6.x-dev.

oops, missed that with no attached patch.

I've had this running for some time now. Changing the weight works.