Site relative paths rewritten client side incorrectly with subfolder

Bug
1

This was working correctly, but a recent update seems to have broken it again

Adding a relative link

[Full version 1.9.2 change history](/downloads/continuaci/continua-ci-version-history-v192)

results in the link being rendered correctly, and the markup is correctly, however when clicking on it the link turns into

https://www.finalbuilder.com/forums/downloads/continuaci/continua-ci-version-history-v192

Note our discourse instance is installed as a subfolder install under forums

It does look like there were some changes in this area earlier this year which might be related.

Currently running 2.8 beta1 - Commits ¡ discourse/discourse ¡ GitHub

3 Likes
2

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/*

2 Likes
3

This worked before, why was it changed?

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.

1 Like
4

So if you had a link on your main website starting with /t/something how would you know if it was a Discourse link or a link to your main website?

1 Like
5

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?

1 Like
6

I agree with @RGJ here. Sharing the same subfolder prefix between multiple applications is just asking for trouble.

It’s a “won’t fix” for me.

2 Likes
7

Seriously? If you write a url starting with / then by design it’s at the root of the site - you are redefining how html links work?

This was working fine for 2.5 yrs on our site - until the recent breaking change.

1 Like
8

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?

1 Like
12

We are investigating this issue, it is possibly related to this fix:

I agree that links to /jobs on acme.com should go to acme.com/jobs regardless of subfolder setup. They should not go to acme.com/forum/jobs.

7 Likes
14

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:

Please let me know if I can be of any help.

15

I investigated this this afternoon and have a fix in this PR:

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.

6 Likes
19

Not sure if this is related or not, but after pulling the update the link editor no longer works (shows up empty or doesn’t separate the fields).

20

This seems to be worse.

if I add a link
[forum relative link](/forums/t/continua-ci-v1-9-2-664-released/7058)

then it ends up as
[forum relative link](https:///forums/t/continua-ci-v1-9-2-664-released/7058)

which is rendered without the href attribute

21

BTW above tests done with Commits ¡ discourse/discourse ¡ GitHub

22

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

23

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:

2 Likes