error when $log_msg['user']->uid is empty
digi24 - September 20, 2009 - 17:31
| Project: | Logging and alerts |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | minor |
| Assigned: | Dave Reid |
| Status: | needs review |
Description
Hi,
I do not know where this problem came from, but in the rare case that $log_msg['user']->uid and name are empty, there is an php error and no message gets send.
I guess uid should never be empty, but in case you have dlog turned off, errors might remain unnoticed. Took me a while find out. I will post a patch as soon as I have verified its working, have to wait for the error.
Index: logging_alerts/emaillog/emaillog.module
===================================================================
--- logging_alerts/emaillog/emaillog.module (revision 700)
+++ logging_alerts/emaillog/emaillog.module (working copy)
@@ -128,8 +128,8 @@
'@ip' => $log_msg['ip'],
'@request_uri' => $log_msg['request_uri'],
'@referer_uri' => $log_msg['referer'],
'@uid' => $log_msg['user']->uid,
'@name' => $log_msg['user']->name,
#1
Hmm, the uid part shouldn't cause any kind of error because the anonymous user's uid is 0. The name part might be undefined. Looking into this.
#2
Dave, I am quite sure that the problem with the empty object (and resulting php error) is not caused by your module. So all that I am proposing are two small if clauses that alternatively fill the field with some debug information. After all, its the modules purpose to handle situations when other modules fail.
I am just not so fluid with the objects, so I wanted to first observe that my clauses correctly handle the error that occurs only sporadically. Generally logging, also for cron and anonymous users works fine.
#3
If something is destroying the global $user (which is what this variable is), then something is going horribly, horribly wrong, because it always needs to be a proper user object, even when anonymous.
#4
Hello Dave,
you are right, the global user object should be intact, but you never know. In my case I experienced, that the global $user was set to scalar "0" (not the ->uid). I have included my modification to help other users debugging, I do not suggest it should be committed.
But where I had problems and what I think should be ammended is the way $log_msg['user']->uid and $log_msg['user']->name are accessed. As far as I understand, whenever $log_msg['user']->uid is destroyed by some other error, the logging module itself throws an error and does not email the original error message.
I am not too familiar with objects and classes, so feel free to close the issue in case I am writing total nonsense.
#5
Ok yeah, that's something going very wrong. Thank you for reporting #594956: broken logic in xmlsitemap_switch_user in another of my modules where the root problem was coming from. :)