Alteration of validation and submit callbacks can cause conflicts

Problem/Motivation

The list of modules altering the same user pass reset form callbacks grows each year. When this issue was created only 2 modules existed that have conflicts with the current situation, but more exist by now.

For a more in-dept + historical view of the issue, see comment #9 🐛 Alteration of validation and submit callbacks can cause conflicts Fixed .

Long story short:

username_enumeration_prevention, logintoboggan and user_registrationpassword (and other modules) change the password reset form validations/submit callbacks. This tends to break when these modules are used in combination with each other.

Also note that the current approach of lt/uep is to lookup+replace the callbacks, not hardcode them via a key. This leads to the same problem from another direction. How to replace a callback that does not exist - or has been replaced previously + how to make that mix work with all modules involved (priority in execution) (and especially account lookup depending on conditions. possibly provided by another module, in our case username_enumeration_prevention, feels like a 'should be fixed in core'-thing, but too large for D7 at this stage).

Drupal 7 is probably never going to address this, even in Drupal 8 it's still a problem for contrib. (see #2918984)

To fix this in core a lot has to happen, this issue only focuses on the current module. It's clear by now some parts have to change, while logintoboggan (for example) has a patch available to partially fix compatibility.

Proposed resolution

• Attempt to get logintoboggan issues fixed (at least #1773424).
• Revive the code that used to exist in user_registrationpassword for securing the password reset form (deprecating the need for username_enumeration_prevention once user_registrationpassword 1.6 is released - this prevents overcomplex code in user_registrationpassword to fix this case).
• Implement hook_module_implements_alter() and make sure we run last (or at least, try to) - and - only replace the core handler, not key 0 - and (re-)setting it as the first in the array.
• Once this has all landed, implement fixes for other modules that we want user_registrationpassword to be compatible with.

Remaining tasks

Assist with getting related issues fixed and testing upcoming patches.
Revive deprecated code that drops the need for username_enumeration_prevention once user_registrationpassword 1.6 is released. (Task: > RobC, patch WIP)
Implement hook_module_implements_alter() (Task: > RobC, patch WIP)

User interface changes

None

API changes

None that should break backwards compatibility.

Data model changes

None

Original by: alfaguru

This code in user_registrationpassword,module can cause conflicts with other modules that add their own validation / submit hooks.

<?php
/**
* Implements hook_form_FORM_ID_alter().
*/
function user_registrationpassword_form_user_pass_alter(&$form, &$form_state, $form_id) {
  $form['#validate'][0] = '_user_registrationpassword_user_pass_validate';
  $form['#submit'][0] = '_user_registrationpassword_user_pass_submit';
}

?>

The problem is that in each case the code wipes out the first hook in the array regardless of what it is. If another module puts its own hooks into the array ahead of all others, it will get overwritten. Overall, the outcome is not predictable.

My suggestion would be to search the array for the core callback that is replaced by default and only make the alteration if it is found. That leaves the door open for other module developers to override your callbacks if they need to. Something like this will work:

<?php
  $key_validate = array_search('user_pass_validate', $form['#validate']);
  if ($key_validate !== FALSE) {
    // Provide custom validator.
    $form['#validate'][$key_validate] = '_user_registrationpassword_user_pass_validate';
  }
  ... repeat for #submit
?>