I haven't tracked down the source of it but it only occurs when a user signs up/user account is created by a user with sufficient privileges. Could be a conflict with some other module but it only appears when logintoboggan is enabled.

Comments

hunmonk’s picture

Status: Active » Postponed (maintainer needs more info)

if you disable the other contributed modules and enable logintoboggan, do you still get the same error?

can you post the full error message?

nonsie’s picture

Digging 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()

    case 'user_register':
      // Admin created account aren't processed by the module.
      if (user_access('administer users')) {
        break;
      }
hunmonk’s picture

i'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?

nonsie’s picture

I 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" }

hunmonk’s picture

but 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.

nonsie’s picture

Project: LoginToboggan » Drupal core
Version: 6.x-1.2 » 6.4
Component: Code » user system

The 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()

damien tournoud’s picture

Version: 6.4 » 7.x-dev
Status: Postponed (maintainer needs more info) » Active

In #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.

boaz_r’s picture

it might be a #maxlength property on password_confirm field. See http://drupal.org/node/378558

gomez_in_the_south’s picture

Removing the #maxlength property from the password_confirm field solved this issue for me in my custom form.

Aleet’s picture

How do you Remove the #maxlength property from the password_confirm field ? I mean in which admin page?

donahoche’s picture

thx Gomez_in_the_South :)

Andrew Schulman’s picture

Issue summary: View changes

I 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.

dcam’s picture

Version: 7.x-dev » 6.x-dev

I 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.

Status: Active » Closed (outdated)

Automatically closed because Drupal 6 is no longer supported. If the issue verifiably applies to later versions, please reopen with details and update the version.