Allowing Admins to place arbitrary links in topnav

Requests for admins to be able to add links to the topnav come up reasonably often here on Meta.

There’s this one:

There’s also this one, with discussion spanning 3 years!

Back in 2015, Jeff said:

Sam responded:

At the moment, the solution for this issue seems to be adding custom JS to the </body>. While this works, it’s not exactly user friendly (you need a basic JS understanding to add or change links), and could break at any time with a code change to Discourse.

I’d like to suggest the following 3-stage rollout:

  1. Provide a site setting for admins to add external links to the topnav. The site setting will need 3 values, I propose a comma separated list. title,tooltip,URL
  2. Provide a site setting for admins to add internal links to the topnav - without handling breadcrumbs.
  3. Improvinate #2 by handling certain cases where breadcrumbs make sense, like Tags, Users, Groups, Badges, etc.

The benefit to the 3-stage rollout is that external links require no routing by Discourse, nor breadcrumb support. They should simply be an href. Keeping steps 2 & 3 separate will allow for complaint driven development. Roll-out internal link support, see if there are complaints about the lack of breadcrumbs. Meta already has 2 internal links without breadcrumb support, and I’ve never seen a complaint.


Isn’t this what this plugin is trying to solve?

Or are you referring to an actual header?

Yes, that’s exactly it - but that’s a plugin, so it’s a no-go on hosted sites.


Well, sort of, until it gets enough traction or customers asking for it, then it gets adopted by the Discourse Team, which makes it more accessible to hosted sites (granted, I realize not all plugins are available for hosted sites)


I have no qualms with it being an officially supported plugin, however:

  1. I assumed from Jeff’s comment above he supports this feature in core.
  2. The plugin has known issues - including for the specific use case (topnav) that I’m looking to have supported.
  3. Plugins are more complicated for sysadmins to handle. They require ssh access to the server, are updated independently, break more frequently than core (less tests), and are a sticky subject for hosting (which plugins go for which plans).