Last I checked, it didn’t seem possible to make permalinks like the latter. I haven’t tried the former, but I’m thinking that won’t work either. My current solution is to use Nginx rewrite rules to just remove the comment stuff so that those links will just fall back to the topic (rather than the post).
Remapping permalinks to anything other than the topic will be quite difficult. I would not even attempt it.
Here’s the crux of it: “list of topic IDs” is usually a reasonably small list, but “list of post IDs” is enormous. You may have 10k topics but you’ll probably have 50k, 100k, even 500k posts.
Remember in discourse Topic IDs are unique, that is to say:
http://discourse.example.com/t/topic-alpha/1234
This is “topic 1234”
But Post IDs in public URLs are not unique, meaning:
There is an internally unique ID for each post in Discourse but I don’t even know how you’d get to it. And at minimum you would need a 2.3M row table mapping each “old forum” post ID to the “new forum” Discourse internal post ID.
Good news: most public links are to topics, not deep links to posts anyway. So it’s a small number of links that will be affected, usually.
I’ve got the mapping from the old post-ids to the Discourse post-ids figured out, and use it to re-write IPB quotes to [quote="#username, post:#{postnum}, topic:#topicid}"], making those quotes appear like native Discourse quotes.
If there were a way to get Discourse would throw away the cruft after the topic URLs (e.g., allow a .* after the permalink), then I wouldn’t need to fuss with Nginx. Right now, links to topics work, but any link in the wild to a topic will 404. It shouldn’t be too hard to write the Nginx rule to drop the post-id part of the URLs, though.
Thanks, @gerhard. That’s very helpful. I have just learned that IPB has (at least?) two url schemes,so your code should make it easier to parameterize them. I don’t think I could have made sense of your code in August when I started writing importers, but now that I know Ruby, I can see that it’s pretty great!
