Problème de redirections de permaliens dû au fragment après "#" non envoyé au serveur

MODIF : j’ai changé le titre du sujet pour qu’il corresponde au problème que j’ai découvert, grâce aux réponses ci-dessous

Je rencontre un comportement étrange avec les permaliens lors de mes travaux de migration.

Mon problème n’est pas celui des liens internes qui ne redirigent pas. Je teste simplement cela en collant des URL dans la barre d’adresse de mon navigateur.

Voici les deux redirections que je souhaite voir se produire lors de mes tests :

C’est une redirection de message, elle devrait rediriger vers le deuxième message comme ceci :

C’est une redirection de sujet, elle devrait aller vers :

Je sais que mes normalisations fonctionnent correctement. Mon expression régulière est :

/(?:.*)(\/)(?<topicid>\d*.)-(.[^\/#\?]*)(?<parm>\?(\w*)[=](?<start>\d+))?(?:\/)?(\D+(\/)?)?(?<postid>\d+)?(?:\/)?/normalized.\k<topicid>.\k<postid>

Et je les vérifie dans la console rails :

irb(main):069:0> Permalink.normalize_url('https://community.suitecrm.com/languages/17978-why-two-italian-language-packs#16249')
=> "normalized.17978.16249"

irb(main):068:0> Permalink.normalize_url('https://community.suitecrm.com/languages/17978-why-two-italian-language-packs')
=> "normalized.17978."

C’est ce que je voulais obtenir. J’ai ceci dans ma table Permalinks :

Et voici à quoi cela ressemble dans la base de données :

Mais lorsque j’entre ceci dans l’URL du navigateur :

Il est redirigé vers :

Au lieu de ce qu’il devrait être :

Donc, je vois le premier message, il ne défile pas vers le deuxième comme il devrait.

Pourquoi ce hash #16249 est-il réajouté, alors que ma normalisation l’a supprimé ?

Une autre façon d’exposer cette incohérence (bien que de manière un peu artificielle) est d’essayer les redirections suivantes depuis la barre d’adresse du navigateur :

https://community.suitecrm.com/normalized.17978.
redirige correctement vers :
Reports disappeared - 💬 General Discussion - SuiteCRM

Et Why two Italian language packs? - #2 by roberto - Translation and Language Packs - SuiteCRM
redirige correctement vers :
Reports disappeared - #2 by erevodifosin - 💬 General Discussion - SuiteCRM

Alors pourquoi cela ne fonctionne-t-il pas lorsqu’on suit le processus normal ?

Les permaliens ne fonctionnent que pour les liens entrants, c’est clairement indiqué dans la description.

Vous devrez corriger les liens internes.

J’ai mentionné au début de mon message que ce n’est pas le cas : je ne clique pas sur des liens dans mes propres forums.

Mais peut-être que je ne comprends pas ce que signifie ici « liens internes ». Pouvez-vous mieux expliquer ? Si je colle une URL dans la barre d’adresse du navigateur, en quoi cela constitue-t-il un lien interne ?

L’identifiant de fragment d’URL (le # et tout ce qui suit) n’est jamais envoyé au serveur par le navigateur — vous ne pouvez pas l’utiliser dans le cadre d’une redirection.

Maintenant que vous le dites, cela a du sens… mais c’est assez déprimant.

Je suppose que cela élimine complètement la possibilité de redirections appropriées au niveau des messages depuis mes anciens forums, puisqu’ils utilisent # pour cela :sob:

Est-ce une limitation courante rencontrée lors des migrations ? Il s’agit du logiciel Kunena, je suppose que c’est assez courant, et je parie que d’autres utilisent également des hachages pour lier des messages…

Je repense à tout cela dans ma tête. C’est une limitation vraiment agaçante. Je suppose que l’erreur fondamentale a été commise il y a longtemps, par les concepteurs des forums Kunena, en n’utilisant que des fragments pour marquer les liens vers les messages… soupir.

Je vois trois approches que Discourse pourrait adopter pour contourner ce problème (je m’aventure clairement dans le domaine du vœu pieux ici, profitez du voyage)

  1. Le JavaScript s’active au chargement de la page, détecte la présence d’un fragment de hachage dans l’URI, et utilise ce dernier pour appeler le serveur et effectuer une nouvelle redirection vers l’endroit approprié. Cela fonctionne, mais vous obtenez une double redirection et l’utilisateur voit la page se recharger.

  2. Discourse pourrait ajouter (côté serveur) une balise id avec l’ancien post_id importé à chaque message HTML. De cette façon, le navigateur transférerait l’ancien identifiant de hachage et l’utiliserait sur la page redirigée pour faire défiler jusqu’en bas. L’inconvénient majeur : le défilement sophistiqué de Discourse, où les messages ne sont chargés que lorsque vous faites défiler jusqu’à eux, rend ce schéma insuffisant.

  3. Un mélange des deux précédentes : Discourse construit (côté serveur) un tableau de correspondance entre les anciens post_id importés et les nouveaux post_number, et l’envoie au client lors du chargement de la page. Le JavaScript côté client détecte la présence d’un hachage dans l’URI, le traduit à l’aide du tableau, puis utilise ses propres fonctions de défilement pour descendre au message correct.

Cela serait fastidieux à mettre en œuvre et entraînerait une pénalité de performance. Cela permettrait toutefois des migrations parfaites…

Ce ne sont pas des solutions complètes car les redirections ne fonctionneront toujours pas sauf si l’utilisateur est déjà dans Discourse. Les liens externes ont beaucoup moins de chances d’arriver de cette manière.

Voici mon approche actuelle pour les redirections internes/externes :

Mon ancien site se trouve à l’adresse https://suitecrm.com/suitecrm/forum/, le nouveau à https://community.suitecrm.com/.

Lorsque le serveur migré sera en ligne, nous effectuerons une redirection de passerelle de l’ancien vers le nouveau.

Je laisse mes liens internes inchangés, en commençant par https://suitecrm.com/suitecrm/forum/. Lorsque quelqu’un clique dessus, cela est externe dans tous les cas pratiques. Ensuite, notre redirection de passerelle s’active, et le trafic revient dans Discourse, où les permaliens devraient fonctionner normalement.

C’est bien ça ? Je ne l’ai pas encore testé… Je suppose que ce serait impossible si nous voulions utiliser le même nom de domaine et le même dossier, mais ce n’est pas le cas.

Ce que vous devez faire, c’est utiliser des redirections de permaliens.

Je crée souvent des permaliens du type /oldpost/POST_ID, puis j’écris une redirection de permalien pour réécrire /forum./category/someslug#1234 afin d’utiliser ces liens.

Par « redirection de permalien », entendez-vous le paramètre du site « normalisations de permalien » ?

Oups ! Oui. Désolé. Mon cerveau était en retard.

D’accord :slight_smile:

Mais j’utilise des normalisations de permaliens (voir mon premier message). Seule la partie du hachage n’est jamais envoyée au serveur. Donc, à moins qu’il n’y ait une sorte de magie côté JavaScript, il est impossible qu’un forum utilisant uniquement des hachages pour les liens au niveau des posts soit jamais correctement migré (en termes de redirections) vers Discourse (ou vers tout autre logiciel).

Désolé. Je n’ai pas lu cela assez attentivement. Je pensais avoir utilisé des éléments après le hachage auparavant, mais je suppose que c’est incorrect. Je me souviens d’un cas récent où ces identifiants de publication hachés étaient présents, mais je suppose que le client ne voulait que des redirections au niveau du sujet. Je pense que pour les 301, aboutir au bon sujet est probablement suffisant.