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:

Instead of:

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.


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.


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…


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.


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



Nope, just assumed that still works fine

This has been on my list forever, would be nice to clear it off.

@kris.kotlarek can you see what is needed to sort out this tracking so it is redirect resilient?


Final test:
unescaped example above

It works now :slight_smile:
This is a test if the bug still exists as on my local machine it works fine. The issue was created a long time ago, so maybe it is already fine.

I see an inbound link: