Page MenuHomePhabricator

Flow: Prettify thread permalink URLs/Titles (they are not human readable!)
Open, MediumPublic

Details

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Now that we are using content handler and it is enabled on prod wikis, we should be able to revisit and solve this.

He7d3r renamed this task from Flow: Prettify thread permalink URLs to Flow: Prettify thread permalink URLs (they are not human readable!).May 10 2015, 4:01 PM
He7d3r updated the task description. (Show Details)
He7d3r renamed this task from Flow: Prettify thread permalink URLs (they are not human readable!) to Flow: Prettify thread permalink URLs/Titles (they are not human readable!).Aug 29 2015, 4:03 PM
He7d3r updated the task description. (Show Details)

I had to delete ALL Topic pages from my watchlist by using Special:Watchlist/raw, because there were too many to select manually using Special:EditWatchlist#editwatchlist-ns2600, and the lack of a meaningful title made it impossible for me to choose the specific ones I wanted (Special:EditWatchlist at least displayed the topic titles, although it didn't show the page names).

A possibility would be [[Flow:<some-id>/original-title]] would be the canonical link to a flow discussion, which if the discussion is renamed, would become a permanent redirect to [[Flow:<some-id>/new-title]] it is what http://stackoverflow.com does for questions and I found it handy (modulo the fact here is a lot of more Flow-id than stackoverflow questions)

@Catrope, is this on your radar? The current URLs are pretty horrendous, IMO.

In T59154#1830589, @ori wrote:

@Catrope, is this on your radar?

I'm aware of this issue, but there are no plans to work on this in the short term.

The current URLs are pretty horrendous, IMO.

Yes they are. So are things like T114550: Flow talk page on mediawiki.org takes 4 seconds to load and T78671: Beta Cluster Special:Contributions lags by a long time and notes slow Flow queries ;)

Change 290365 had a related patch set uploaded (by Matthias Mullie):
[WIP] Pretty topic urls

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

We can have a simple implementation where the pretty url contains the topic title and/or the board name (for context).
It'll still include the UUID (because we don't want a lookup table).
The "pretty" part of the url would simply be ignored (similar to StackOverflow, I believe)

We should be able to link to said pretty url from most places, but there may be some places that still link to the current URL (because we don't have the topic title at hand and don't want additional DB lookups just for this)

Here's some suggestions of what those urls could look like:

  • Topic:UUID/Board/Pretty_title (e.g. Topic:T490mfdufwaacxk7/Talk:Sandbox/Subpage/This_is_my_post)
  • Topic:UUID/Pretty_title@Board (e.g. Topic:T490mfdufwaacxk7/This_is_my_post@Talk:Sandbox/Subpage)
  • Topic:UUID/Pretty_title (e.g. Topic:T490mfdufwaacxk7/Talk:Sandbox/This_is_my_post)
  • Topic:Pretty_title/Board/UUID (e.g. Topic:This_is_my_post/Talk:Sandbox/Subpage/T490mfdufwaacxk7)
  • ...

The possibilities are endless! Just keep in mind that:

  • we need to have the UUID in there somewhere, in a predictable place
  • it shouldn't be confusing for cases where we don't have the topic title at hand and can't generate a better link than Topic:T490mfdufwaacxk7
  • keep in mind that board names may have a hierarchy (parent/subpage) already, which could be confusing

So... What do we want them to look like?

Perhaps it's unviable, been awhile since i thought about this, but could it be possible to do this by creating pages in mediawiki for each topic name?

Page created with topic 'hi there':

  • Create Topic:hi_there with flow-board content type, the content would contain the uuid that backs the topic. Could store the current page name as a new field in the flow_workflow table?

Topic changed to 'other':

  • Create Topic:other with flow-board content type, again contain contains the uuid that backs the topic
  • Topic:hi_there changed to wikitext page with content #REDIRECT [[Topic:other]]
  • flow_workflow table updated with other as current topic page

Topic changed to 'yet again':

  • Create Topic:yet_again with flow-board content type, again contain contains the uuid that backs the topic
  • Topic:other changed to wikitext page with content #REDIRECT [[Topic:yet again]]
  • flow_workflow table updated with yet again as current topic page
  • Job enqueued to pull redirects from the redirect table pointing to Topic:other and perform an edit to point them at Topic:yet_again

