realname_make_name, theme, block configuration
| Project: | RealName |
| Version: | 6.x-1.2 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | postponed (maintainer needs more info) |
Jump to:
This is probably a hard to replicate bug.
Basically, if realname_make_name has to be called before the block configuration page callback is called AND realname needs to call theme('something), it messes up the displaying of correct theme (when having multiple themes, like with administer theme).
For example, for a CCK field that does not have a values already populated and needs formatting, theme('link_default' for example is called, and the current theme is registered.
Examples of module that call user_load before the page callback is OG (organic groups) in implementation of hook_init (og_init).
Example, og_init calls user_load, which calls hook_user($op='load'), then realname calls realname_make_name, then content_formater is called, which calls theme, which registers the current theme. Then the block configuration tries calling init_theme but garland is already initialized so the correct theme isn't loaded.
#1
line 296
<?phpfunction realname_user($op, &$edit, &$account, $category = NULL) {
global $theme;
if (!$theme) return; // prevent realname from overiding theme on block pages
?>
#2
I'd like to confirm this bug. Going to block admin displays the incorrect theme (garland instead of my custom theme) and therefore I can't configure any blocks after enabling this module.
The fix(?) proposed above doesn't seem to work for me.
#3
More a workaround them a fix.
It may that something is calling part of the realname instead of user_load, which was my issue.
The test above is basically checking if the $theme variable is set, which indicates the theme has been loaded for the page.
If you wanna be risky, could backtrace how I found out what was calling it by putting echo's in module_implements and module_invoke all and .. theme_init ? to see what module hooks are being called and when the theme is being registered. As long as your comfy with that and removing the statements later.
#4
I don't see how RealName would care what theme is current or could even change it. Certainly, my theme doesn't switch to Garland.
#5
It's been changed in organic groups already to my knowledge, but they were calling user_load in hook_init. At that time, realname also was calling the make name function in hook_user 'load'. Using content profile to supply and Format the fields (which use theme functions), the function theme() was being called. When theme is called it checks if the theme is loaded; if not, it loads the theme that is currently set for the theme.
For the case of blocks configuration page, which switch themes in the page callback by setting a variable, if the theme is already registered and loaded it uses the loaded theme and not the newly set theme (it's very not possible to unload a theme to my knowledge, once a theme is loaded it's the theme).
so the program flow was
og_init called user_load($user->uid)
user_load called hook_user which triggered realname_user('load')
realname makename was called populated by cck fields, which had formatters that were called via theme('whatever'
theme() call inialized the theme, which via admintheme was set to 'garland'
page callback called
block config tries to change the theme to the default theme but fails due to garland being intailized.
And thus garland was shown on admin page
(This was extremly hard to figure out XD).
I haven't looked at realname in a bit so no idea if it's still relavent; my guess is since realname uses the database now it wouldn't be as likely for a rogue module calls user_load before page callback, and unless block config clears cache then refreshing would solve it.