Custom Header Links

[AndyatFocallocal]

I find the custom header links and burger links menus conflict with each other preventing admins from accessing the admin menu.

the use case we have, which i think is fairly common, is that we have a set number of links in the menu, yet on mobile there isn’t room for all of them. We resolve this by hiding some when the phone is held in portrait mode.

in this scenario a project like ours needs the ability to move some links into the menu when the phone is in portrait mode on a mobile (as we can do with the burger menu plugin). We also nee

[ariznaf (fernando)]

Great component.
Just what we were looking for: a way to show a simple menu with links to external pages and internal ones.

But we are having some trouble with it in mobiles. Is it a bug?
In a mobile -while displaying the forum in vertical view- there is no enough place for the menu and the standard buttons (search, site menu and user menu).
So the system hides that menus that are essential to forum navigation.

A user that is not connected cannot even connect, as he can not see the login button.

In horizontal view in the mobile everything seems to work OK.

If there is no place to put the header links, the component should show only the permanent (tagged as keep) ones and if there is no room either, just don’t show any link.
It is preferible to not showing the essential system menus.

Alternatively, if there is no room, the links could be displayed as a drop down list.

[ariznaf (fernando)]

That said, if you’re OK with some links being in the hamburger menu on mobile, then it follows that said links are not of the utmost importance and wouldn’t need to be in the desktop header in the first place. Have you considered using the Custom hamburger menu links component for these links alongside this component?

No, it is not that the links are note important, but impossible is impossible.
In the mobile in vertical position there is too few space, and the menu links are of less importance than the user menu, the hamburger itself or the login button.
So they should dissapear or be moved a a drop down list or the hamburger.

But in horizontal view there is enough space, so they should be showed.

Current implementation don’t let you decide to show them in other way in portrait mode or set different links in portrait or landscape mode in mobiles.

[awesomerobot (Kris)]

I’ve added a setting to this theme that allows the links to be displayed to the left as well. Due to the title position, these links are automatically hidden when scrolling within a topic.

[Jeremy_Marks]

I’m new to this. Added this, created my links, and the preview shows and works properly. However, in the live site the links don’t show up. I must be missing something. Can you help?

[simon (Simon Cossar)]

the preview shows and works properly. However, in the live site the links don’t show up

Have a look at the “Add theme components to a theme” section of How do I install a Theme or Theme Component?. It sounds like you might have missed that step.

[Jeremy_Marks]

Got it working. Thanks for that–I missed that last step of adding it to the theme.

[nobodyfrm]

Hi, is it possible to show the link only for users with a trustlevel greater then 1?

[knewt]

In a similar vein, is it possible to show a link only for users who are members of a particular group?

[pgr]

Our designer is having some problems with the responsive aspect of this (very nice and useful) add-on and she asks if she can change the breakpoint where it currently switches from the vdo to vmo elements?

Is this possible? Thanks

[pfaffman (Jay Pfaffman)]

Sure. Just fork and edit the theme component.

[pgr]

Thanks, I had a look but I don’t find it there… I guess it’s relying on some Discourse setting that applies throughout the site, not just for that menu?

Any way - we have it working with CSS media queries. Not ideal, but we can live with this.

[Johani (Joe)]

Our designer […] asks if she can change the breakpoint where it currently switches from the vdo to vmo

The switch from vdo - view desktop only - to vmo - view mobile only - is based on the user-agent in your browser and not on the width of the viewport you use / simulate.

CSS media queries are not as important in Discourse as they are in other sites that you might be accustomed to.

Discourse serves different optimized markup based on the device the user is on.

What I’m getting at is that you don’t need to worry much about CSS media queries. Your designer needs to either add ?mobile_view=1 to the URL they’re testing on, or use a mobile user-agent while testing / debugging things on desktop.

[pgr]

Interesting thanks for taking the time to explain.

But when I am on desktop, playing with my browser window size, I see Discourse reacting and rearranging stuff on screen. That’s not coming from my user agent string, I assume. Is there another mechanism reacting to screen size?

For example: that time-lapse scroll bar on the right disappears at small widths and is replaced by a smaller indicator with just the post number and total like 19 / 24

[Johani (Joe)]

But when I am on desktop, playing with my browser window size, I see Discourse reacting and rearranging stuff on screen. That ’s not coming from my user agent string, I assume. Is there another mechanism reacting to screen size?

You’re not wrong.

Discourse will move things around if you shrink your window size enough. We do this to accommodate for different desktop / laptop screen sizes.

That’s not the point here though. Shrinking the viewport won’t trigger user-agent change because it’s entirely based on the user-agent of the device you’re using.

If you’re on desktop and you change the window / screen width, Discourse will adjust to that as much as reasonably possible.

However, if you’re trying to test what Discourse looks like on mobile while you’re on desktop, then you need to either add

?mobile_view=1 to the URL they’re testing on

like I mentioned above

or test on a mobile device.

[Rhidian (Rhidian Bramley)]

Great theme component. Thank you.

Is there a way to hide the links if the user has to login to view the site content?
This is what my site looks like on the login page with the theme enabled.

[Steven]

Until there is a cleaner way to do it via an upgrade of the component, you can add this css lines in your theme

.anon .custom-header-links {
    display: none;
}

[nathankershaw]

@Steven

.anon .custom-header-links { display: none; }

This works a treat!!!

If any of you amazing coders out there could add the ability per link to make visible to

1. logged in users or
2. anon (eg not logged in) users or
3. all users

we would be extremely grateful!!!

[Steven]

Everything is still doable via css, but you have to create a line for each link which can take some time.

If we take the demo for this component :

'Custom Header Links' by @Johani

I’ll try your 3 scenarios with the Tech example.

Ex #1 visible to logged in users

.anon .headerLink.tech {
    display: none;
}

Ex #2 visible to not logged in users

.headerLink.tech {
    display: none;
}
.anon .headerLink.tech {
    display: inline-block;
}

Ex #3 visible to all users : don’t add anything

---

Replace text with the key word of your menu.

I’ll take a last example to help you. The css class to use for the item menu Your Vote Counts! is .headerLink.your-vote-counts

[nathankershaw]

@Steven

Replace text with the key word of your menu.

Dude! You rock! Sorted.

I’ve noticed that on hover, the link doesn’t change background colour like all the other ones in Discourse. I’ve tried to hack some CSS to cover that, which works well enough:

.custom-header-links .headerLink a:hover {
      background-color: #343434
}

It would be good to get this into the theme-component CSS, but I’m too much of a numpty to do that. Maybe time to get onto GitHub, eh?