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.
Sie können in Ihren Beiträgen nach URLs suchen, die einem regulären Ausdruck entsprechen. Soweit ich weiß, müssen Sie im Titel-Feld lediglich etwas angeben. Es muss nicht der tatsächliche Titel sein, aber es muss etwas eingegeben werden.
Du kannst für den Titel alles angeben, ja. Es ist jedoch nicht so einfach, meine Beiträge zu finden. In einem Teil unserer Community hat es sich zur gängigen Praxis entwickelt, den Titel ganz wegzulassen, um ausführliche URLs zu vermeiden. Mehrere Nutzer müssten also alle ihre Links korrigieren.
Warum wurde dies in den Support verschoben? Dass die Seite endlos lädt, ist eindeutig ein Fehler, selbst wenn die Lösung nicht dazu führt, dass titellose URLs wieder funktionieren. Und dass es in manchen Fällen funktioniert (Links zu verschiedenen Beiträgen; direkter URL-Aufruf in der Adressleiste), aber in diesem Fall nicht, ergibt meiner Meinung nach keinen Sinn.
Da es sich um etwas handelt, das aufgrund einer unbeabsichtigten Nutzung behoben werden muss, war es niemals etwas, das wir unterstützen konnten. Ein Fehler (Bug) ist eine Funktionsstörung, die nicht mehr funktioniert – was hier nicht der Fall ist.
Ich habe den Titel außerdem so angepasst, dass er das tatsächliche Geschehen widerspiegelt: Links werden nicht ohne Titel erstellt. Das Problem ist entstanden, weil Links entweder manuell eingegeben wurden oder ihre Titel entfernt wurden. Discourse ist in keiner Hinsicht die Ursache des Problems, sodass es sich nicht um einen Discourse-Fehler handelt.
Sie können alle defekten Links auf einen Blick identifizieren, indem Sie Ihre Datenbank durchsuchen. Ihre Benutzer müssen nicht einzeln zurückgehen und sie manuell reparieren, aber Sie müssen sie unbedingt erneut schulen, um zu verhindern, dass sie dies in Zukunft wieder tun.
Langfristig müssen sie ihre Links reparieren, da das, was sie taten, im Grunde ein nicht unterstützter Hack war.
Wie bereits erwähnt, ist die reine Themen-ID tatsächlich eine offiziell unterstützte Form (um den Fall „Ups, ich habe den Titel vergessen" abzudecken), aber die Kombination aus Themen-ID und Beitrags-ID ist es nicht.
Was denkst du, @eviltrout, wie das Verhalten sein sollte (siehe dritter Link im ersten Beitrag)?
Oh, das ist interessant. Was ist die Begründung dafür, sie unterschiedlich zu behandeln? Ist es nicht so, dass Menschen immer noch den Titel vergessen, aber einen bestimmten Beitrag im Blick haben?
Das ist ein ziemlich übler Hack, da wir Text als Zahl behandeln. Im Wesentlichen ist es eine Notlösung: „Wow, der Nutzer ist wirklich verwirrt, wir geben unser Bestes, um etwas zu retten.
Findet die Erkennung nur beim Klicken auf einen Link statt? Könnten wir sie beim Erstellen des Beitrags durchführen und eine Klasse auf alle seltsam formatierten Links anwenden?
Wenn das für deine Community so wichtig ist, warum diskutieren die Administratoren hier nicht darüber? Sie sind diejenigen, die letztendlich alle Korrekturen vornehmen müssen.
Es ist interessant, dass dies serverseitig behandelt wird. Es gibt eine spezifische Route für /t/:topic_id/:post_number.
Die Übereinstimmung erfolgt nur, wenn topic_id und post_number numerisch sind. In diesem Fall wird die richtige Topic-Slug nachgeschlagen und dorthin weitergeleitet.
Da dies serverseitig unterstützt wird, sollten wir meiner Meinung nach auch clientseitige Unterstützung dafür bieten. Es ergibt keinen Sinn, eine Fehlerseite anzuzeigen, wenn wir per AJAX die richtige Slug nachschlagen und sie anzeigen können. Dennoch würde ich davon abraten, solche Links zu verwenden, da diese zusätzliche Nachschlageaktion eine weitere Webanfrage für einen größtenteils sinnlosen Zweck darstellt.
Ich habe es zufällig bemerkt und daher angesprochen. Die Community ist sehr zurückhaltend, daher versuche ich, die Administratoren nur dann einzubinden, wenn es wirklich wichtig ist. Ich bin sehr aktiv in der Community, insbesondere in der Untergruppe, die von dieser Änderung am stärksten betroffen wäre.
Hackig, unbeabsichtigt oder wie auch immer – ich finde, dieser Fehler muss behoben werden. Jetzt, da dies bekannt ist, könnten Trolle solche Links absichtlich erstellen. Denken Sie daran: Es lädt nicht nur das Thema nicht, es legt die gesamte Seite lahm.