Page MenuHomePhabricator

Provide a link to the permalink for this page in the user interface (to page, not revision)
Closed, InvalidPublic

Description

There's already the ID, but not an actual link.
This could be an easy way to address bug 21572 at least in part.


Version: unspecified
Severity: enhancement

Details

Reference
bz42238

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 1:14 AM
bzimport set Reference to bz42238.
bzimport added a subscriber: Unknown Object (MLST).

This request would benefit from a bit clearer summary and description.

PS: found during https://www.mediawiki.org/wiki/Bug_management/Triage/20130307

The current revision is linked in the "Edit history" section in the "Date of latest edit" field. The curid itself doesn't look like a valuable piece of information otherwise.

(In reply to comment #2)

The current revision is linked in the "Edit history" section in the "Date of
latest edit" field.

Do you mean oldid?

The curid itself doesn't look like a valuable piece of
information otherwise.

Why? Have you read the dependency? Reopening pending explanation.

(In reply to comment #3)

(In reply to comment #2)

The current revision is linked in the "Edit history" section in the "Date of
latest edit" field.

Do you mean oldid?

This is actually the same thing as curid, isn't it?

The curid itself doesn't look like a valuable piece of
information otherwise.

Why? Have you read the dependency? Reopening pending explanation.

What dependency? They're both marked as fixed.

(In reply to comment #4)

This is actually the same thing as curid, isn't it?

Definitely not; curid is page_id, oldid is rev_id.

What dependency? They're both marked as fixed.

Bug 21572: action=info already provides the page ID, but not in the form of a curid link, which could be used as short permalink to the page (as opposed to permalink to a specific revision of it). We're definitely not exposing this sort of permalinking feature in the UI, so it can't be a WORKSFORME; of course it may be a bad idea, in which case it would be a WONTFIX. :)

Blarghfrpft. Okay. I was confused by the "permalink to last revision" part in bug summary. I'm rephrasing it (again), not sure if it's any better though. You should probably implement it yourself to avoid further misunderstandings :P

For what it's worth, I still don't know what's being asked here. I'm not sure this should be tagged with the "easy" keyword.

(In reply to comment #7)

For what it's worth, I still don't know what's being asked here. I'm not sure
this should be tagged with the "easy" keyword.

From the bug summary, I think they want to add the "permalink" of the page to action=info (example page: https://www.mediawiki.org/w/index.php?title=Project:Sandbox&action=info )

Maybe add a new row to the pageinfo-header-basic with the current ID and make that ID a link?

Anyway, I'd put the +easy keyword only when the design decision of where and how display that link has been made. Making the decision during the code-review process would be frustrating for a new developer.

Krinkle renamed this task from Expose in UI the page id link (permalink to this page) of a page by adding it to the respective action=info to Provide a link to the permalink for this page in the user interface (to page, not revision).Jan 26 2019, 7:06 AM
Krinkle removed a subscriber: wikibugs-l-list.
Jdlrobson added a subscriber: Jdlrobson.

7 years later still unclear on the goal and there are permalinks in the sidebar:

This was about providing a pemalink to "the page, not the revision". In other words, a link that uses curid= instead of title=… or /wiki/….

I agree with declining that, however. That direction seems problematic for two reasons.

  1. People think they want this because they want a shorter or prettier URL. Especially for non-latin language wikis where the standard URL is very long and ugly due to percent-encoding. But, advertising a URL with a fundamentally different concept behind it (title vs page id) seems like a bad idea. We have https://w.wiki now which should suffice for this need. There are numerous gadgets for interacting with the url shorterner, which can be invested in further as-needed.
  2. Aside from title and page ID being different, of these two title is considered stable, and page ID considered unstable. Titles form the basis of our canonical and long-term supported URLs and are expected to keep working and keep tracking the same subject matter even after splits, merges, deletes, undeletes, and recreations. Page IDs are something different, largely internal, and not meant to be stable or used by end-users outside of short-term interactions with the API and such.
  1. Aside from title and page ID being different, of these two title is considered stable, and page ID considered unstable. Titles form the basis of our canonical and long-term supported URLs and are expected to keep working and keep tracking the same subject matter even after splits, merges, deletes, undeletes, and recreations. Page IDs are something different, largely internal, and not meant to be stable or used by end-users outside of short-term interactions with the API and such.

I'm pretty sure page renames are way more common for potentially long-lived pages than splits, merges, deletes, undeletes, and recreations. While renames usually leave a redirect behind, sometimes the redirect is omitted, or even repurposed to a different page content, disambiguation...

We also have Special:Redirect/page/<page id> already