A recent update in Discourse has broken relative link rendering in a subfolder setup. When a user adds a relative link starting with /, it is incorrectly rendered as a link within the subfolder instead of the site root. For example, [Full version 1.9.2 change history](/downloads/continuaci/continua-ci-version-history-v192) is rendered as https://www.finalbuilder.com/forums/downloads/conti nuaci/continua-ci-version-history-v192.
vinecentp and Dave_Sparks argue that a link starting with / should be relative to the site root, not the subfolder root. However, RGJ and Falco believe that relative links should be relative to the subfolder root.
The issue is being investigated by the Discourse team, and a possible fix has been proposed in this PR. The issue may be related to a previous fix that changed the way relative links are handled. renato suggests that the getURL function should not be called for user-entered links.
Additionally, some users have reported other issues related to link rendering, such as the link editor not working correctly after pulling the update and relative links to the same site being treated as external links.
I think it’s fair to assume that any relative link is relative to the subfolder root. So if you want a link outside of the forum, you’ll need to use the full-qualified URL.
Alternatively I think you might be able to set up a permalink routing /forum/downloads/* to https://example.com/downloads/*
I wouldn’t think this would the normal thing to expect when the relative path is anchored, ie /downloads - in html/http world this suggests at root of of the site, not the root of the subfolder.
It would be written as /forums/t/something. This is what a public user writing a forum post would expect. It’s how most websites work - why would someone know to enter /t/something?
That is the issue, discourse is adding the same prefix /forums to multiple applications and this is causing the aforementioned trouble. I don’t understand why you need to alter the URL entered into a post at all?
I’ve made the last commit to get-url.js, some time after the linked one.
I agree links shouldn’t be rewritten if they’re user-entered, maybe getURL shouldn’t be called in these scenarios? I think getURL is supposed to be used for Discourse default routes to “convert” them to the subfolder setup, it has some tests explicitly expecting this subfolder prepending:
Unfortunately our routeTo code is designed to work with relative URLs, so if we call url.routeTo("/cool") and there is a subfolder of sub setup, it’ll rewrite to /sub/cool even though /cool looks relative. I don’t think this is correct but I bet a lot of code depends on it.
Fortunately, in this case it was the click tracker that was redirecting because it thought the URL was internal. I added a check to make sure the internal link is on the same prefix, and cleaned up the tests. It seems to work.
I have no idea how it regressed though - I tried to git blame and came up empty.
We have also noticed that relative links to the same site such as /downloads are treated as external links and open in a new browser tab. This is not a big deal really.
Also, not a biggy, but if you remove the post id from the end of a link to a forum post link, like I did, the browser history gets lost when clicking on the link e.g. this link
Unfortunately, I can’t reproduce this. Locally when I use the exact same link it cooks properly. I should also add that my patch should not change the way links are written as HTML, it only handles what happens when you click on a link.
I believe this is being looked at already, thanks: