Don't initialize the theme system during common.inc. Instead, wait for the first call to theme() and do it there. There are 2 big benefits:

- sometimes you never call theme(), and thus don't ever need to include theme engine and template. thats a performance win. examples include RSS feeds, blogapi, distributed auth, ...

- module developers are currently forced to use hook_init() to set a custom theme for a given page view. with this patch, they can wait and do this during hook_menu(). Without this delay, module developers are tempted, sometimes forced, to break the bootstrap and inadvertently load all the modules for every page view. I almost did this in Organic Groups module, where each group can shoose its own theme. You can break the bootstrap by doing something as simple as node_load().

This is a tiny patch, and merits consideration for 4.6, i think.

CommentFileSizeAuthor
init_theme_lazy.patch1.04 KBmoshe weitzman

Comments

chx’s picture

Very nice, very clever, very big plus one.

BTW. What about including the "do not use hook_init instead hook_menu" in the "update your modules" section of handbook?

moshe weitzman’s picture

that is already documented - http://drupaldocs.org/api/head/function/hook_init. it doesn't belong in the upgrading page it has worked this way for several rleases now.

chx’s picture

Several releases? hook_menu came to existence in 4.5, and we have 4.6 coming up.

And no, it was not working, I think it was you who have fixed bootstrap sometime around 4.5.2...

Chris Johnson’s picture

Agree on this being a very nice patch. Nice performance optimization. +1

dries’s picture

I wonder if this "performance win" is even measurable. That aside, it makes sense to do it this way.

TDobes’s picture

+1... this also has the added benefit that the $custom_theme variable can be specified by a PHP node. (note that this doesn't work in preview, though... only after the node has been submitted)

chx’s picture

What's more, a PHP block is also capable of setting $custom_theme (no need to output anything, thus this will be an invisible block). This combined with the powerful block admin pretty much obsoletes sections.module and is capable of much more.

adrian’s picture

oooooh nifty!

(that is all .. oh... and +1 for 4.6)

dries’s picture

Committed to HEAD. Please take the time to update whatever code that can take advantage of this (eg. sections.module).

Anonymous’s picture