[prev in list] [next in list] [prev in thread] [next in thread]
List: drupal-documentation
Subject: [documentation] [Documentation bug] hook_user() changed and should
From: drupal-docs () drupal ! org (Jax)
Date: 2006-09-13 19:04:14
Message-ID: type=project&nid=42057&cid=136035&host= () drupal ! org
[Download RAW message or body]
Issue status update for
http://drupal.org/node/42057
Post a follow up:
http://drupal.org/project/comments/add/42057
Project: Documentation
Version: <none>
Component: Developer Guide
-Category: tasks
+Category: bug reports
Priority: normal
Assigned to: chx
Reported by: Patrick Nelson
Updated by: Jax
Status: active
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
<?php
$edit['birthday']?=?NULL;
?>
like instructed in the documentation. But afterwards the user_save()
overwrites my value. A workaround was to do:
<?php
unset($edit['birthday']);
?>
But that is not what the documentation says.
So a solution would be to change user_save() to:
<?php
? ? 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?
Jax
Previous comments:
------------------------------------------------------------------------
Thu, 22 Dec 2005 09:26:55 +0000 : Patrick Nelson
OK, I have a problem with a 4.7.0-beta2 site which in essence is this:
1) Users cannot change passwords
2) Administrator cannot change password
3) Editing users results in ALL roles being selected
This is practically a default site - almost nothing has been changed
and the problem has me completely flummoxed. I have re-installed the
site and monitored the entire process and have even tried rolling back
when the error occured but to no avail.
I am so keen to get this problem resolved that I am willing to give
administrator access to help solve it. The site is currently on
www.v-community.co.uk [1] and you can log in and create yourself a new
account if you want to in order to test that this is true and, if you
can help with the problem, please contact me for the Administrator
password.
I have also 'blogged' the entire routine that I followed in setting
this site up and getting to the point where the problem reoccured. You
can read the blog here [2].
I think this is a relatively easy problem for people to encounter so
perhaps the urgency is greater than just my own little site. All help is
greatly appreciated.
Regards
Patrick
[1] http://www.v-community.co.uk
[2] http://www.v-community.co.uk/node/1
------------------------------------------------------------------------
Thu, 22 Dec 2005 13:52:50 +0000 : Patrick Nelson
All bets are off. I've found the problem and it is in version 1.543 of
the user module.
This update breaks the system in the following way:
1) It is impossible to change the password (either as user 1 or as the
user whose password it is)
2) Changing roles results in all roles being selected for that user.
At least, this is the result of this update on my version of beta-2
which is pretty much a standard install.
Does anyone else have this problem?
------------------------------------------------------------------------
Thu, 22 Dec 2005 16:20:29 +0000 : Eaton
I'm seeing it on a fresh install from HEAD as well.
------------------------------------------------------------------------
Thu, 22 Dec 2005 16:43:51 +0000 : Eaton
Doing some investigation, also changing the title to reflect the nature
of the problem
------------------------------------------------------------------------
Thu, 22 Dec 2005 22:12:50 +0000 : puregin
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
------------------------------------------------------------------------
Thu, 22 Dec 2005 22:18:14 +0000 : Eaton
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.
------------------------------------------------------------------------
Fri, 23 Dec 2005 00:24:39 +0000 : Patrick Nelson
puregin,
I appreciate that "users cannot change passwords" is 'not very
descriptive', as you put it, but if you read the whole of the first
post, you will see a link to a blog which describes the whole process
that I took which I think IS descriptive.
------------------------------------------------------------------------
Fri, 23 Dec 2005 05:04:25 +0000 : puregin
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
------------------------------------------------------------------------
Sat, 24 Dec 2005 01:18:29 +0000 : chx
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...
------------------------------------------------------------------------
Sat, 24 Dec 2005 02:31:35 +0000 : chx
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.
------------------------------------------------------------------------
Sat, 24 Dec 2005 11:37:25 +0000 : Patrick Nelson
Puregin,
/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./ - That's
why I put in my first post, "I have also 'blogged' the entire routine".
If you took a couple of seconds to click the link, you would have seen
that. If you also took those couple of seconds instead of jumping to
conclusions about what the blog contained, you would find that it is not
a /"nice way to promote your (my) blog/ because that is not MY blog - I
put it up there because I was trying to be helpful.
I will read the guidelines that you suggested, thank you very much for
pointing them out, because I AM trying to be /"helpful to people trying
to fix bugs"/ as asked for of the entire community here [3]. If some of
the developers wonder why more people haven't got involved and are
helping, perhaps it has something to do with receiving rudeness and
ignorance and getting their heads bitten off by people with a "holier
than thou" attitude whenever they do.
To Eaton [4] and chx [5], thank you for trying to help and I apologise
if I didn't explain things clearly enough in my first post.
[3] http://drupal.org/drupal-4.7.0-beta2
[4] http://drupal.org/user/16496
[5] http://drupal.org/user/9446
------------------------------------------------------------------------
Sun, 25 Dec 2005 04:33:14 +0000 : chx
Attachment: http://drupal.org/files/issues/user_submit.patch (3.89 KB)
Roles work. Passwords do not. I am pretty sure you would have problems
with pictures too.
------------------------------------------------------------------------
Sun, 25 Dec 2005 04:33:56 +0000 : chx
I mean deleting pictures -- previously, validate unset them. Now you
need to unset them in submit.
------------------------------------------------------------------------
Mon, 26 Dec 2005 09:44:29 +0000 : chx
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'...);
------------------------------------------------------------------------
Wed, 28 Dec 2005 02:29:34 +0000 : alexis
Hi, any update on this?
------------------------------------------------------------------------
Wed, 28 Dec 2005 14:54:45 +0000 : chx
After talking with Dries, we agreed it's better if I finish.
------------------------------------------------------------------------
Sun, 01 Jan 2006 10:02:06 +0000 : hunmonk
Attachment: http://drupal.org/files/issues/user_password.patch (7.46 KB)
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.
------------------------------------------------------------------------
Sun, 01 Jan 2006 17:43:48 +0000 : Eaton
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...
------------------------------------------------------------------------
Sun, 01 Jan 2006 22:11:27 +0000 : hunmonk
Attachment: http://drupal.org/files/issues/user_password_0.patch (9.53 KB)
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... :)
------------------------------------------------------------------------
Mon, 02 Jan 2006 00:27:18 +0000 : Eaton
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.
------------------------------------------------------------------------
Mon, 02 Jan 2006 04:07:52 +0000 : chx
Attachment: http://drupal.org/files/issues/user_edit_3.patch (9.64 KB)
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.
------------------------------------------------------------------------
Mon, 02 Jan 2006 05:24:36 +0000 : gordon
This is great, +1 please commit ASAP.
------------------------------------------------------------------------
Mon, 02 Jan 2006 05:40:33 +0000 : Eaton
Just tested it on my install as well. Everything's good to go. +1
------------------------------------------------------------------------
Mon, 02 Jan 2006 08:35:21 +0000 : Dries
Committed to HEAD. Thanks.
------------------------------------------------------------------------
Mon, 07 Aug 2006 14:40:51 +0000 : ax
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 [6]. marking ACTIVE until this is
fixed. see also bug update documentation for hook_user, op 'submit' [7].
[6] http://drupal.org/node/22218
[7] http://drupal.org/node/77459
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic