$user->domain_user not set consistently
ariflukito - October 21, 2008 - 04:16
| Project: | Domain Access |
| Version: | 5.x-1.9 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | patch (to be ported) |
Description
Got this error
warning: Attempt to assign property of non-object in C:\www\drupal\sites\all\modules\domain\domain.module on line 623.
warning: Invalid argument supplied for foreach() in C:\www\drupal\sites\all\modules\domain\domain.module on line 627.| Attachment | Size |
|---|---|
| domain.module.patch | 620 bytes |
#1
fix a few more warnings
#2
Yup. I changed that function during development.
Thanks!
#3
warning: Invalid argument supplied for foreach() in C:\www\drupal\sites\all\modules\domain\domain.module on line 1132.Still getting this
#4
That's weird. For some reason the $user object does not contain the domain_user element at that point. It is as if hook_user('load') has not run yet.
Any ideas why? By design, users must be assigned to at least one domain, so this array should never be empty. But if you print $user at this point, you will see that the domain data simply is not present.
#5
#6
ok here what I found out
the $user object wasn't loaded from hook_user
it was loaded from sess_read() function in session.inc, from this query
<?php$user = db_fetch_object(db_query("SELECT u.*, s.* FROM {users} u INNER JOIN {sessions} s ON u.uid = s.uid WHERE s.sid = '%s'", $key));
?>
#7
That's pretty weird. I found the same behavior in hook_user('form') but thought it was an odd case.
Seems like a bug to me, but I can account for it.
Committed to HEAD.
#8
Hi sorry to reopen this, I'm trying to find a proper fix for this one.
On the page where I got the warning above, there are 2 calls to user_load() (which calls hook_user('load')). I skimmed through the source code of user.module and most of the time the output of user_load() (user object) doesn't get saved into global $user variable and it is likely the case here. So I'm thinking what about saving the domain_user value to user data field by calling the routine on hook_user('insert') instead of hook_user('load').
#9
No, that's what we're trying to avoid.
I am thinking of adding this to domain_boot():
<?phpglobal $user;
$user->domain_user = domain_get_user_domains($user);
?>
That will populate the global object correctly for all page views.
#10
I've just tried that and it didn't work with hook_boot() but it worked with hook_init().
#11
It seems to work with hook_boot() -- but you have to reload the module page to set the boot flag in {system} table.
Committed. But the safety code in hook_form_alter() remains.
#12
#13
should domain_source_form_alter() have safety code as well? Probably not, since domain_form_alter() is always processed first.
#14
It might need it. Is it working as expected now?
#15
Yes it is working now with domain_boot() with and without the safety code.
Should we remove the hook_user('load') bit?
#16
No, having it there is appropriate, since that is what the API suggests. It is possible that user_load() requests are done for accounts other than the global $user, so we need that code there.
#17
If we make a similar data storage change in D5, then this patch has to be accounted for.
#18