Imagecache breaks, avoid node_load() in hook_init()

Does Image Cache break immediately after you installed ThemeKey. Or did it break after you created rules?

I thought about what changes if ThemeKey is installed. Under some circumstances node_load() is triggered in hook_init() which previously seemed suspicious to me. Now I found a releated issue: #582382: Blog Theme causes Fatal Errors in other modules, due to bad hook_init() implementation

If this is causing your issue or not, we should avoud node_load() at this point.

I wrote a patch to avoid node_load() within hook_init(). Are you able to test it if it resolves your issue?

We had the same kind of problem; But tried upgrading from 6.x-1.x so... since we didn't have many rules.. we uninstalled 1.x and installed 2.0 instead... after this it seems the imagecache works o.k.

I've tried to apply the patch but it doesn't change the problem with 100% cpu

Also - looking at debug - we get:

# ThemeKey Debug: Match: "drupal:path = retro >>> lan09"
# ThemeKey Debug: Switching theme to lan09

But it never actually does the switch... the page with path retro is shown with default theme.

So for us, the module does not work. (Is there a problem with autopath?)

I know this should proberbly have been submitted as a new issue, but I think it's related.

Any help will be appreciated. :-)

ThemeKey itself works;
# ThemeKey Debug: Match: "drupal:path = retro >>> lan09"
# ThemeKey Debug: Switching theme to lan09

There must be another module that breaks the theme switching. Please read through this issue:
#681358: insertFrame must not call theme() in hook_init()

Especially look at comments #6, #7 and #8.
It will be interesting to see which module causes the trouble. Please post the results here.

Thanks a lot for your help. (And for maintaining such a nice module)

Together with browscap-module, we also had a little module of our own; trying to switch theme based on browscap... this seems to have been giving the trouble; sorry.

(Any plans on properties which can match browscap?)
EDIT: I see that there is already: # system:user_browser and # system:user_browser_simplified in the ThemeKey Properties-module

Btw - by using "Module Weights" - it's possible to change the order of "invoking" and this can be a help when troubleshooting simular problems.

Hmmm... we still have the problem: enabling themekey gives us trouble with imagecache and also makes cpu go 100%
I'm sure it's some other module calling theme() in hook_init - but how do I debug it?
Is the patch in #6 (in #681358) just applied to theme.inc in core?
(Is there another way?)

Thanks for you help. :-)

I think we get problems because of the following in themekey_base.inc:

It seems that the themekey processes requests that are ment to be js or png files which creates a lot of calculation and also starts and holds a lot of apache threads (childs).

It seems that there's an endless loop here:

for ($i = 0; $i < count($ancestors); $i++) {
$ancestors = array_unique(array_merge($ancestors, themekey_add_path_ancestors($ancestors[$i])));
}

Any thought's on this?

Sounds like we need a kind of blacklist. Could you post some of the URLs?

Unfortunately we had no other possibility than disabling themekey - so I don't think providing you with urls does any good (?)

On the other hand... feel free to have a look... This is our main page: www.tv2east.dk and then on this... www.tv2east.dk/landsstaevne there used to be another theme applied (by themekey 1.x)

Any help are very welcome. (Thanks for your great work with ThemeKey) :-)

I close this issue because it's "fixed" since comment #3.
But I opened a new issue to continue the blacklist discussion:
#741530: Add a blacklist to ThemeKey

@ #8 moyoda
You were right. There was a regression in ThemeKey that caused high CPU load. It has been fixed. See #707208: Out of Memory