Inbound links don't show up when topic ID is not included

Some just posted a topic on our forum that links to several other topics.

I was trying to figure out why the inbound links didn’t show up on the target topic and then I noticed that for some reason, they trimmed the topic ID from the link, for example, they posted something like:

https://meta.discourse.org/t/topic-list-previews/

Instead of:

https://meta.discourse.org/t/topic-list-previews/41630/613

Pasting the unescaped example above as well to illustrate here (so if you click that link, you should go to the Topic List Previews topic, but notice there’s no link on that topic back to this one).

Apparently that puts things in a state where the links to the topics work, but the inbound links on the destination don’t show up.

I’m not sure any change is warranted in the software regarding this issue, so I’m going to just advise the user to not trim the ID, but I thought it was interesting and worth documenting here.

That makes sense, the inbound link is incomplete without the topic ID and breaks totally if the topic title is changed. If you visit the URL without a topic ID the location in the header is amended to show the topic ID.

Throw your broken URL into curl --head to see what I’m referring to.

2개의 좋아요

Removing the ID also causes the link to break should the topic be renamed.

I was surprised the link worked at all, (even while the name matches). If I’d propose any change here it would be to make that stop working.

Why? It’s a simple convenience to preserve links where possible, if the stub matches are there any disadvantages to not punishing the user with an error?

Are we assuming that users always check links prior to posting? If so your users are much more disciplined than some of ours!

I would argue that working links are more important than working link tracking, but that could just be me.

2개의 좋아요

I guess it depends on the tradeoff about links breaking after renames… I’m not going to make a strong case either way, just saying that’s the only sensible alternative to the current behavior that I see…

In this case, I’m not going to bother editing the post. If the link breaks due to a rename later and someone complains, then we can edit the post to fix it.

Given that, “do nothing” still seems like the most reasonable action to take here…

4개의 좋아요

It’s sometimes convenient to have the /t/slug work (e.g., if the data was imported). It takes a very particular kind of user to remove the id from the end of the URL, so it’s very rare for a user to edit the URL and for the topic to be renamed.

5개의 좋아요

We definitely want to capture the the tracking, did you test if renamed slugs are tracked, that is a far more common case…

Eg: https://meta.discourse.org/t/old-slug/100551

2개의 좋아요

Nope, just assumed that still works fine

이건 제 목록에 정말 오래 남아 있었어요. 정리할 수 있으면 좋겠네요.

@kris.kotlarek 이 트래킹을 리다이렉트에 강건하게 만들려면 어떤 작업이 필요한지 확인해 주시겠어요?

3개의 좋아요

최종 테스트:
위에서 설명한 탈출되지 않은 예시

수정:
이제 작동합니다 :slight_smile:
내 로컬 머신에서는 정상적으로 작동하므로, 버그가 여전히 존재하는지 테스트하는 것입니다. 이 문제는 오래 전에 생성되었으므로, 이미 해결되었을 수도 있습니다.

인바운드 링크를 확인했습니다:
Screen Shot 2021-03-18 at 6.33.28 pm

2개의 좋아요