Problem/Motivation

After overriding the /user/login page with Page Manager, placing the user login block on the page doesn't show the block.

Steps to Reproduce

  1. Create a page_manager instance to override the /user/login route
  2. Place the user login block on the page
  3. Visit the page, the user login block isn't displayed.
CommentFileSizeAuthor
#5 unable_to_override_user-2801511-5.patch782 bytesnitebreed

Comments

mdeltito created an issue. See original summary.

sebastien m.’s picture

Hi,
The issue seems to moved a few. Now I can create the page, but I'm unable to include in the page the user form login.
I'm can include the search form, and other block, but I can include login form.
Does someone perform to do it ?
Thanks

damienmckenna’s picture

Issue tags: +Needs tests

Lets put together a test to make sure this block can be added to a display.

andrii_svirin’s picture

I have by this uri /user/atatat throwing exception that is not presented in themed 404 page error. May be this is can help.

nitebreed’s picture

Title: Unable to override User Login with Page Manager » Can't place user login block on user/login when using Page Manager
Project: Page Manager » Drupal core
Version: 8.x-1.0-alpha21 » 8.4.x-dev
Component: Miscellaneous » user.module
Issue summary: View changes
StatusFileSize
new782 bytes

I changed the title & description, because the original issue doesn't exist anymore. The other issue mentioned in #2 is the real problem now.

I attached a patch that fixes this, although I'm not sure this is the right fix because I don't know why the code was there in the first place; in the blockAccess() function there's a check if the current route isn't 'user.login'. Well in our case it IS. Can someone verify why this code was originally set up?

nitebreed’s picture

Status: Active » Needs review

Status: Needs review » Needs work

The last submitted patch, 5: unable_to_override_user-2801511-5.patch, failed testing.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

tstoeckler’s picture

Can someone verify why this code was originally set up?

I didn't do any digging but I'm pretty sure that this is just legacy code, because generally it does not make sense to display a login block if the main page content is already the same login form. However, that should be accomplished using the path visibility configuration of the respective block, not hardcoded in the block plugin. Not sure why the logout route is there as well, as that will always just redirect anyway, so it will never display any blocks.

So, I think we should do the following:

  1. Remove the ::blockAccess() implementation entirely from UserLoginBlock
  2. Add a post-update function that adds the /user/login and /user/logout paths to all existing login blocks for backwards-compatibility. This will need to take into account the possibility of path visibility already being set for any block.
  3. Alter the configuration form for the login block so that the /user/login path (but not the /user/logout path) is excluded by default

If people agree with that plan, we can update the issue summary accordingly.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

piggito’s picture

Can someone verify why this code was originally set up?

I tracked it all the way back to d7 issue https://www.drupal.org/project/drupal/issues/345866 with comment // For usability's sake, avoid showing two login forms on one page. so I believe this confirm we are save to remove this constraint to give user full control over block placement in page manager.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.