从 URL 中移除标题会破坏链接

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.

您可以搜索帖子中包含符合正则表达式的 URL。据我所知,您只需在标题字段中填写任意内容即可,该内容不必是实际标题,但必须填写某些内容。

标题可以随意指定,没错。不过,这并不像查找我的帖子那么简单。在我们社区的一部分用户中,已经形成了一种惯例,即完全移除标题以避免冗长的 URL。因此,会有多位用户需要修复他们所有的链接。

为什么这个问题被移到了支持板块?页面无限旋转显然是一个漏洞,即使修复后标题为空的 URL 无法再次正常工作。而且,在某些情况下(例如链接到其他帖子、在地址栏直接输入 URL)可以正常工作,但在此情况下却无法工作,在我看来这并不合理。

因为这是因误用而需要修复的问题,它从来就不是一个受支持的功能。所谓的“bug

我不是管理员,所以很遗憾我无法这样做。

那么页面无限旋转也是可以接受的吗?即使重定向到 404 页面也比这样更合理。

但这并不能解决你的问题,对吧?

从长远来看,他们需要修复这些链接,因为他们所做的本质上是一种不受支持的变通方法。

正如我所说,仅使用主题 ID 确实是一种官方支持的形式(用于处理“哎呀,我忘了标题”的情况),但主题 ID 加帖子 ID 的组合则不受支持。

@eviltrout,你认为应该采取什么样的行为(请参见第一个帖子中的第三个链接)?

哦,这很有趣。为什么对它们区别对待?难道不是有些人虽然会忘记标题,但却很在意某个特定帖子吗?

这是一个相当糟糕的变通方案,因为我们把文本当作数字来处理。本质上,这是一个“哇,用户真的搞混了,我们只能尽力而为”的应急出口。它并不是设计用来作为人们应该依赖的主要导航方式,尤其是当帖子 ID 也参与其中时。

检测是否仅在点击链接时发生?我们能否在帖子生成时进行检测,并为任何格式异常或奇怪的链接添加一个类?

如果这对你的社区如此重要,为什么管理员们没有在这里讨论这个问题?他们才是最终需要实施任何修复措施的人。

有趣的是,服务器端的情况确实处理了这个问题。存在一个专门针对 /t/:topic_id/:post_number 的路由。

只有当 topic_idpost_number 为数字时,匹配才会发生。在这种情况下,它会查找正确的主题 slug 并在那里重定向。

既然服务器端已支持,我认为客户端也应该支持。当我们可以进行 AJAX 查找以获取正确的 slug 并显示它时,显示错误页面是没有意义的。话虽如此,我还是不建议人们使用这些链接,因为额外的查找意味着多一次网络请求,而这样做的原因大多毫无意义。

我碰巧注意到了这个问题,所以提了出来。这是一个非常“放手”的社区,因此我尽量只在真正重要的事情上让管理员介入。我在社区中非常活跃,尤其是在最可能受此变更影响的子群体中。

不管这漏洞是 hacky 的、无意的还是其他原因,我认为它必须被修复。既然这个问题已经暴露, trolls 可能会故意创建这类链接。请记住,这不仅仅导致话题无法加载,它会导致整个网站崩溃这里,看看我的新游戏!

不完全是,因为你可以按返回按钮。

你想把这个任务分配给某人吗?@eviltrout

这对我没用……

点击坏链接后,以下操作全部失效:

  • 点击浏览器的返回按钮
  • 点击 Logo
  • 点击主题标题
  • 搜索
  • 点击汉堡菜单中的“最新/未读/标签”等

我发现唯一有效的方法是点击通知,或者刷新页面。