If by some combination of circumstances (in my case, I think it was a an incorrectly set-up database merge) you get user entries which don't have usernodes, the code is insufficiently robust in its handling of the issue. It can lead to the creation of empty nodes which don't even have a type value, which then cause all sorts of knock-on effect.
In my case I got a recursive invocation of some workflow, which led to a new empty node being created each time through. As a result I now have hundreds of empty nodes for which I'll have to hand-craft the code to clean up.
Fortunately the remedy is very simple, and I've patched the code in my own copy accordingly. I attach a patch created using TortoiseSVN which I suspect may not be in the correct format, so here's what needs to be done. At line 274 of usernode.module, in the usernode_update_node() function, replace these lines:
$node->user = $user;
usernode_save_node($node);
with these:
if($node) {
$node->user = $user;
usernode_save_node($node);
} else {
usernode_create_node($user);
}
This patch will of course not deal with any other consequences of missing usernodes: it only deals with the most pathological problem.
Comment | File | Size | Author |
---|---|---|---|
usernode.patch | 513 bytes | alfaguru |
Comments
Comment #1
alfaguru CreditAttribution: alfaguru commentedWell, I found why some users lacked usenodes - cron wasn't running. However, even if cron runs OK there is still a time period between this module being activated and when cron next runs when there may not be usernodes present; during which this nasty bug can rear its head. So I think the fix is called for as the effect is pretty severe.
Comment #2
beatelic CreditAttribution: beatelic commentedThanks, i had the same problem. Don't know why this happend, but this code fixed it.
Comment #3
fagothanks, I've committed a slightly improved version.
Comment #4
Anonymous (not verified) CreditAttribution: Anonymous commentedAutomatically closed -- issue fixed for two weeks with no activity.