realname_make_name, theme, block configuration [#467492]

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.

Comments

Comment #1

hefox CreditAttribution: hefox commented 20 May 2009 at 15:06

line 296

function realname_user($op, &$edit, &$account, $category = NULL) {
	global $theme;
  if (!$theme) return; // prevent realname from overiding theme on block pages

Comment #2

bcruiksh CreditAttribution: bcruiksh commented 10 July 2009 at 21:21

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.

Comment #3

hefox CreditAttribution: hefox commented 11 July 2009 at 04:35

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.

Comment #4

NancyDru

she/her/hers

English

Boston

CreditAttribution: NancyDru commented 8 October 2009 at 21:18

Status:

Active

» Postponed (maintainer needs more info)

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.

Comment #5

hefox CreditAttribution: hefox commented 8 October 2009 at 21:57

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.

Comment #6

kylex CreditAttribution: kylex commented 10 January 2012 at 18:05

Version:

6.x-1.2

» 6.x-1.4

This issue is still occurring for me on 1.4

Comment #7

ChrisLaFrancis CreditAttribution: ChrisLaFrancis commented 8 May 2012 at 05:30

Version:	6.x-1.4	» 6.x-1.x-dev
Status:	Postponed (maintainer needs more info)	» Active

I'm still seeing this as well. Initially I thought it was related to the Content Profile module and filed #1566540: Content Profile interferes with blocks administration when administration theme used, but the problem seems to be more related to RealName. For me, the issue only seems to occur when both modules are enabled, RealName is set to use Content Profile (blocks administration is fine when RealName is set to use Core Profile), and only after the RealNames are rebuilt.

As was alluded to in previous comments, I think the problem has something to do with the theme system being initialized too early... see #219910: Calling theme function from hook_init() interferes with administration theme.

#792260: Block breaks when realnames are calculated for the first time and #1186654: Wrong theme on Administer Blocks page (realname + token + me + special_menu_items) seem like likely duplicates of this issue.

Comment #8

ChrisLaFrancis CreditAttribution: ChrisLaFrancis commented 9 May 2012 at 03:47

So after further testing, the issue I described above does not happen on every site in which both RealName and Content Profile are enabled... there's obviously another variable in play. My first thought was that a different module must be interacting with RealName and Content Profile to cause this issue to manifest itself, but so far I haven't been able to find a module which is enabled in all of the sites that have the problem and disabled in the sites that don't have the problem.

Comment #9

hefox CreditAttribution: hefox commented 9 May 2012 at 05:18

add a print_r(debug_backtrace()); die(); (or similair debug statement) in realname_user to see what is first calling it

Comment #10

ChrisLaFrancis CreditAttribution: ChrisLaFrancis commented 9 May 2012 at 15:28

Thanks, that was helpful. So both sites-with-the-problem and sites-without-the-problem have the same backtrace:

drupal_bootstrap -> _drupal_bootstrap -> _drupal_bootstrap_full -> module_invoke_all -> call_user_func_array -> password_policy_init -> user_load -> realname_user

Password Policy is calling user_load() in its hook_init(), so it looks like the same scenario as was described in comment #5. Disabling the Password Policy module makes the problem go away on sites-with-the-problem. Interestingly, it's configured exactly the same on sites-with-the-problem and sites-without-the-problem.

Something else I just noticed is that the problem with the blocks administration page only occurs when the profile content type has a field with a data type of "file", e.g. for a user's photograph. If I remove this field, blocks administration works fine. If I add a field of this type to a site-without-the-problem, blocks administration stops working. If a file field is there and Password Policy is enabled, blocks administration is broken... with the field there, and Password Policy disabled, blocks administration works as expected.