Removing extra buttons from "Login required" screen

ux
1

Hello everybody.

I have set up a Discourse forum for university internal use, so it’s invitation only with no guest reading. I’ve disabled signing up feature too. But when I log out from my account, I see a screen with four buttons doing basically the same thing: two “Sign in” buttons, search button, and hamburger button. All of them just spawn login dialog.

Of course, this isn’t an issue I can’t live with, but it hearts my feelings each time I see all these buttons making extra entropy to the Universe.

  • What can I do to get rig of them?
  • What can I do to free the upstream of them?

There is a screenshot attached to show how it looks. Sorry for this being in Russian.

Screen Shot 2015-10-06 at 01.56.52.png730×541 63.5 KB

1 Like
2

Have you considered that it actually provides more chances for people to stumble onto your login prompt? It may be painfully obvious to you that there are multiple ways to activate the login box, but most folks need all the help they can get.

4 Likes
3

Adding this to the admin/customize/head section will hide the header login and dropdown menu buttons on the login page. There might be a better way to do this.

This kind of thing would be easier if Discourse added some more descriptive css classes to the body,

<script>
    Discourse.ApplicationController.reopen({
        // Gets the current pathname
        currentPathDidChange: function() {
            Discourse.currentPath = window.location.pathname;
        }.observes('currentPath')
    });
    
    Discourse.ApplicationView.reopen({
        didInsertElement: function() {
            this._super();
            if (Discourse.currentPath === '/login') {
                $('.d-header .panel').css('display', 'none');
            }
        }
    });
</script>

Screenshot 2015-10-05 18.17.04.png811×314 18.2 KB

4 Likes
4

The answer to that, for small UX issues, is “make a coherent, valid point for removing them here on meta and someone will make a PR (or a core dev will commit the change)”.

However, I agree with @ky_metro - the header on the login gate mimics that of what you see after logging in, and what other Discourse sites look like, but there isn’t anything we can put there that isn’t a privileged action on a login-required site. So they all funnel to the login modal.

5

You mean something like that cognitive bias? Maybe. But I really cannot believe that people nowadays need that much help to find a login form.

Thank you for your solution, it seems to work and I cannot see any side effect yet. You really saved my eyes from too much tearing. I’ve tried to solve the problem by myself first, but I couldn’t figure out any difference I could exploit in CSS to hide these buttons.

Maybe at least disable exta button, to see that they’re here, but inaccessible? But I really don’t insist on the change if the rest of community is happy with the buttons. I think I’ll be okay with the ad-hoc solution proposed above.

6

There might be a problem with this. It’s adding a currentPath property to the Discourse object. It might not be a good idea to do that in a customization. I’ll look at another way to do it later today.

7

Simplest way is just with a bit of CSS, if we are missing a class to target it we should add.

In the past we did not have the button there and some were confused about how to log in.

2 Likes
8

That would be great!

9

@simon @sam : Is this handled ? How can I achieve this ?

10

I can’t see how this would be a problem with CSS.

11

The css class static-login is added to the body tag of the login-required page. To hide the login button in the header do something like this:

.static-login .d-header .login-button {
    display: none;
 }

To hide the login button that is in the main content area do something like this:

.static-login #main-outlet .login-button {
    display: none;
}
6 Likes