As suggested, I’m trying to keep my old forum(s) “in place” while using discourse on the same domain. I managed to get nginx to proxy and work around any conflicts with discourse urls so everything works great on an initial page load (and for SEO purposes).
My problem is with linking out to those old links within discourse. The discourse app routing intercepts those urls as internal links and thus 404. I have tried numerous ways to get around this with the tools at hand but nothing works with urls or same-domain. (I also don’t want to put discourse in a subfolder)
If only I could add to the SERVER_SIDE_ONLY array to mimic what I’m doing in nginx, that should work. Anyone have any suggestions as to how to do this, or something else?
That’s not at all what that topic was recommending. You should start your new forum on a new subdomain and leave the old one behind.
I think that’s right. If you really want the old forum and the new one on the same domain (which, again, seems like a horrible idea for the issues you have already outlined), You could conceivably have another domain that’s a CNAME for the old one and have Discourse link to those, then it would think that it was a different server and wouldn’t try to handle those links itself and when nginx got the link, it would either just serve the data from the other domain or redirect the browser to the right one.
I considered putting the old stuff on an archive subdomain (risking impact to SEO), but even still I don’t think there is a way have Discourse change the link a user provides other than creating a permalink for every possible page. I suppose usage of the archive subdomain would eventually take over as people know about it and copy/paste from the browser address bar.
If you’d just done an import then there would be permalinks for all of those, but that’s not very helpful. And the kind of thing that someone who makes a considerable part of his living doing imports might think.
The easiest thing would be to move the new forum to a new URL (hopefully you’d not screw up much SEO yet) or move the old forum to another one (and lost SEO for the old stuff, though it might be possible to make a permalink normalization or NGINX magic that would do redirects). Has the new site been in place for long?
You might be able to create a permalink normalization. . . no. I think permalink_normalizations work only for permalinks and they can’t be external. It might be possible to have a theme component find matching URLs and re-write them with the fake/cname hostname, but I’m not sure what gets to the baked post (is it the full url with hostname, or does the cooking process strip the hostname?).
! I can handle this on the 404 page via a script in theme HTML…
I have the 404 page reload the browser window to the “missing” url which will hit the server-side. It works! Only downside I see is the redirect is noticeable and you get taken out of the app for any real 404s (losing the sidebar/header).
<script type="text/discourse-plugin" version="0.8">
api.onPageChange((url, title) => {
const router = api.container.lookup('service:router');
var is404 = document.getElementsByClassName("page-not-found");
if (is404.length) {
const params = new URLSearchParams(router.currentRoute.queryParams).toString();
let q = "";
if (params){ q = "?"+params; }
window.location.replace(window.location.origin + url + q);
}
});
</script>
Theme Component created! It looks for any hrefs to the hostname with a path that matches your provided regexes, then adds a click event to set window.location to skip internal routing.
Same-domain urls do get oneboxed and still have the same issue as a plain link. My theme component will apply to any <a href links in the post so it does work for oneboxed links too.
! I can handle this on the 404 page via a script in theme HTML…