hook_user() changed and should be documented

I'm seeing it on a fresh install from HEAD as well.

Doing some investigation, also changing the title to reflect the nature of the problem

Could you provide more detail:

Which version of PHP?

What is the behaviour that you're seeing? "users cannot change passwords" is not very descriptive - what steps must I follow to duplicate this behaviour? Alternatively, step by step, what did you do, what did you expect to see/experience, what did you in fact experience.

Could this be a duplicate of: http://drupal.org/node/40384

Thanks, Djun

Running today's HEAD, with a fresh database, on a Site5 server with PHP Version 4.4.0 and MySQL 4.0.25.

Create the first account, get the auto-generated password. Log in. Go to user/edit/1 and change the password. Save.

Log out, then log in with the new password -- username/password not recognized. Reset the password, get the reset email, log in using the one-time key, change the password -- same story.

Then, go back and try to log in using the original randomly generated password from account creation -- success!

Have to investigate the issue with roles, I've only seen the password issue personally.

As a developer interested in fixing bugs, I like to see what I need to know about a bug in the issue that people file, IN ONE PLACE. Don't make me chase through half a dozen replies, and blogs on this or that server. It's a nice way to promote your blog, but not helpful to people trying to fix bugs.

Please read the guidelines for submitting issues at
http://drupal.org/node/317 and http://drupal.org/node/19279.

Thank you

There was a user edit form submit model conversion. It's rather trivial to see that this issue means that function user_edit_submit is botched. Let me see...

http://drupal.org/node/39179 now fixes the role checkboxes problem.

Password, however reveals a much deeper problem. hook_user needs a 'submit' op, much like hook_nodeapi needed. validate validates, submit changes. The two are mixed. I do not have the time to rearrange _user_edit_validate accordingly (and put a caller line into user_user). However, it should be quite clear what's needed now.

Roles work. Passwords do not. I am pretty sure you would have problems with pictures too.

I mean deleting pictures -- previously, validate unset them. Now you need to unset them in submit.

Gordon reports , and he is right that pass1 and pass2 needs to be elements of the forms array. Something like

$form['passwords']['#theme'] = ...
$form['passwords']['pass1'] = array('#type' => 'password'...);
$form['passwords']['pass2'] = array('#type' => 'password'...);

Hi, any update on this?

After talking with Dries, we agreed it's better if I finish.

chx: hope i'm not stepping on your toes here, but this bug has been outstanding for awhile, and it's fairly serious--so i took a crack at a solution. attached patch integrates your previous patch, and creates a new 'password_confirm' form element so that the password fields get properly built in the form api code. also, the validation code was broken for users trying to register for new accounts, so i fixed that up. lemme know if there's anything else that needs done to get this in.

Password and role changes are now working (Yay!) but it's now impossible to change ANY field if pass1 and pass2 aren't entered. That means that an admin cannot add new roles without altering a user's password...

eaton: indeed. i caught that shortly afterwards. now, six hours later, i think i've finally got things squared away. please test! i revamped the password_confirm form element, and moved all of the relevant form processing behavior into the element itself--much nicer :) now if you want a password_confirm form element, you just:

$form['name_of_element'] = array('#type' => 'password_confirm');

and that's it. as long as the passwords properly validate, you'll end up with:

$form_values['name_of_element'] at your disposal... :)

you even have the option of making the password_confirm element required or not, and any module can use it, since it's now a system form element.

i also temporarily fixed the user picture uploads. somebody needs to properly abstract that portion of the code, but i feel that's a seperate issue to be filed. please, let's get this committed if it tests out ok--it's been broken in HEAD for 11 days now--not good... :)

Role changes are working, user pictures are working, password changes are working, and password reset emails are working. The password-confirm form element is a great re-usable element, too. Definite +1.

Chad, you are FANTASTIC! I changed the following:

• As the process function had no logic inside, I simply moved the child elements into system_elements.
• I changed a bit the call to #after_build so you can change the global form_values in #after_build. This change does not affect node previews and other #after_build functions -- I checked.

Otherwise, you are the man.

This is great, +1 please commit ASAP.

Just tested it on my install as well. Everything's good to go. +1

Committed to HEAD. Thanks.

this patch adds a new op 'submit' to hook_user and should be documented at http://api.drupal.org/api/4.7/function/hook_user (and HEAD) and possibly Converting 4.6 modules to 4.7. marking ACTIVE until this is fixed. see also bug update documentation for hook_user, op 'submit'.

There is something missing in the patch. I was trying to update my birthday module to 4.7 and noticed somthing weird.

In hook_user I need to update 1 field and at the end I do

$edit['birthday'] = NULL;

like instructed in the documentation. But afterwards the user_save() overwrites my value. A workaround was to do:

unset($edit['birthday']);

But that is not what the documentation says.

So a solution would be to change user_save() to:

    foreach ($array as $key => $value) {
      if ($key == 'pass' && !empty($value)) {
        $query .= "$key = '%s', ";
        $v[] = md5($value);
      }
      else if ((substr($key, 0, 4) !== 'auth') && ($key != 'pass')) {
//        if (in_array($key, $user_fields)) {        >>> This is the line that changes
        if ($value !== NULL && in_array($key, $user_fields)) {		
          // Save standard fields
          $query .= "$key = '%s', ";
          $v[] = $value;
        }

So please explain if I should use unset or if the user.module should be patched? Or should the custom user fields be removed in the user_register_submit?

I know that usually extra user fields are added through profile but in this case it is not possible. Moreover, shouldn't it be possible to add user fields?

Patch implements my proposed solution. Maybe I should start a new thread for this issue?

It would be best to open a new issue, since the original patch has already been committed. This issue was only re-opened to point out the need to document the change that had been made.

Ok. Created new issue and resetting the status of this one to what it was before I started fiddling with it.
http://drupal.org/node/85094

Patch committed. Documentation request is a duplicate of issue 77459.