Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.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.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | domain.patch | 1.62 KB | ariflukito |
| domain.module.patch | 620 bytes | ariflukito |
Comments
Comment #1
ariflukito commentedfix a few more warnings
Comment #2
agentrickardYup. I changed that function during development.
Thanks!
Comment #3
ariflukito commentedStill getting this
Comment #4
agentrickardThat'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.
Comment #5
agentrickardComment #6
ariflukito commentedok 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
Comment #7
agentrickardThat'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.
Comment #8
ariflukito commentedHi 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').
Comment #9
agentrickardNo, that's what we're trying to avoid.
I am thinking of adding this to domain_boot():
That will populate the global object correctly for all page views.
Comment #10
ariflukito commentedI've just tried that and it didn't work with hook_boot() but it worked with hook_init().
Comment #11
agentrickardIt 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.
Comment #12
agentrickardComment #13
ariflukito commentedshould domain_source_form_alter() have safety code as well? Probably not, since domain_form_alter() is always processed first.
Comment #14
agentrickardIt might need it. Is it working as expected now?
Comment #15
ariflukito commentedYes it is working now with domain_boot() with and without the safety code.
Should we remove the hook_user('load') bit?
Comment #16
agentrickardNo, 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.
Comment #17
agentrickardIf we make a similar data storage change in D5, then this patch has to be accounted for.
Comment #18
jmunning commentedComment #19
agentrickard