Allow contrib modules to alter the redirect and ignored routes

Re-rolling patch for Password Policy 4.x

This patch works well for changing the redirect url.

But I agree that the $ignore_routes should be configurable or alterable with a hook,

Although it's easy to have a configurable redirect destination replace the hardcoded redirect to entity.user.edit_form, I am leaning towards #4's reasoning.

As far as password_policy (and any other module) is concerned, the password edit fields are in entity.user.edit_form as implemented in core. The change_pwd_page module replaced that location, so change_pwd_page should be in-charge of redirecting everyone to this new location, not the other way around where everyone has to adapt to change_pwd_page.

From a dependency perspective, this approach would have both modules not know of each other. password_policy only knows to send the user to entity.user.edit_form, while change_pwd_page only knows that it needs to redirect requests from entity.user.edit_form to its new page. This is kinda like how change_pwd_page is currently replacing user.reset from core's original path to its own. Maybe something similar can be done for entity.user.edit_form. But this work would have to be on change_pwd_page's side.

My 2c.

I have a custom module that creates its own page/form for changing the password similar to change_pwd_page, the entity.user.edit_form is still a valid path for editing other user fields. There is no way for me to know the intent of why a user ends up on entity.user.edit_form without checking for an expired password when on the entity.user.edit_form route a second time and then issuing a second redirect to my change password form.

It feels like it would be a a lot easier if both the redirect route and the routes excluded from redirection were either configurable settings or alterable in a hook or event subscriber.

If they were alterable, we wouldn't need to change the schema and any module could define its own redirect route an exclusion routes for not checking for expired passwords.

loze → changed the visibility of the branch 4.0.x to hidden.

MR!91 adds an alter hook. hook_password_policy_routes_alter(string &$change_password_route, array &$ignored_routes); This allows contrib modules to change these two variables.

in my use case I am using it like this

/**
 * Implements hook_password_policy_routes_alter()
 */
function MYMODULE_password_policy_routes_alter(string &$change_password_route, array &$ignored_routes) {
  // Our custom change password form.
  $change_password_route = 'entity.user.edit_form.change_password';

  // Ignore commerce checkout routes.
  $ignored_routes = array_merge($ignored_routes, [
    'commerce_checkout.form',
    'commerce_checkout.checkout',
  ]);
}

It also appears that with change_pwd_page, #2933747: Integration with password_policy → added some changes that rely on the patch here in #12.

If the approach I propose here is accepted, that commit could be reverted and all that change_pwd_page would need to do is implement the hook as follows

/**
 * Implements hook_password_policy_routes_alter()
 */
function change_pwd_page_password_policy_routes_alter(string &$change_password_route, array &$ignored_routes) {
  $change_password_route = 'change_pwd_page.change_password_form';
}

Instead of introducing all those update hooks that their solution added. It seems like a much simpler approach to me.

Re-rolling patch for 4.0.2+