Login block not shown on user/register

I believe this is a won't fix. I don't see this as a bug. The code comment included there explains why the login block isn't shown.

at user/register. There is a login tab on the register form. The code is doing what it is supposed to do AFAICT.

register form can be seen as the login form, especially when no approval or verification on the site is required as this setup automatically logs user in upon registration.

Patches welcome if you would like someone to review the changes you propose.

Is there a way to override this behavior via a theme? This can quite break a layout when you are depending on the block to fill out a region.

i'd think you could set a static region rather than a conditional one so that the "sidebar" is always there whether a block is enabled or not.

i agree with Jasu_M that registration form + login form on a same page is a valid use case.

just a note that this won't get dealt with directly in 6.19. It would have be dealt with in D7 or probably even D8 if this involves any API change. Thus the thread should likely be moved up stream if you all feel so strongly that this should be implemented. At which point this issue should be turned into a feature request rather than a bug.

+1 for this being a valid use case and a legitimate bug. Although the code is working correctly based on its own internal logic, I think from a usability perspective it would be much better to let a themer or site administrator decide how to configure this functionality. This seems like a very restrictive implementation of a well-intentioned idea.

Is there any way to turn off this feature/bug?

See also: Always show the login block (even when logged in)

turn off? without hacking core? doesn't seem like it.

I didn't dig to see if this can be overridden with a custom module either.

I also haven't checked D7 for the same, but someone in this thread that wants a different behavior should check and if it's still an issue this thread should be moved to a version of Drupal that is actively being worked on which isn't D6. Whether a change like this would make it into D7 and backported at this point I can't say. If the behavior wasn't changed in D7, this would likely have to be moved to D8 to be looked at for future versions. Especially if there is no patch being worked on by any one already involved in this thread. At this point there are few eyes to read this as its labeled 6.19 and most core developers are working on D7.

moving to feature request since the code comments note this was done for usablity. Thus not considered a bug as it's a known issue and specifically implemented with a defined reason.

Moving to Drupal 6.x-dev since code in 6.19 wouldn't be altered. Someone with interest will have to do the rest of the legwork to get this moving in a direction that satisfy's the desire wanted.

Thanks for the feedback VM, makes sense.

Another idea here is to at least have the UI better match the code. While it's nice that the code itself is well commented, a user would have no idea what's going on unless they happen to be sifting through the php in user.module. As far as I know there's no UI content that corresponds to the helpful code comment.

This thread comes up in a search which users should know how to do. That aside where in the ui
would any of this make sense? Perhaps in the core help.module which is a fairly easy patch for someone wanting to take initiative.

That's an interesting point, I did find this pretty quickly myself by searching drupal.org. Probably the same page that contains the user login block visibility settings would be a good place to mention that this one particular block has an unusual visibility restriction.

Does anyone know if there are adverse side effects to simply removing this restriction from user module, other than the standard problems that come from hacking core?

I'm attaching two patches for this issue. 893868-allow-user-pages.patch will both allow the user login block on user form pages and also improve the visibility settings UI. 893868-ui-enhancement.patch will only improve the visibility settings UI, but not change visibility functionality.

They both need review, but I prefer the first patch because it allows for greater flexibility. And it seems to work well with the redirect features in Login Destination module: http://drupal.org/project/login_destination

This issue seems to originate from Revision 1.175 of user.module:

http://drupalcode.org/viewvc/drupal/drupal/modules/user/user.module?view...
http://drupalcode.org/viewvc/drupal/drupal/modules/user/user.module?r1=1...

Rerolled the patches, hopefully they test better this time.

Trying again, not sure what the problem is.

Ok I guess automated testing is for D7 only: http://drupal.org/node/894166#comment-3693940

Here's another try.

Subscribe.

Wow, I got stuck by this, though i will try to convince my client that this is a case of better usability, i don't think it is.

Subscribe

Subscribe

ps: Surely this behaviour shouldn't be hardcoded - the way it is now is not drupalish from any point of view!

There's an easy workaround for this, which I can live with very well. Just create a new block with this as block content:

<?php
global $user;
if (!$user->uid) {
  print drupal_get_form('user_login_block');
}
?>

Then do with the block what you want. Don't forget to enable and use the PHP filter!

This should not be hardcoded, indeed. The block visibility options are already available for this kid of control.

The solution at #29 is fine for me, but I pity the n00b.

This isn't likely to get any traction or be changed until someone figures out whether it's still an issue in Drupal 8.x-dev. Which is where it needs to happen first then backported from there to D7 and D6.

I was just caught out by this. It took me hours of searching before realising that this is a "feature". I must strongly disagree with that assessment - this is definitely a bug. For every other block, it is up to the admin to determine the pages that should display the block, EXCEPT FOR THIS ONE!

