Continuing the discussion from Discourse rewriting url path behaviour failing due to subfolder:
I have the exact same issue from the aforementioned topic, in which the URL is rewritten only in scenarios where the start of a sub-route is equal to the subfolder. I’m using /f as subfolder, I understand the caveats and pains of this setup, but everything else is working fine so I’d like to get some help fixing this, if possible.
I’m not using an existing Discourse route, but if the one-letter subfolder is an issue I’d like to try fixing it before considering a different setup.
Some routes that get rewritten:
/f/t/food-chain-magnate/4826→/f/tood-chain-magnate/4826/f/tag/food-chain-magnate→/f/tagood-chain-magnate/f/u/renato/follow/following→/f/u/renatoollow/following/f/u/fred/summary→/f/ured/summary
As it’s a client-side rewrite, CURL’ing the same URLs works fine.
Here’s the commit that originally fixed this, but getURL has changed to use get-url helpers instead of Discourse.BaseUri.
Following the calls to that getURL, location.pathname is correct on first call (starting with /f), but on one of the next calls the subfolder gets stripped and becomes /t/f-started-slug/id, causing this replace to act on that /f.
I don’t know enough of Discourse internals to fully understand where this rewrite is taking place, but testing in my instance, enforcing the replace in withoutPrefix to only act at the beginning of path seems to fix it.
// changing ...
return path.replace(rootURL, "");
// to something like ... (assuming rootURL doesn't need to be escaped)
return path.replace(new RegExp("^" + rootURL), "")
// or without regex ...
return path.indexOf(rootURL) === 0 ? path.slice(rootURL.length) : path;
I don’t know if that would be a possible fix or if it would introduce any regression, any help is appreciated.