I’ve been going over this in my head. It’s such an annoying limitation. I guess the basic mistake was made long ago, by the Kunena forums designers, in using just fragments to mark post-links… sigh.
I see 3 approaches that could Discourse could use to work-around this (I’m going clearly into wishful thinking territory here, enjoy the ride)
Discourse could add (server-side) an id tag with the old imported post_id to each post’s HTML. This way the browser would transfer the old hash id, and use it in the redirected page, scrolling to the bottom. Main caveat: Discourse’s fancy scrolling, where posts are only loaded when you scroll to them, makes this scheme insufficient.
This would be laborious to implement, and have a performance penalty. It would allow the perfect migrations to occur, though…
My current approach for the internal/external redirects is this:
My old site is at https://suitecrm.com/suitecrm/forum/, the new one at https://community.suitecrm.com/
When the migrated server goes live, we do a Gateway redirect from the old to the new.
I leave my internal links unchanged, starting with https://suitecrm.com/suitecrm/forum/. When somebody clicks them, that’s external for all practical purposes. But then our Gateway redirect happens, and it comes back into Discourse, and the permalinks should kick in normally.
Right? I haven’t tried this out yet… I guess this would be impossible if we wanted to use the same domain name and folder, but we don’t.
Sorry. I didn’t read that carefully enough. I thought that I’d used stuff after the hash before, but I guess that’s wrong. I remember a recent case where those hash post ids were there but I guess they client wanted only topic level redirects. I think that for 301s ending up at the right topic is likely good enough,