Customized header link target attribute being ignored


#1

I’ve tried a few dozen searches and can’t find an answer to this question so hopefully I haven’t just done a really poor job of searching.

I have customized the header of my Discourse install with a link to another site. That site is on the same domain but different sub-domain (so blog.example.com vs forum.example.com). I want the link to open in a new tab but no matter what I do it opens in the same tab. If I view the source of the page I can see that the target="_blank" is set on the link but it is being ignored. Is there something in Discourse that it overriding the default HTML link behavior? If so, can it be disabled?

I’ve read several topics about the “open external urls” setting in the Admin panel, and have already tried it with both logged in and guest users and it does not work for this link at least. I’d prefer a solution that worked even for guest users. Any help is appreciated.

Thanks


(cpradio) #2

What HTML/Code did you use to create said link in your header? Where did you place that code? Sitepoint has links at the top that utilize target="_blank" and it works just fine…


#3

Here is the code I used:

<script type="text/discourse-plugin" version="0.4">
api.decorateWidget('home-logo:after', helper => {
    const showExtraInfo = helper.attrs.minimized;
        if(!showExtraInfo) {
            return helper.h('a.blog-link', {href:'https://blog.example.com', target:'_blank'}, 'Visit our blog');
        }
});
</script>

I placed that in the Customize -> CSS/HTML -> </head> section. Running 1.8.0 beta4 (upgrading to beta5 to see if it helps).


(cpradio) #4

@eviltrout, this seems like a legitimate issue. Doesn’t apply to SP, because we use a different technique. But it is happening at Feverbee too, which I know are using a similar (if not the same) technique as described here.


(Mittineague) #5

Is the click being intercepted?


(cpradio) #6

Not sure, I may try debugging it later, but I was fairly certain it worked at Feverbee previously so I think this is a regression of some sort, but not sure why or where.

Edited:
So I did debug it, and maybe this never worked, though I could have sworn it did. But I don’t see anything obvious that is set to handle target="_blank", but it is definitely being intercepted by intercept-click.js.es6


(cpradio) #7

Oh this is interesting, if you take that code and change it to

<script type="text/discourse-plugin" version="0.4">
api.decorateWidget('header-buttons:after', helper => {
    const showExtraInfo = helper.attrs.minimized;
        if(!showExtraInfo) {
            return helper.h('a.blog-link', {href:'https://blog.example.com', target:'_blank'}, 'Visit our blog');
        }
});
</script>

It will open in a new window just fine.

So there seems to be a difference in how the clicks are handled when it is home-logo:after versus header-buttons:after


Why is the large middle blankspace in the header not configurable?
(Robin Ward) #8

Yeah the home-logo has special click handling:

We’ve gone over it many times to make sure the logo works the way people expect, but I guess it means it’s a bit weird if you add more formatting to it. I think it’s probably best if the link is placed elsewhere, like in @cpradio’s example.


#9

Thanks @cpradio and @eviltrout for the feedback. I’ve moved the code into the header-buttons area – not ideal but it gets the job done. It might be nice if there was a class or something you could apply to a link to override Discourse hijacking the link target. It certainly is confusing when you click on a link and it doesn’t behave in the standard way.


(Jeff Atwood) #10