Fatal error on user profile

Does this change fix the problem?

OK, great. I will plan to develop a better fix for commit.

The code was always trying to customize the password field for the user_register_form and user_profile_form, whether or not the password field existed on them.

Same fix, but try to make code intent more explicit.

This same problem exists with the Profile2 module. Looking at the patch, I'm wondering if there's a simpler way that it could be done, without hard coding user_profile_form and user_register_form in the code?

How about just setting the default array value to NULL, and skipping the function if no array is set. Seems more straightforward to me, unless I'm missing some particular case?:

function password_policy_password_element_alter(array &$element = NULL, $account) {
  if (isset($element)) {
    $items = array();
    $policies = PasswordPolicy::matchedPolicies($account);

    foreach ($policies as $policy) {
      $items = $items + $policy->messages();
    }

    // Only alter description if policy messages are present.
    if (count($items)) {
      $element['#description'] = (isset($element['#description']) ? $element['#description'] : '') .
        theme('item_list', array(
          'items' => $items,
          'title' => t('Passwords must match the following requirements -'),
          'attributes' => array(
            'id' => 'password-policy-requirements',
          ),
        ));
    }

    // Attach password evaluation logic and ensure it's added after user.js.
    $element['#attached']['js'][] = array(
      'data' => drupal_get_path('module', 'password_policy') . '/password_policy.js',
      'weight' => 10,
    );

    // Add dependency of password_policy.js.
    $element['#attached']['library'][] = array('system', 'drupal.form');

    // Add clean URL setting for use by password_policy.js.
    $clean_url = variable_get('clean_url', FALSE);
    $settings = array('cleanUrl' => $clean_url);
    $element['#attached']['js'][] = array(
      'data' => array('passwordPolicy' => $settings),
      'type' => 'setting',
    );
  }
}

Looking a little more closely at the patch you created in #1, it's relatively close to what I added, except you're using a return to break out of the function.

I'm assuming the reason for the more lengthy approach in #4 is you're wanting to be more explicit in the solution?

This same problem exists with the Profile2 module. Looking at the patch, I'm wondering if there's a simpler way that it could be done, without hard coding user_profile_form and user_register_form in the code?

That would be ideal. I thought there could possibly be cases where $form['account']['pass'] is set but the element should not be altered. (The original authors may have hard-coded the form IDs for a reason.) So adding an extra condition seemed safest initially.

I'm not sure your proposed code change would work though. Have you tried it? On some forms, I believe $form['account'] will not be set, so accessing $form['account']['pass'] in the call to password_policy_password_element_alter() would give an error.

I'm assuming the reason for the more lengthy approach in #4 is you're wanting to be more explicit in the solution?

Yes, I wanted the purpose of the conditionals to be clearer. A problem I have had working with the code, especially the 1.x branch, is conditionals where it is unclear what they are doing or why they are necessary.

I did try my suggestion with Profile2 and it worked as I would expect, however as you mentioned it may not work in all situations.

Certainly a case where $form['account'] is not set would be an issue.

+1 for @ron_s #8 solution. The patches did not work for me. They fixed the fatal error, but nullified the password policy. Users could enter any password they wanted without any barrier from the password policy.

mudjunky, are you also using Profile2?

+1 on the commit in #6. While it may not be the simplest implementation as others have suggested, it does work and should $form['account'] be unset, everything still works well. This issue appears to be resolved.

@mudjunky re: #14 - Try the dev version or use the patch from it which should apply cleanly to alpha5.

I believe this is fixed in 7.x-2.0-alpha6 and onward, without hard-coding form IDs, by the patch committed in #2562481: Apply password policies to account password elements on custom forms:
http://cgit.drupalcode.org/password_policy/commit/?id=9f69062

If you experienced this error before, please retest with 7.x-2.0-alpha6 or later, and let us know whether it still occurs. If so, we can re-open. Thanks all.