Do not alter forms after calling drupal_get_form()

+function user_form_user_login_form_block_alter(&$form, &$form_state, $form_id) {
+  if ($form_id == 'user_login_form_block') {

That looks slightly redundant.

+++ b/core/modules/user/user.module
@@ -1568,6 +1560,28 @@ function user_set_authmaps($account, $authmaps) {
+/**
+ * Implement hook_form_alter().
+ */

Implements hook_form_FORM_ID_alter() :/

The downside of hook_form_alter() is that it runs only after retrieval of the form definition and is not cached with it.

So why don't we take the hook_forms() approach suggested here and skip the alter? I.e.:

function user_forms() {
  $forms['user_login_form_block'] = array(
    'callback' => '_user_login_form_block',
  );
}

function _user_login_form_block($form, &$form_state) {
  $form = user_login_form($form, $form_state);
  // Perform adjustments...
  return $form;
}

The reason for still using hook_forms() with this would be to automatically leverage Form API's built-in base form ID mechanisms (invoking hook_form_alter() additionally for the base form ID, likewise for #validate, #submit, and #theme).

Any reason to make another form? Original issue was about removal of 2 forms #1772584: Get rid of user_login_block() & user_login() in favour of user_login_form()
Originally @catch suggested this approach with customization in block, suppose it needs his review

Here's what I suggested in #8, but skipping the hook_forms() workaround.

The downside of hook_form_alter() is that it runs only after retrieval of the form definition and is not cached with it.

Huh? We cache not the retrieved form, but the prepared form, so alters are included.

I like #5 except for user.module altering its own form, and I prefer alters to be limited to a module altering something of another module. Ideally, we should change hook_forms() to decouple 'base form id' from 'callback', but I don't think it's worth making that part of the scope of this issue. Can we go with #5 for this issue, and have a follow up for improving hook_forms()?

Any reason to make another form? Original issue was about removal of 2 forms Originally @catch suggested this approach with customization in block, suppose it needs his review

Well, the original issue was about removing it as 2 totally disconnected forms: this issue is about making a form that's a customization of a base form, which seems the correct approach to me. I don't see comments in that issue which are incompatible with this issue, but please point one out if I missed something.

So #7 or #10 approach is a better?

Ping!

During rerolling this patch , the functions mentioned in the patch doesnot exist in the current 8.0.x branch . Hence this patch cannot be rerolled i guess .

Any thoughts?, otherwise we can close this issue.

I am removing the tag need reroll and changing status needs work to needs review.

Indeed--if the underlying logic has not been fixed already, this issue needs a summary update.

Thanks everyone who contributed to this issue.

Given that the latest comments were seeking additional information and none has been provided, I am marking this issue Closed (cannot reproduce).

If anyone believes this issue should not be closed, please provide specific steps to reproduce when reopening it.