Client-side path rewrite failing with subfolder setup

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.

1 Like

Oh well, a better search on existing topics would lead me to a reply from yesterday that might fix this…
https://meta.discourse.org/t/two-bugs-with-usernames-starting-with-subfolder-name/169505/6

EDIT: I just upgraded to 70050a8ba3 and the issue persists.

2 Likes

I will take a look a this as time permits.

4 Likes

This looks to be the way indeed, thanks for the investigation and bug report. This PR should fix it:

Can you give it a try @renato ?

2 Likes

It’s working great now, thanks!

2 Likes

This topic was automatically closed after 7 days. New replies are no longer allowed.