Supprimer le titre de l'URL casse les liens

All three of the following links are to the second post in this topic. However, only the first two work. The third one worked until very recently, and we use it pretty extensively in our community to avoid cluttering wiki posts that reference several posts within the topic. That third link now just loads endlessly and never actually shows the content.

[full title link](https://meta.discourse.org/t/link-to-post-within-same-topic-doesnt-work-if-there-is-no-title-in-the-url/121455/2)
full title link

[short title link](https://meta.discourse.org/t/short/121455/2)
short title link

[no title link](https://meta.discourse.org/t/121455/2)
no title link


P.S. Sorry about not using try.discourse.com earlier. I’ll create an account over there for next time.

Second post to demonstrate the bug.

What you’re actually using there is a hack, especially if it is a deep link to a specific post. This is the correct permalink URL form

https://meta.discourse.org/t/{title}/{topic-id}/{post-id}

This has been hacked up to work, when people accidentally omit the topic ID, we guess that if the “topic title” is all numeric, they meant the topic ID:

https://meta.discourse.org/t/{topic-id}

So this works

https://meta.discourse.org/t/121455

but this cannot, for what I hope are obvious reasons

https://meta.discourse.org/t/topic-title

But adding the post number to that is riskier.

I recommend not relying on sort of hacky undocumented behaviors, though, and switching to this formally supported form

https://meta.discourse.org/t/x/121455/2

The third link does work if you open it in a new tab. It’s only when you click within one tab that it breaks. And it breaks bad - you can’t even click the logo to go back to the front page of the forum.

TypeError: Cannot read property 'get' of undefined
    at n.setupController (application-779d3dc401b01d1322f0bf8b26cb0e5f4c83a62f26cbecbd52159a94370dffc3.br.js:68)
    at n.a.setup (ember_jquery-0ae86c6a7527a99c2b9b8a11521273bd9cb4f7d41bc546df081b7ee94f26d9c3.br.js:8)
    at i (ember_jquery-0ae86c6a7527a99c2b9b8a11521273bd9cb4f7d41bc546df081b7ee94f26d9c3.br.js:17)
    at u.n.routeEnteredOrUpdated (ember_jquery-0ae86c6a7527a99c2b9b8a11521273bd9cb4f7d41bc546df081b7ee94f26d9c3.br.js:17)
    at u.n.setupContexts (ember_jquery-0ae86c6a7527a99c2b9b8a11521273bd9cb4f7d41bc546df081b7ee94f26d9c3.br.js:17)
    at u.n.finalizeTransition (ember_jquery-0ae86c6a7527a99c2b9b8a11521273bd9cb4f7d41bc546df081b7ee94f26d9c3.br.js:17)
    at ember_jquery-0ae86c6a7527a99c2b9b8a11521273bd9cb4f7d41bc546df081b7ee94f26d9c3.br.js:17
    at f (ember_jquery-0ae86c6a7527a99c2b9b8a11521273bd9cb4f7d41bc546df081b7ee94f26d9c3.br.js:17)
    at T (ember_jquery-0ae86c6a7527a99c2b9b8a11521273bd9cb4f7d41bc546df081b7ee94f26d9c3.br.js:17)
    at E (ember_jquery-0ae86c6a7527a99c2b9b8a11521273bd9cb4f7d41bc546df081b7ee94f26d9c3.br.js:17)

Error while processing route: topic.fromParams Cannot read property 'get' of undefined TypeError: Cannot read property 'get' of undefined
    at n.setupController (https://d11a6trkgmumsb.cloudfront.net/assets/application-779d3dc401b01d1322f0bf8b26cb0e5f4c83a62f26cbecbd52159a94370dffc3.br.js:68:14673)
    at n.a.setup (https://d11a6trkgmumsb.cloudfront.net/assets/ember_jquery-0ae86c6a7527a99c2b9b8a11521273bd9cb4f7d41bc546df081b7ee94f26d9c3.br.js:8:6889)
    at i (https://d11a6trkgmumsb.cloudfront.net/assets/ember_jquery-0ae86c6a7527a99c2b9b8a11521273bd9cb4f7d41bc546df081b7ee94f26d9c3.br.js:17:23930)
    at u.n.routeEnteredOrUpdated (https://d11a6trkgmumsb.cloudfront.net/assets/ember_jquery-0ae86c6a7527a99c2b9b8a11521273bd9cb4f7d41bc546df081b7ee94f26d9c3.br.js:17:24069)
    at u.n.setupContexts (https://d11a6trkgmumsb.cloudfront.net/assets/ember_jquery-0ae86c6a7527a99c2b9b8a11521273bd9cb4f7d41bc546df081b7ee94f26d9c3.br.js:17:23260)
    at u.n.finalizeTransition (https://d11a6trkgmumsb.cloudfront.net/assets/ember_jquery-0ae86c6a7527a99c2b9b8a11521273bd9cb4f7d41bc546df081b7ee94f26d9c3.br.js:17:22253)
    at https://d11a6trkgmumsb.cloudfront.net/assets/ember_jquery-0ae86c6a7527a99c2b9b8a11521273bd9cb4f7d41bc546df081b7ee94f26d9c3.br.js:17:21378
    at f (https://d11a6trkgmumsb.cloudfront.net/assets/ember_jquery-0ae86c6a7527a99c2b9b8a11521273bd9cb4f7d41bc546df081b7ee94f26d9c3.br.js:17:29538)
    at T (https://d11a6trkgmumsb.cloudfront.net/assets/ember_jquery-0ae86c6a7527a99c2b9b8a11521273bd9cb4f7d41bc546df081b7ee94f26d9c3.br.js:17:30915)
    at E (https://d11a6trkgmumsb.cloudfront.net/assets/ember_jquery-0ae86c6a7527a99c2b9b8a11521273bd9cb4f7d41bc546df081b7ee94f26d9c3.br.js:17:30814)

Uncaught TypeError: Cannot read property 'cancelFilter' of undefined
    at n.deactivate (application-779d3dc401b01d1322f0bf8b26cb0e5f4c83a62f26cbecbd52159a94370dffc3.br.js:68)
    at n [as deactivate] (ember_jquery-0ae86c6a7527a99c2b9b8a11521273bd9cb4f7d41bc546df081b7ee94f26d9c3.br.js:10)
    at n.a.exit (ember_jquery-0ae86c6a7527a99c2b9b8a11521273bd9cb4f7d41bc546df081b7ee94f26d9c3.br.js:8)
    at u.n.setupContexts (ember_jquery-0ae86c6a7527a99c2b9b8a11521273bd9cb4f7d41bc546df081b7ee94f26d9c3.br.js:17)
    at u.n.getTransitionByIntent (ember_jquery-0ae86c6a7527a99c2b9b8a11521273bd9cb4f7d41bc546df081b7ee94f26d9c3.br.js:17)
    at u.n.transitionByIntent (ember_jquery-0ae86c6a7527a99c2b9b8a11521273bd9cb4f7d41bc546df081b7ee94f26d9c3.br.js:17)
    at u.n.doTransition (ember_jquery-0ae86c6a7527a99c2b9b8a11521273bd9cb4f7d41bc546df081b7ee94f26d9c3.br.js:17)
    at u.n.intermediateTransitionTo (ember_jquery-0ae86c6a7527a99c2b9b8a11521273bd9cb4f7d41bc546df081b7ee94f26d9c3.br.js:17)
    at n.s.intermediateTransitionTo (ember_jquery-0ae86c6a7527a99c2b9b8a11521273bd9cb4f7d41bc546df081b7ee94f26d9c3.br.js:8)
    at n.a.intermediateTransitionTo (ember_jquery-0ae86c6a7527a99c2b9b8a11521273bd9cb4f7d41bc546df081b7ee94f26d9c3.br.js:8)

Yep, it’s being treated like a permalink redirect and they’re not supported for internal links.

Unfortunately we had no way of knowing that this wasn’t officially supported behavior. As far as we were concerned, it worked. So we used it. I’ll try to let people know not to use that approach from now on, but unfortunately that doesn’t help us now when we have hundreds of these floating around.

As @Dannii said, it only breaks when it’s clicked to load in the same tab, and pretty badly. Even if it’s only really supported for when people do this by accident, doesn’t that still mean it should be fixed? Especially since it works when the topic is different.

Vous pouvez rechercher dans vos publications des URL correspondant à une expression rationnelle. D’après ce que je sache, il vous suffit de saisir n’importe quoi dans le champ titre ; ce n’est pas nécessairement le titre, mais il faut bien y entrer quelque chose.

Vous pouvez tout spécifier pour le titre, oui. Ce n’est pas aussi simple que de trouver mes publications, cependant. Il est devenu courant, dans une partie de notre communauté, de supprimer entièrement le titre pour éviter les URL verbeuses. Ainsi, plusieurs utilisateurs devraient corriger tous leurs liens.

Pourquoi cela a-t-il été déplacé vers le support ? Le fait que la page tourne indéfiniment est clairement un bug, même si la correction ne permet pas aux URL sans titre de fonctionner à nouveau. Et le fait que cela fonctionne parfois (liens vers différentes publications ; accès direct via l’URL dans la barre d’adresse) mais pas dans ce cas, n’a pas vraiment de sens, à mon avis.

Parce qu’il s’agit d’un problème à corriger en raison d’une utilisation non prévue, cela n’a jamais été quelque chose de pris en charge. Un bogue est une fonctionnalité qui a cessé de fonctionner, ce qui n’est pas le cas ici.

J’ai également mis à jour le titre pour refléter ce qui s’est réellement produit ici : les liens ne sont pas créés sans titre. Ce problème est survenu parce que les liens ont été saisis manuellement ou que leurs titres ont été supprimés. Discourse n’est en aucun cas la source du problème, il ne peut donc pas s’agir d’un bogue de Discourse.

Vous pouvez identifier tous les liens brisés en une seule fois en examinant votre base de données. Vos utilisateurs n’ont pas besoin de revenir les corriger manuellement, mais vous devez absolument les rééduquer pour les empêcher de recommencer à l’avenir.

Je ne suis pas administrateur, donc je ne peux malheureusement pas faire cela.

Donc, il est acceptable que la page tourne indéfiniment ? Même une redirection vers une page 404 aurait plus de sens que cela.

Cela ne résoudra pas votre problème, non ?

À long terme, ils doivent corriger leurs liens, car ce qu’ils faisaient était essentiellement un hack non pris en charge.

Comme je l’ai dit, l’ID du sujet seul est effectivement une forme officiellement prise en charge (pour couvrir le cas « oups, j’ai oublié le titre »), mais l’ID du sujet plus l’ID du poste ne l’est pas.

Qu’en pensez-vous @eviltrout concernant le comportement à adopter (voir le troisième lien dans le premier message) ?

Ah, c’est intéressant. Quelle est la logique derrière cette différence de traitement ? N’est-il pas vrai que les gens oublient toujours le titre, mais qu’ils tiennent à un message spécifique ?

C’est un hack plutôt vicieux, car nous traitons le texte comme un nombre. En substance, c’est une porte de sortie du type « wow, l’utilisateur est vraiment confus, nous ferons de notre mieux ». Ce n’est pas censé être une méthode de navigation principale sur laquelle les gens devraient s’appuyer, surtout une fois que les IDs de publication sont également impliqués.

La détection se fait-elle uniquement au clic sur le lien ? Pourrions-nous la déclencher lors de la génération du message et appliquer une classe à tous les liens malformés ou étranges ?

Si c’est un problème si important pour votre communauté, pourquoi les administrateurs ne sont-ils pas ici pour en discuter ? Ce sont eux qui devront finalement appliquer les correctifs.

Il est intéressant de noter que le côté serveur gère ce cas. Il existe une route spécifique pour /t/:topic_id/:post_number.

La correspondance ne se produit que lorsque topic_id et post_number sont numériques. Dans ce cas, il recherchera le bon slug de sujet et redirigera vers celui-ci.

Puisque cela est pris en charge côté serveur, je pense que nous devrions également le prendre en charge côté client. Il n’est pas logique d’afficher une page d’erreur alors que nous pouvons effectuer une recherche AJAX du bon slug et l’afficher. Cela dit, je déconseillerais aux gens d’utiliser ces liens, car cette recherche supplémentaire représente une requête web supplémentaire pour une raison en grande partie inutile.

Je suis tombé dessus par hasard, alors j’en ai parlé. C’est une communauté très discrète, alors je n’implique les administrateurs que lorsque c’est vraiment important. Je suis très actif dans la communauté, en particulier dans le sous-groupe qui serait le plus touché par ce changement.

Hack, involontaire ou autre, je pense que ce bogue doit être corrigé. Maintenant que cela est révélé, les trolls pourraient intentionnellement créer ces liens. N’oubliez pas que cela ne se contente pas de ne pas charger le sujet, cela fait planter tout le site.

Voici, découvrez mon nouveau jeu !

Pas vraiment, puisque vous pouvez appuyer sur le bouton retour.

Voulez-vous attribuer cette tâche à quelqu’un @eviltrout ?

Ça ne fonctionne pas pour moi…

Après avoir cliqué sur un mauvais lien, tout cela cesse de fonctionner :

  • cliquer sur le bouton retour du navigateur
  • cliquer sur le logo
  • cliquer sur le titre du sujet
  • effectuer une recherche
  • cliquer sur Derniers/Non lus/Étiquettes, etc. dans le menu hamburger

La seule chose que j’ai trouvée qui fonctionne, c’est de cliquer sur une notification. Ou d’actualiser la page.