If this "feature" is to be kept, then it should be changed so that it doesn't appear on the login page since in that case, the page would display two identical forms. But it is certainly a valid use case to allow the user to login or register (or retrieve forgotten pw) from the same page.

It's this kind of undocumented, hidden "feature" that makes Drupal so frustrating to the novice developer.

Rant over.

Just another workaround for D7, for those who don't want to use PHP code, hack the core or wait for the patch. I have created a sandbox module, download and enable, link: Custom Login Block

The problem with what is in Drupal core now is that is stops the user login block showing on /user/*, including user/password - where it actually makes sense to show the user login block, as well as multiple other paths under /user/.

Attached is a simple patch that adjusts this so that it actually only prevents the form from showing on /user and /user/register - which is more inline with the comment in the code that states "For usability's sake, avoid showing two login forms on one page.".

I also sort of agree that this kind of hardcoded rule really should not be in the code at all, although in the rare case where you might want to override that behaviour a simple custom block implementation is an easy solution.

Good point.

I would prefer a patch utilizing hook_block_info() though. Though that might have implications for users who are already using the visibility field.

36: 893868-drupal-user-password-block-visibility-D7-36.patch queued for re-testing.

Thanks to #29. A little messy but functional.

I spend hours trying to figure out why this block didn't show up. Enabled, Disabled, Edited Contexts, Views, Block, you name it.

Here's the Drupal 7 code for Comment #29's solution which worked for me.

<?php print(drupal_render(drupal_get_form('user_login_block'))); ?>

Just use block settings to limit to roles to anonymous.

This seems more like a bug instead of a feature request

This is a bug

There was a access check in code which checks login block should not shown on register url, here is the patch for the bug

Tested #46 its working fine.

Since this is a bug, we need test coverage for this.

See if I manage to write test for this.

I created new test Drupal\user\Tests\UserBlocksTest::testUserLoginBlockVisibility I decided to test other paths too:

  $paths = [
      'node' => TRUE,
      'user/login' => FALSE,
      'user/register' => TRUE,
      'user/password' => TRUE,
    ];

Attached only test to confirm that it would detect this issue, and second patch having #46 fix with the tests.

error: patch failed: core/modules/user/src/Plugin/Block/UserLoginBlock.php:77
error: core/modules/user/src/Plugin/Block/UserLoginBlock.php: patch does not apply

rerolled #52 The changes really only come down to some line-number changes, and a few out of context differences.

let me try to see what I did wrong there.

So in the test, when the DrupalGet tries to get the markup for the block, this is what is returned:

<div id="block-wk467xrv" role="form" class="block block-user block-user-login-block">
  
  <h2>hMhBCtHO</h2>
    
      
  <div class="js-form-item form-item js-form-type-textfield form-type-textfield form-item-name">
      Username
  </div>

  <div class="js-form-item form-item js-form-type-password form-type-password form-item-pass">
      Password
  </div>


  <div data-drupal-selector="edit-actions" class="form-actions js-form-wrapper form-wrapper" id="edit-actions--2"></div>


  <div class="item-list"><ul><li><a href="/user/register" title="Create a new user account." class="create-account-link">Create new account</a></li><li><a href="/user/password" title="Send password reset instructions via e-mail." class="request-password-link">Reset your password</a></li></ul></div>
 </div>

The test target has this assert:

  $this->xpath('//div[@class="block block-user"]/form[@id="user-login-form"]');

I will re-target for the .block-user-login-block, which should be sufficient.

retargeted the login block assert test. Please check the new targeting (visible in the diff) to corroborate that it makes sense.

Sorry for the lack of interdiff. Diff attached quickly.

Incidentally, I tested this manually, and via automated testing.

Targeting is okey. One thing - typo on patch file on line 23 hided->hidden, but otherwise i will set RTBC!

After committing this, lets create a follow-up novice issue for changing that typo.

Normal bug, fixed with no disruption. Committed 18802aa and pushed to 8.0.x. Thanks!

diff --git a/core/modules/user/src/Tests/UserBlocksTest.php b/core/modules/user/src/Tests/UserBlocksTest.php
index 87446c4..8909fe4 100644
--- a/core/modules/user/src/Tests/UserBlocksTest.php
+++ b/core/modules/user/src/Tests/UserBlocksTest.php
@@ -40,9 +40,8 @@ protected function setUp() {
   }
 
    /**
-   * Test that user login block is hided from user/login, but not from 'node',
-   * user/register or user/password.
-   */
+    * Tests that user login block is hidden from user/login.
+    */
   function testUserLoginBlockVisibility() {
     // Array keyed list where key being the URL address and value being expected
     // visibility as boolean type.

Should be one line and does not need to be quite so descriptive.