Redirecting internal links via routes

AI-generated summary

The discussion revolves around redirecting internal links via routes in Discourse. attj has created a plugin to redirect example.com/[0-9]+/[0-9]+ to example.com/tag/$1-$2, but it doesn’t work for internal links. pfaffman suggests rewriting internal links in raw posts and rebaking. However, this solution has limitations.

attj explains that the goal is to use example.com/123/456 as a shortcut for example.com/tag/123-456. The issue arises when users post internal links, which don’t trigger the redirect.

attj shares the context of their website, which creates a one-to-one correspondence between research papers and tags. They want users to be able to replace the preprint server URL with their website’s URL and land on the same page.

pfaffman suggests creating a theme component to rewrite links when entered into a post. attj finds a partial solution using a linkify words in post component, which replaces links with the desired format, but doesn’t work with URLs prefixed with https://.

I currently have the following redirection on my website: example.com/[0-9]+/[0-9]+ → example.com/tag/$1-$2 where $1 and $2 are the values from the previous regex. I wrote this simple plugin below and it works perfectly if I type example.com/[0-9]+/[0-9]+ to the url bar. However, if I give the same link in a post inside discourse, the redirection doesn’t work. Is there a way to accomplish this?


Discourse::Application.routes.append do
    get '/:year/:id', to: redirect('/tag/%{year}-%{id}') , constraints: {year: /[0-9]+/, id: /[0-9]+/}
end

You need to rewrite the internal links in the raw posts (and rebake).

This would only change the current posts so far right? Do I need to do it after every new post then?

New links will be written by Discourse so they will be correct from the start.

Or maybe you’re going to import more posts, in which case you’ll modify the import script to fix them.

My initial purpose to have that route is not related to imports. I would like to use example.com/123/456 (123 and 456 is arbitrary here as long as they are both [0-9]+) as a shortcut for example.com/tag/123-456 so it is not semantically “wrong” to use it.

However, the route doesn’t work for internal links (I need to refresh the website to make the route work), hence I need to detect each example.com/[0-9]+/[0-9]+ and change it to example.com/tag/[0-9]+-[0-9]+ which looks practically impossible to do without parsing each new post one by one.

Sorry. I missed that your issue is that you don’t like the route for tags. Why do you think it will be valuable to change that route? Are people going to be typing them by hand? They’d not it, because discourse will let them search and enter them.

Can you take a step back and say what problem you’re solving by taking “tag” out of the tag route?

My website creates a one to one correspondence with research papers in a preprint server and tags. My users are used to visiting the website preprint.com/123/456. For a paper with id 123-456. This corresponds to mywebsite.com, hence I have a route that redirects mywebsite.com to mywebsite.com.

The idea is that users can hot-swap preprint.com with mywebsite.com and land on the exact paper’s page that they were browsing on the preprint server. This was working fine until someone gave an internal link mywebsite.com in a post and we realized that it is not redirecting and instead gives a 404. I am using Discourse for a very specific and targeted user base, hence, my usecase may sound strange.

Aha. Then I think you want a theme component that will rewrite those links when they are entered into a post. I’m not quite sure how to do that. One, that would require a bit of user training would be bbcode for those links. But I think a theme component could just hijack those links and rewrite them when they get baked.

After you mentioned the theme components, I was able to partially accomplish what I was looking for using the following component: Auto-Linkify Words

It perfectly supports regex so I was whenever someone types mywebsite.com, it successfully replaces the link with mywebsite.com.

The only thing left is it doesn’t work if someone types the url with prefix https://. It’s still a very nice component though.

Nice! I think that a custom theme component could fix the ones with https too, but maybe you can try to train people out of that, or to use #123-456