Posted by jhm on July 2, 2006 at 8:09pm
3 followers
Jump to:
| Project: | Organic groups |
| Version: | 4.7.x-1.x-dev |
| Component: | og.module |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (won't fix) |
Issue Summary
When installing og the masquerade module breaks because og_init loads the user data from the database and therefore overrides the changes the masqurade_init made to the global $user structure.
I patched the og_init function to look as follows:
function og_init() {
// only bother when we are not serving a cached page. check for which functon that only exists afterwards
if (function_exists('drupal_set_content')) {
// we have to perform a load in order to assure that the $user->og_groups bits are present.
global $user;
if(module_exist('masquerade')){
$masquerading = isset($user->masquerading) ? $user->masquerading : null;
$user = user_load(array('uid' => $user->uid));
if( $masquerading ) $user->masquerading = $masquerading;
}else{
$user = user_load(array('uid' => $user->uid));
}
og_theme();
og_set_locale();
if (module_exist('views')) {
include drupal_get_path('module', 'og'). '/og_views.inc';
}
}
}
Comments
#1
no masquerade specific code allowed in og.module. we need a different fix
#2
well, there is
viewspecific code in the og.module?Anyways, since og.module decides to force the reloading of the user object, the only other way (I could come up with) of restoring compatibility of the og.module with modules that rely on/modify the user object in memory is to make sure that those modules are invoked after the og.module.
I renamed masquerade.module (and its hook methods) to zmasqurade.module, thus ensuring that its init hooks are called after og.module reloads the global user object.
#3
jhm: What about a patch to masquerade module that increases its weight in the system table to 10 or something so it is always the last module executed?
#4
Also, there is view-specific code in OG because OG actually makes use of views. Masquerade is a developer tool; 95% of sites won't ever use it, and the 5% that do won't ever on a production site. Therefore, it doesn't make sense to introduce logic for a module that in the vast majority of cases isn't going to be present, and that doesn't improve/enhance OG in any way.
#5
masquerade is a developer tool, true. I was just bitten in the rear starting to develop, and the first thing that craped out was the developer tool :>)
I did weigh down the masquerading module (in the database - didn't find an interface for it).
That did not matter, since
og_roles_menualso callsuser_loadand therefore overrides anything that happened duringmodule_invoke_all('init').I guess masquerade writing to the global $user is not a good idea since anybody could have called the
user_loadfunction anytime. Will think about a solution to patch the masquerade module instead.#6
I patched the masquerade module instead
see http://drupal.org/node/62278
I changed the status of this "bug" to won't fix.