Je pense qu’il est raisonnable de supposer que tout lien relatif est relatif à la racine du sous-dossier. Ainsi, si vous souhaitez un lien en dehors du forum, vous devrez utiliser l’URL entièrement qualifiée.
Sinon, je pense que vous pourriez être en mesure de configurer un routage de lien permanent /forum/downloads/* vers https://example.com/downloads/*.
Je ne penserais pas que ce soit la norme attendue lorsque le chemin relatif est ancré, c’est-à-dire /downloads — dans le monde HTML/HTTP, cela suggère la racine du site, et non la racine du sous-dossier.
Donc, si vous aviez un lien sur votre site web principal commençant par /t/something, comment sauriez-vous s’il s’agit d’un lien Discourse ou d’un lien vers votre site web principal ?
Cela s’écrirait sous la forme /forums/t/something. C’est ce qu’un utilisateur public s’attendrait à voir en écrivant un post sur un forum. C’est ainsi que fonctionne la plupart des sites web — pourquoi quelqu’un saurait-il entrer /t/something ?
Sérieusement ? Si vous écrivez une URL commençant par /, alors par conception, elle se trouve à la racine du site — vous redéfinissez le fonctionnement des liens HTML ?
Cela fonctionnait parfaitement depuis 2,5 ans sur notre site — jusqu’à ce changement de rupture récent.
C’est là que réside le problème : Discourse ajoute le même préfixe /forums à plusieurs applications, ce qui cause les ennuis mentionnés précédemment. Je ne comprends pas pourquoi vous devez modifier l’URL saisie dans un message.
Nous enquêtons sur ce problème, qui est peut-être lié à cette correction :
Je suis d’accord pour dire que les liens vers /jobs sur acme.com doivent rediriger vers acme.com/jobs, quelle que soit la configuration du sous-dossier. Ils ne doivent pas rediriger vers acme.com/forum/jobs.
J’ai effectué le dernier commit sur get-url.js, quelque temps après celui auquel vous faites référence.
Je suis d’accord pour dire que les liens ne devraient pas être réécrits s’ils sont saisis par l’utilisateur ; peut-être que getURL ne devrait pas être appelé dans ces cas ? Je pense que getURL est destiné à être utilisé pour les routes par défaut de Discourse afin de les « convertir » vers la configuration en sous-dossier ; il contient des tests qui s’attendent explicitement à ce préfixe de sous-dossier :
N’hésitez pas à me dire si je peux vous être d’une quelconque aide.
J’ai enquêté là-dessus cet après-midi et j’ai une correction dans cette PR :
Malheureusement, notre code routeTo est conçu pour fonctionner avec des URL relatives. Ainsi, si nous appelons url.routeTo("/cool") et qu’un sous-dossier sub est configuré, cela le réécrit en /sub/cool, même si /cool semble relatif. Je ne pense pas que ce soit correct, mais je parie que beaucoup de code en dépend.
Heureusement, dans ce cas, c’est le suiveur de clics qui redirigeait car il pensait que l’URL était interne. J’ai ajouté une vérification pour m’assurer que le lien interne se trouve sur le même préfixe, et j’ai nettoyé les tests. Cela semble fonctionner.
Je n’ai aucune idée de la façon dont la régression s’est produite — j’ai essayé de faire un git blame mais sans succès.
Je ne sais pas si cela est lié ou non, mais après avoir téléchargé la mise à jour, l’éditeur de liens ne fonctionne plus (il s’affiche vide ou ne sépare pas les champs).
Nous avons également remarqué que les liens relatifs vers le même site, tels que /downloads, sont traités comme des liens externes et s’ouvrent dans un nouvel onglet du navigateur. Ce n’est pas vraiment un problème.
De plus, ce n’est pas grave non plus, mais si vous supprimez l’ID du message à la fin d’un lien vers un message du forum, comme je l’ai fait, l’historique du navigateur est perdu lors du clic sur le lien, par exemple ce lien.
Malheureusement, je ne parviens pas à reproduire ce problème. Localement, lorsque j’utilise exactement le même lien, il est généré correctement. Je devrais également préciser que mon correctif ne devrait pas modifier la façon dont les liens sont écrits en HTML ; il ne gère que ce qui se produit lorsque vous cliquez sur un lien.