Page MenuHomePhabricator

Permalink redirecting: Support plain section links
Open, Needs TriagePublic

Description

Using the DT permalinks metadata database, we should be able to look up the plain section link in the full history of the page (which is contained within DT IDs).

Once we have a DT ID, we can do our normal search to find where the topic currently resides on the wiki. No need to configure what an archive page path looks like on a per-wiki basis.

Story

  • As someone who is wanting to view a topic that A) no longer exists on the page from which the link was generated and B) does NOT use the URL schema DiscussionTools introduced (T302012), I want to know that the software cannot locate the topic I am seeking, why it cannot locate said comment, and where I might look to find said comment, so that I can increase the chances that I can find the topic I'm seeking myself.

Requirements

TODO

Open questions

  • 1. What – if anything – should people experience who have one of the two gadgets below enabled? E.g. will the code this ticket implements "listen for" the presence of these gadgets and disable itself when it detects them, as we did for the Reply Tool in T298909?

Gadgets

There are two gadgets that implement this behaviour already, with nearly identical mechanisms (possibly one copied the other?):

  • find-archived-section on en.wiki
  • ConvenientDiscussions on ru.wiki and others

Both gadgets use the search API with srprop=sectiontitle and a pre-defined per-wiki prefix, e.g. "Page name/Archive...". CD switched to using mw.notify notifications instead of a banner to display the results.

When multiple results are found, the most recent one is displayed. In all cases (0/1/many results) a search link is provided, although this requires knowing about the archive prefix, so we would omit this from our implementation.

CDfind-archived-section
image.png (109×290 px, 8 KB)
image.png (214×1 px, 39 KB)

Background

T304579 will make it possible for people to locate a comment that has since been moved from the page on which the link to said comment was generated.

This task involves the work of extending the same capability to links that include a discussion topic's title, represented in the form of a hash [i] as opposed to the URL schema Discussion Tools introduced in T302012.


i. E.g.
https://www.mediawiki.org/wiki/Extension_talk:Graph/Plans#Underlying_purpose_inspiring_the_extension

Event Timeline

Change 967561 had a related patch set uploaded (by Esanders; author: Esanders):

[mediawiki/extensions/DiscussionTools@master] Find a heading by title in archives

https://gerrit.wikimedia.org/r/967561

Oh, that's great news. (Currently a fragment with random characters gives a notification "This comment could not be found. It might have been deleted or moved." – is that expected? Also maybe unsuccessful lookup should be reflected in the notification text as well.)

Will this run independently of other DiscussionTools features? With an analogous update for comments, this solves archivation + section/comment moving (which our tools couldn't track), I think? So the piece of code in our tools (written initially by SD0001) will be redundant.

(Currently a fragment with random characters gives a notification "This comment could not be found. It might have been deleted or moved." – is that expected? Also maybe unsuccessful lookup should be reflected in the notification text as well.)

I think it should either say "heading" or show no message at all. We try to filter out other things that appear in the hash fragment like "/media/File:.." but we can't be exhaustive so there will be false positives. I'm inclined to show nothing as if the fragment was at some point a valid heading it is very likely our tool will find a result, so if there are no results it's probably because the fragment was broken or served some other purpose.

Will this run independently of other DiscussionTools features?

The patch-as-written includes it inside the DT initialization, so it'll run if anything at all is causing DT to be loaded on the page. (Which I think might be always happening on talk pages now regardless of how many of the sub-features are disabled. I checked, and turning off everything in the preferences still leaves the mw.dt object existing from the dt.init JS.)

Which I think might be always happening on talk pages now regardless of how many of the sub-features are disabled. I checked, and turning off everything in the preferences still leaves the mw.dt object existing from the dt.init JS.

OK, thanks.

Change 967561 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Find a heading by title in archives

https://gerrit.wikimedia.org/r/967561