Closed (outdated)
Project:
Drupal core
Version:
6.x-dev
Component:
user system
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
1 Aug 2008 at 01:06 UTC
Updated:
2 Mar 2016 at 22:18 UTC
Jump to comment: Most recent
Comments
Comment #1
hunmonk commentedif you disable the other contributed modules and enable logintoboggan, do you still get the same error?
can you post the full error message?
Comment #2
nonsieDigging deeper into the bug - I've set the module up as follows:
login using their e-mail address - disabled
two e-mail fields on registration form - enabled
set password - enabled
If I create a new user account as a user with administer users permission I get this error message:
warning: mb_strlen() expects parameter 1 to be string, array given in C:\example.com\includes\unicode.inc on line 405.
Line 405 is in drupal_strlen() function and what happens is instead of a single password field being passed in for validation an entire array is passed along containing pass1 and pass2. This is because of the following part of logintoboggan_form_alter()
Comment #3
hunmonk commentedi'm not clear why that code would be causing the problem -- it's simply passing control of the user registration process back to core. can you elaborate?
Comment #4
nonsieI was checking variables going through drupal_strlen() and the only one that is not passed as string is password which is passed as an array - array(2) { ["pass1"]=> string(6) "123456" ["pass2"]=> string(6) "123456" }
Comment #5
hunmonk commentedbut if you follow the code flow, i don't think LT has anything to do w/ password being an array. the password and password confirm form items are generated by core.
Comment #6
nonsieThe problem is indeed in the core, see http://drupal.org/node/232763
_form_validate() gets called before password_confirm_validate(), but pass gets converted to a string in password_confirm_validate()
Comment #7
damien tournoud commentedIn #117748: Trim required fields on validate: we added a drupal_strlen() check there, that's what caused an ordering issue to appear in plain light: _form_validate() gets called before password_confirm_validate(), but pass gets converted to a string in password_confirm_validate().
I think that the password widget is wrong: it should not call form_set_value() in password_confirm_validate() but rather properly implement its own #process function.
Bumping to 7.
Comment #8
boaz_r commentedit might be a #maxlength property on password_confirm field. See http://drupal.org/node/378558
Comment #9
gomez_in_the_south commentedRemoving the #maxlength property from the password_confirm field solved this issue for me in my custom form.
Comment #10
Aleet commentedHow do you Remove the #maxlength property from the password_confirm field ? I mean in which admin page?
Comment #11
donahoche commentedthx Gomez_in_the_South :)
Comment #12
Andrew Schulman commentedI used to have this bug, but as of Drupal 7.28 I can't reproduce it any more. I suggest closing it, but would like others to confirm first.
Comment #13
dcam commentedI can't confirm the bug for 7.x. The #maxlength attribute was removed for 8.x and 7.x in #1777270: Write tests for: Users with passwords over 60 characters cannot log in via the user login block. Plus, the 7.x user account form is drastically different now than it was in 2009, probably due to Profile being combined with User. I don't know if the issue is still present in 6.x, so I'm bumping the version down to it.