This does create the difficulty of needing some sort of way to handle multiple topics of the same name. Easiest solution might just be a random string attachment, so Topic:yet_again/a8fq, and trying a couple times (perhaps expanding the # of generated characters each time) in the case of collision.
Might need to put page protection on the wikitext pages to keep them from being edited and broken. Alternatively instead of using wikitext redirects could recognize when loading a workflow that the requested page doesn't match the canonical page, and issue a redirect then.

Please do not make the same LQT did with user names (T23612), hardcoding them into titles which cannot be changed if a user is renamed (e.g. Topic:T490mfdufwaacxk7/User_talk:OLD_USERNAME_FOREVER/Something ok).

@EBernhardson: It's probably viable (and a lot easier now than it used to be), but it'll cost more time & risk (backfill pages, deal with collisions, ...).
This task is 2.5y old already and not a huge priority, so I think a simple improvement is more likely to actually get done :)

@He7d3r: The "pretty" parts of the url would simply be ignored & could be anything, only the UUID would be used internally.
So if a page name or topic title changes, new links would include the new data, but links with the old data would still work (and probably redirect to the current accurate url)

As long as those page do not get indexed by search engines with titles which can't be changed...

IIRC, talk pages aren't indexed (wrong: T122119). But as long as we include a rel="canonical" and/or redirect to the new url once it changes, indexed pages would get updated as they're crawled again.

What is the rational behind using UUID ? some kind of counter could not work ?

Flow was designed to support multiple wikis and be sharded across multiple databases. With default auto-increment IDs, we'd have risked ID collisions, whereas UUIDs are guaranteed to be unique.

Please check https://www.mediawiki.org/wiki/Topic:Tjpkjvsopstw586w
In non latin script wikis this would create even more horrible urls without solving any problem.

For the url https://el.wikipedia.org/wiki/Topic:Tizm73nml0pv0ff0 a Topic:UUID/Pagename/Topic solution would result to https://el.wikipedia.org/wiki/Topic:Ti11vwprij2he4mg/%CE%A3%CF%85%CE%B6%CE%AE%CF%84%CE%B7%CF%83%CE%B7_%CF%87%CF%81%CE%AE%CF%83%CF%84%CE%B7:Geraki/%CE%A0%CF%81%CF%8C%CF%84%CF%85%CF%80%CE%BF:%CE%9A%CE%BF%CF%85%CF%84%CE%AF_%CF%80%CE%BB%CE%B7%CF%81%CE%BF%CF%86%CE%BF%CF%81%CE%B9%CF%8E%CE%BD_%CF%80%CE%BF%CE%B4%CE%BF%CF%83%CF%86%CE%B1%CE%B9%CF%81%CE%B9%CE%BA%CE%BF%CF%8D_%CF%83%CF%85%CE%BB%CE%BB%CF%8C%CE%B3%CE%BF%CF%85

If the plan is to change the current url "to have something more descriptive that will give more context to users", the question should be "where/when it will give this more context?":

  • When the user is already on the topic page, the topic title and page title are displayed on the top of the page itself
  • When the url is copy&pasted in another page it is not human readable in any way.

Keep the url as it is.

For practical reasons, please do not comment twice, both on the proposal page and here.

@geraki, I've replied to your feedback concerning URLs encoding here.

All modern browsers percent-decode URLs before display; you never see the %s unless you use IE8 or something (in which case this is not going to be your biggest problem).

In T59154#2965748, @Tgr wrote:

All modern browsers percent-decode URLs before display; you never see the %s unless you use IE8 or something (in which case this is not going to be your biggest problem).

I use Chromium, last version, and I have a nice collection of % in my address bar! :)

In T59154#2965748, @Tgr wrote:

All modern browsers percent-decode URLs before display; you never see the %s unless you use IE8 or something (in which case this is not going to be your biggest problem).

Indeed, but when you copy the nice url from the address bar it is copied (and then pasted) decoded.
The example above is displayed nice in the address bar but in this way when you paste it anywhere else.

I have a request to have anchors readable as well.

Change 290365 abandoned by Matthias Mullie:
[WIP] Pretty topic urls

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