Internal topic link behavior on non-http installs


We’ve noticed that linking a topic by using the full url e.g. vs the relative url /t/topic-slug/123 result in different behaviors on our site.

Linking the full url ( will cause the whole page to reload (and clicks don’t get counted), whereas the relative url (/t/topic-slug/123) will refresh the ember outlet without having to refresh the entire page.

Posted Internal Link Not Loading Dynamically
(Jeff Atwood) #2

Hmm is this something we can fix @eviltrout?

(Robin Ward) #3

I just tested this locally and couldn’t reproduce it. Are you talking about creating links within a post using markdown? Are they on their one line (oneboxed) or embedded within text?


They’re markdown’ed like this:

[Link to topic A][1]
[Link to topic B][2]

[2]: /t/slug/222

(Rafael dos Santos Silva) #5

Yeah this happens with me too, found it while linking the FAQ to the about page with a full link.

(Robin Ward) #6

I just used the same markup in my test environment and it didn’t force a full refresh. Here’s an example on meta:

Link to topic A
Link to topic B


That’s weird. I was able to reproduce it on my local vmware copy of discourse (both copies are non-https).

Another thing I noticed is that the the full link will work if you click on the link after you post a link or edit the post, but will do a full page once you come back. :confused:


I think I may have figured out what is causing this issue…

Looking at the page source, I noticed that the full links causing a full page refresh were cooked like this:
<a href="//">topic a</a>
whereas the ones that would work (such as the ones in the gutter) included the http: prefix:
<a href="">topic a</a>

Your link above seems to include the https: prefix, and thus works as expected.

Posted Internal Link Not Loading Dynamically
(Jeff Atwood) #9

How are you getting unprefixed links, though? Manually entering them?


I have no idea. The link has the http:// prefix when I submit a new post/link, but it then get removed when I come back to that post.

edit - it’s missing the http prefix in the api json, so it’s not a browser issue…

(Jeff Atwood) #11

Describe, step by step, the buttons or keys or touchscreen presses you made to create the post with the problem? I am not following.


It doesn’t really seem to matter how we do it, internal links just seem to have their http prefix removed once ‘cooked’:

(Sam Saffron) #13

Can you repro this on ? Its a non HTTPS site, we only do the // hack on non HTTPS sites.


Seems to be working as it should with the full url…

(Kane York) #15

This is probably an oddity around using an IP address… what happens if you assign that IP address the name discourse.internal and tell Discourse that that’s its hostname?


Same issue with a real domain - that’s where we actually noticed the issue and were able to reproduce it on a vmware install (w/ip address). I can try to assign a name to the vmware and see if it still has the bug.

I believe @falco also has the same issue on a live site.

Ok looks like it has nothing to do with the domain/ip address, just rebuilt my container with DISCOURSE_HOSTNAME: ‘discourse.vm’ and it does the same thing:

(Kane York) #17

Do not use discourse.vm, because IANA/ICANN/whatever might decide to make .vm a TLD at some point. How about discourse-vm.internal or discourse.vm.local?


Rebuild the container with discourse.local as the hostname, no plugins, v1.4.0.beta7 +76.
Still missing the http on the cooked posts:

"cooked": "<p><a href=\"//discourse.local\">Domain Link A</a><br><a href=\"//discourse.local/t/test-link/280/2\">Domain Link B</a><br><a href=\"\">IP Link</a> <br><a href=\"\">External Link</a> </p>",

(Jeff Atwood) #19

I guess if we can’t repro the behavior, it is something specific to your install…


I guess could always just write a script to add the missing http to the cooked version, but it does seem to be a bug since I was able to reproduce it on a live digital ocean install and a local vmware install.

Is there a setting to disable this?