__clone method called on non-object

The module doesn't ever try to create a user directly, although one of the API calls I make could be trying to. I will exam the code to see what that clone method is trying to do and see how it relates to the module, but my first impression is this is a problem unrelated to the update. In fact, the update just mirrored the changes you were already running. I would try to get the UID of that blank named user you are talking about and examine your users table to see if that turns up any hints.

I'll let you know if I find anything.

Ah, sorry. I didn't read your post closely enough. I went through the code again today and found that the user_multiple_role_edit() function can try to create users at one point. There is a lot of code in that function and I haven't finished going through it yet. This may have to do with the way I obtain the UID to pass it to user_multiple_role_edit(). I run this query:

SELECT uid FROM {users} WHERE mail = "CiviCRM Member's Primary Email Goes Here"

If that query is somehow generating a bogus UID and then passing it to user_multiple_role_edit() then that could be creating the problem you are having. I have just recently learned about some CiviCRM API functions that can get the UID for me. I am going to look into those functions today and see if I can fit them into my code. I'll try to get a patch out as soon as possible.

In the mean time, if you wanted to try and isolate which email could be causing the error, then you can run this query on your CiviCRM database (using phpMyAdmin or a shell if you have access to one):

SELECT email FROM civicrm_membership cm
LEFT JOIN civicrm_contact cc ON cm.contact_id = cc.id 
LEFT JOIN civicrm_location cl ON cc.id = cl.entity_id 
LEFT JOIN civicrm_email ce ON cl.id = ce.location_id 
WHERE contact_type = 'Individual' 
AND entity_table = 'civicrm_contact' 
AND cl.is_primary = 1 
AND ce.is_primary = 1
AND membership_type_id = %1
AND cc.domain_id = %2
AND status_id = %3

Where %1 is your membership type id (can be found in civicrm_membership_type table), %2 is equal to your domain id (which is 1 if you are not running in a multi-site environment), and %3 is equal to your status rule id that means current (can be found in civicrm_membership_status). For the status rule ids, you may have to add some OR statements if you are using more than one status rule id that means current. You can then take those e-mails and pass them to the first query I posted and see if you get a UID of 401 (I would use some sort of script to do that unless you only have a handful of emails). If you do, that's the problem. I know that is a lot of work, but it is just a suggestion. Waiting for the patch is probably a lot easier...

Erg, I just realized that my above post is a dumb suggestion. Just add this code somewhere between lines 419 and 421 in civimember_roles.module:

      echo "<p>";
      echo "UID: " . $uid . " Email: " . $dao->email;
      echo "</p>";

It will do the same thing as my above post in much less time. Look for "UID: 401 Email: Whatever" and that should confirm that this is the problem. Do this on an offline copy of your site if you have one, because this could give users of your site other users info!

Only the primary CiviCRM Contact E-mail is used to match a Drupal user because I was under the impression that this is how CiviCRM related Drupal users to contacts. From what I've read I still believe that is true, but I think there might be more complexity involved that I'm not taking into account.

I just got some feedback on the CiviCRM developer forums which has led me to create this patch. Remove any custom lines from your civimember_roles.module file (or just restore a fresh copy from the tar archive) and apply the attached patch. Let me know if this fixes your problem and if so I'll schedule the patch to be included in the next release.

EDIT: The patch I posted 8 min ago might cause a problem that I just caught. Use this new one called "civimember_roles_uf_id_fix_2.patch".

I'm going to e-mail the Drupal development mailing list to see if I can get any feedback. I have a feeling this is a problem with the Drupal user_save() function. If I can't get any answers there, then I will just write my own role insertion function and see if that helps. I'm hesitant to go that route though, because I feel that the Drupal API is a lot safer.

I found this post discussing similar errors, but it is for Drupal 4.6. It might shed some light on your problem though:

http://drupal.org/node/70106

Oh, could you also try to download the latest dev snapshot for 1.x? It has a much cleaner application of the patch I posted earlier in it. I made that patch very quickly and it's very hack-ish. I think you will probably get the same error, but it is worth a shot.

I just thought of this:

Maybe you have duplicate contacts in CiviCRM that are causing this issue. A while back I ran into a situation where CiviCRM had duplicate contacts in the database and actually forced two Drupal users to have the same e-mail. This caused all sorts of problems, but I fixed it by using the remove duplicates tool in the Administer CiviCRM area and deleting the duplicate Drupal users. Probably isn't the exact same situation for you, but could be related.

Just got a reponse from the mailing list. It seems this problem could be related to permissions. Can you use the manual sync as user 1? (if you have access to user 1). I think this really could be the issue since you are saying that only user 1 is synced.

I will need to restructure the code so as to give normal users temporary user 1 status to apply the roles. I will probably submit these changes either tonight or tomorrow morning. I just need to take the time to make sure this is done securely, because if done improperly there is a risk of permission escalation.

I had more time than I thought I would this morning, so here is a patch that performs the user switching. I tested it with both user 1 and another non-privileged user and both tests worked. I also tested cron when logged out and it also worked. This patch is for the unmodified civimember_roles.module file that you can get in the 1.1 tar archive. I am using security suggestions from other developers on the mailing list, so it should be safe.

Hmm, where did you add the break statement before? I thought you just commented out the if statement that was checking to see if the $uid query wasn't FALSE, which was causing problems when you didn't have a Drupal user for a contact.

EDIT: Made a quick change to the patch. Use the file called civimember_roles_permission_fix_2.patch if you downloaded the old one.

That's great news!

You don't have to apologize; I wasn't entirely sure it would solve your issues either. I'm reviewing all the code in the module and will put out another release soon.

Then we can move onto your next future issue and turn that into a release too... =).