Don't you let the user.module decide to show the "user_login_block" or not.

This code block urls like "user/top", "user/whatever" ...

if (!$user->uid && !(arg(0) == 'user' && !is_numeric(arg(1)))) {
 $block['subject'] = t('User login');
 $block['content'] = drupal_get_form('user_login_block');
}

The visibility can be controlled via block options as always no need to have ab exception here. Please just remove the surrounding if()-condition which comes to simply

 $block['subject'] = t('User login');
 $block['content'] = drupal_get_form('user_login_block');

Comments

naden’s picture

naden commented
Component: user system » user.module
cvdenzen’s picture

cvdenzen commented
Version: 8.x-dev » 7.9
Category: task » bug
Status: Postponed (maintainer needs more info) » Active

This comment is wrong. I meant the navigation block, not the user login block.
I totally agree. The user login block is useful, e.g. for showing the name of the user that is logged in. It should not disappear magically when the user is logged in. In D6 it did not disappear, in D7 it does.
This issue was originally reported agains D6.9, but I think that is a mistake (if I look at the date of that report).

Everett Zufelt’s picture

Everett Zufelt commented
Version: 6.9 » 8.x-dev
Category: bug » feature

This is a feature request, and as with all feature requests, should be targeted at 8.x.

Since this would significantly change the UI on many sites, I cannot see this being a suitable candidate for backport to Drupal 7.

You can likely change the behavior on a specific site by implementing hook_block_view_MODULE_DELTA_alter().

cvdenzen’s picture

cvdenzen commented

This comment is wrong. I meant the navigation block, not the user login block.
It is a pity that we missed/ignored the (early) warning by naden. Many users will find it hard to upgrade from D6 to D7 because they are losing their user login block.
The great advantage of Drupal is it configurability. The current code is not exactly what we want.
The solution with the hook_block_view is likely to live a long time and clutter a lot of web site code.
I propose to change the user login block right now (in D7), and make the upgrade process automatically set the block settings in a way that there is no change in behaviour:
From D6 to D7: do not change the role specific visibility
From D7 to D7: set the role specific visiblity to 'anonymous user' if it was not set at all.
Is that a possibility?
Disadvantage:
It will make the (temporary) upgrade code more difficult.
Advantages:
It keeps the Drupal code clean.
The user login block behaves as users expect.
It makes an upgrade from D6 to D7 easier for a lot of users.
Thanks for reading this,
Carl van Denzen

Everett Zufelt’s picture

Everett Zufelt commented
Category: feature » task

This is not a bug, it performs as designed. All changes are made to 8.x and then backported to 7.x where appropriate.

So, let's get a patch for 8.x, which can then be discussed. If there is community support it will be committed to 8.x. Then we can discuss backporting the change to 7.x. I doubt this type of change will be backported,but I am not the one that makes that decision.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
Status: Active » Postponed (maintainer needs more info)

I'm genuinely confused.

The code in the OP is in Drupal 6's version of user_block(): http://api.drupal.org/api/drupal/modules--user--user.module/function/use... Drupal 7's version is literally a straight-up copy of it: http://api.drupal.org/api/drupal/modules--user--user.module/function/use... so I don't understand the argument that there's a regression here from D6. I've also never in all the Drupal sites I've ever built needed to customize this part of the visibility, because you simply don't ever want this block visible for non-anonymous users. If you're already logged in and re-submit that form, you get a 403 page. So what's the actual use case for pushing this setting to something that can be manually tweaked (and thus potentially broken)?

But at any rate, no, we can't push any changes to D7 that changes the visibility of this during a stable release. That would be incredibly jarring if the login block suddenly started showing up in production sites, and users flooding inboxes of site maintainers about 403 errors.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

Also this assertion:

"This code block urls like "user/top", "user/whatever" ..."

Is false, as far as I can see? user/top will fail the is_numeric() check. And you can't replicate the is_numeric() check in the block visibility textfield, so moving it there as "user/*" would block it from "user/top".

cvdenzen’s picture

cvdenzen commented
Version: 7.9 » 8.x-dev
Category: bug » task
Status: Active » Postponed (maintainer needs more info)

I also was confused. The user login block is not the block that triggered my attention. I have withdrawn my comments. It is the navigation block that bothers me. It doesn't show the users login name in D7, and it did in D6. But that issue should not go into this thread.
I am sorry for the confusion I created, but I am not a Drupal expert.

Carl (http://vandenzen.nl)

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
Status: Postponed (maintainer needs more info) » Closed (won't fix)

No worries, it happens. :) feel free to start another issue that outlines your concerns with the navivation block and we can discuss it, as I'm not quite sure the behaviour change you want.

Given #7 though I think fixing this would actually introduce problems, so I'm going to mark this won't fix. If I'm mistaken we can discuss.

cvdenzen’s picture

cvdenzen commented

There is already an issue about the navigation block not showing the user name as its title: http://drupal.org/node/1245368, so no need to create a new issue.