Enable confirmation page also for registration form

I would argue that Passwordless does control user registration. More specifically, Passwordless does modify the behavior of the user registration form. For reference, documentation mentions:

Note

Passwordless disables the password fields in user-registration and user-profile forms, which means that:

the system takes care of creating a password for new users
there’s no longer a requirement for users to reenter their current password when they enter a new email address in their profile.

and respective codes look at the moment like:

    case 'user_register_form' :
      if (!empty($form['account']['mail'])) {
        $form['account']['mail']['#description'] = $mail_description;
        $form['account']['mail']['#required'] = TRUE;
      }
      // Hides the password field, and populates it with a random password
      $form['account']['pass']['#type'] = 'value';
      $form['account']['pass']['#value'] = sha1(user_password());
    break;

So, I would move this back to "Needs review" and hope that the maintainers see this the same way.

Hiding patch, switching to 2.0.x-dev and requesting a review for the PR if you please :-)

I tested the patch because I was interested in the solution. Unfortunately, the patch from the MR does not work for me, see error messages below. The registration worked, a new user was created, although the error appeared. Tested under Drupal 9.5.7 & PHP 8.1.

Login:

RuntimeException: Callable "Drupal\passwordless\Controller\PasswordlessController::sentPageAccess" requires a value for the "$action" argument. in Drupal\Component\Utility\ArgumentsResolver->handleUnresolvedArgument() (line 143 of core/lib/Drupal/Component/Utility/ArgumentsResolver.php).
Drupal\Component\Utility\ArgumentsResolver->getArgument(Object) (Line: 54)
Drupal\Component\Utility\ArgumentsResolver->getArguments(Array) (Line: 73)
Drupal\Core\Access\CustomAccessCheck->access(Object, Object, Object)
call_user_func_array(Array, Array) (Line: 160)
Drupal\Core\Access\AccessManager->performCheck('access_check.custom', Object) (Line: 136)
Drupal\Core\Access\AccessManager->check(Object, Object, Object, 1) (Line: 113)
Drupal\Core\Access\AccessManager->checkRequest(Object, Object, 1) (Line: 110)
Drupal\Core\Routing\AccessAwareRouter->checkAccess(Object) (Line: 95)
Drupal\Core\Routing\AccessAwareRouter->matchRequest(Object) (Line: 112)
Symfony\Component\HttpKernel\EventListener\RouterListener->onKernelRequest(Object, 'kernel.request', Object)
call_user_func(Array, Object, 'kernel.request', Object) (Line: 142)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.request') (Line: 145)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 81)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 191)
Drupal\page_cache\StackMiddleware\PageCache->fetch(Object, 1, 1) (Line: 128)
Drupal\page_cache\StackMiddleware\PageCache->lookup(Object, 1, 1) (Line: 82)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 49)
Drupal\remove_http_headers\StackMiddleware\RemoveHttpHeadersMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 718)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Register:

RuntimeException: Callable "Drupal\passwordless\Controller\PasswordlessController::sentPageAccess" requires a value for the "$action" argument. in Drupal\Component\Utility\ArgumentsResolver->handleUnresolvedArgument() (line 143 of core/lib/Drupal/Component/Utility/ArgumentsResolver.php).
Drupal\Component\Utility\ArgumentsResolver->getArgument(Object) (Line: 54)
Drupal\Component\Utility\ArgumentsResolver->getArguments(Array) (Line: 73)
Drupal\Core\Access\CustomAccessCheck->access(Object, Object, Object)
call_user_func_array(Array, Array) (Line: 160)
Drupal\Core\Access\AccessManager->performCheck('access_check.custom', Object) (Line: 136)
Drupal\Core\Access\AccessManager->check(Object, Object, Object, 1) (Line: 113)
Drupal\Core\Access\AccessManager->checkRequest(Object, Object, 1) (Line: 110)
Drupal\Core\Routing\AccessAwareRouter->checkAccess(Object) (Line: 95)
Drupal\Core\Routing\AccessAwareRouter->matchRequest(Object) (Line: 112)
Symfony\Component\HttpKernel\EventListener\RouterListener->onKernelRequest(Object, 'kernel.request', Object)
call_user_func(Array, Object, 'kernel.request', Object) (Line: 142)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.request') (Line: 145)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 81)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 49)
Drupal\remove_http_headers\StackMiddleware\RemoveHttpHeadersMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 718)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Hey @zcht, I wanted to look into the problem you reported, I didn't manage to reproduce it though. Can you give me a little more information? I tried it on a fresh standard Drupal 9.5.7 on Php8.1 and didn't get any errors. Any other modules that might play a part?

I can see the point of this issue, but:

1. I’m not sure why the confirmation should be different for login and registration—and in fact the proposed defaults are the same. Can we keep it simple and use the same settings for both, so there’s no need to have an update function?
2. The branch has changed a lot since this was proposed (I’d been meaning to refactor a few things for a long time), so this code will need to be rebased and adapted.

This issue will become obsolete if 📌 [Opinions welcome] Remove customizable options Needs review goes forward. (And I’m very inclined to make it go forward, unless I get massive pushback.)