Continuando a discussão de Discourse rewriting url path behaviour failing due to subfolder:
Tenho exatamente o mesmo problema do tópico mencionado, no qual a URL é reescrita apenas em cenários onde o início de uma sub-rota é igual à subpasta. Estou usando /f como subpasta; entendo as ressalvas e os problemas dessa configuração, mas tudo o mais está funcionando bem, então gostaria de ajuda para corrigir isso, se possível.
Não estou usando uma rota existente do Discourse, mas se a subpasta de uma letra for um problema, gostaria de tentar corrigi-la antes de considerar uma configuração diferente.
Algumas rotas que são reescritas:
/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
Como é uma reescrita no lado do cliente, fazer CURL nas mesmas URLs funciona bem.
Aqui está o commit que originalmente corrigiu isso, mas getURL mudou para usar os helpers get-url em vez de Discourse.BaseUri.
Seguindo as chamadas para esse getURL, location.pathname está correto na primeira chamada (começando com /f), mas em uma das próximas chamadas a subpasta é removida e torna-se /t/f-started-slug/id, fazendo com que este replace atue naquele /f.
Não conheço o suficiente dos internos do Discourse para entender completamente onde essa reescrita está ocorrendo, mas testando na minha instância, forçar o replace em withoutPrefix para atuar apenas no início de path parece corrigir o problema.
// alterando ...
return path.replace(rootURL, "");
// para algo como ... (assumindo que rootURL não precisa ser escapado)
return path.replace(new RegExp("^" + rootURL), "")
// ou sem regex ...
return path.indexOf(rootURL) === 0 ? path.slice(rootURL.length) : path;
Não sei se isso seria uma correção possível ou se introduziria alguma regressão; qualquer ajuda é apreciada.