The discussion revolves around allowing admins to add arbitrary links to the top navigation bar in Discourse. jomaxro highlights the frequency of this request and cites past discussions, including a quote from Jeff Atwood, who supports this feature. jomaxro proposes a 3-stage rollout to implement this feature, starting with adding external links, followed by internal links without breadcrumb support, and finally handling breadcrumbs for certain internal links.
jomaxro notes that the current solution involves adding custom JavaScript, which is not user-friendly and may break with code changes. cpradio suggests that a plugin might solve this issue, but jomaxro points out that plugins are not suitable for hosted sites. cpradio mentions that plugins can be adopted by the Discourse Team and become available for hosted sites, but jomaxro prefers a core feature due to the plugin’s known issues and the complexity of managing plugins for sysadmins.
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:
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
Provide a site setting for admins to add internal links to the topnav - without handling breadcrumbs.
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.
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:
I assumed from Jeff’s comment above he supports this feature in core.
The plugin has known issues - including for the specific use case (topnav) that I’m looking to have supported.
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).