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.
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
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)
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.
Puedes buscar en tus publicaciones las URLs que coincidan con una expresión regular. Por lo que sé, solo necesitas especificar cualquier cosa en el campo de título; no tiene que ser el título real, pero sí debes ingresar algo.
Puedes especificar cualquier cosa para el título, sí. Sin embargo, no es tan sencillo como encontrar mis publicaciones. Se ha convertido en una práctica común en una parte de nuestra comunidad eliminar el título por completo para evitar las URL largas. Por lo tanto, varios usuarios tendrían que corregir todos sus enlaces.
¿Por qué se movió esto a soporte? Que la página gire indefinidamente es claramente un error, incluso si la solución no hace que las URLs sin título vuelvan a funcionar. Y que funcione a veces (enlaces a diferentes publicaciones; acceso directo a la URL en la barra de direcciones) pero no en este caso, en mi opinión, no tiene mucho sentido.
Dado que se trata de algo que debes corregir debido a un uso no previsto, nunca fue algo que pudiera ser soportado. Un error es una característica funcional que dejó de funcionar, lo cual no es el caso aquí.
También he actualizado el título para reflejar lo que realmente ocurrió aquí; los enlaces no se crean sin un título. Esto se ha producido porque los enlaces fueron ingresados manualmente o se les eliminaron los títulos. Discourse no es la fuente del problema en ningún sentido, por lo que no puede considerarse un error de Discourse.
Puedes identificar todos los enlaces rotos de un solo vistazo revisando tu base de datos. Tus usuarios no necesitan volver y corregirlos manualmente, pero definitivamente debes volver a educarlos para evitar que vuelvan a hacerlo en el futuro.
A largo plazo, necesitan corregir sus enlaces, ya que lo que estaban haciendo era básicamente un truco no soportado.
Como dije, el ID del tema por sí solo es, de hecho, una forma oficialmente soportada (para cubrir el caso de “ay, olvidé el título”), pero el ID del tema más el ID de la publicación no lo es.
¿Qué opinas @eviltrout sobre cómo debería comportarse esto (ver el tercer enlace en la primera publicación)?
Ah, eso es interesante. ¿Cuál es la razón para tratarlos de manera diferente? ¿No es cierto que la gente aún olvida el título pero le importa una publicación específica?
Es un truco bastante malo, porque estamos tratando el texto como numérico. Esencialmente, es una válvula de escape que dice: «vaya, el usuario está realmente confundido, supongo que haremos lo mejor que podamos». No está pensado para ser un método de navegación principal del que la gente deba depender, especialmente una vez que también se incluyen los identificadores de las publicaciones.
¿La detección ocurre solo al hacer clic en el enlace? ¿Podríamos detectarla cuando se genera la publicación y aplicar una clase a cualquier enlace malformado o extraño?
Si esto es tan importante para tu comunidad, ¿por qué los administradores no están discutiéndolo aquí? Ellos son quienes finalmente tendrán que aplicar cualquier corrección.
Es interesante que el lado del servidor lo gestione. Existe una ruta específica para /t/:topic_id/:post_number.
La coincidencia solo ocurre cuando topic_id y post_number son numéricos. En ese caso, buscará el slug correcto del tema y redirigirá allí.
Dado que esto es compatible en el lado del servidor, creo que deberíamos implementarlo también en el lado del cliente. No tiene sentido mostrar una página de error cuando podemos realizar una consulta AJAX para obtener el slug correcto y mostrarlo. Dicho esto, desaconsejaría que la gente utilice esos enlaces, ya que esa consulta adicional implica una petición web extra por una razón mayormente innecesaria.
Lo noté por casualidad, así que lo mencioné. Es una comunidad muy poco intervencionista, por lo que intento involucrar a los administradores solo cuando es realmente importante. Soy muy activo en la comunidad, especialmente en el subgrupo que se vería más afectado por este cambio.
Hacky, no intencional o lo que sea, creo que este error debe corregirse. Ahora que esto ha sido revelado, los trolls podrían crear intencionalmente estos enlaces. Recuerda que no solo no carga el tema, sino que rompe todo el sitio.