Page MenuHomePhabricator

On mobile web, discussion link at bottom of subject page links to page which incorrectly says "There are no conversations about this page"
Closed, ResolvedPublic

Description

In Beta mode, when you go to a subject page (e.g. https://m.mediawiki.org/wiki/User:Jorm_%28WMF%29) that has an associated talk page, there is a discussion button at the bottom. It links to e.g. https://m.mediawiki.org/wiki/User:Jorm_(WMF)#/talk

For Flow (which the example above is), that link does not work. You see "There are no conversations about this page.", presumably because there are no section headings in the raw text that Flow stores (which is just a small JSON blob).

It links to "Read as wiki page", which ironically works (although Flow is not a standard wiki talk page).

For subject pages associated with Flow boards (flow-board content model), either (ideally both):

  1. The Discussion button should link directly to https://m.mediawiki.org/wiki/User_talk:Jorm_(WMF), or
  2. https://m.mediawiki.org/wiki/User:Jorm_(WMF)#/talk should redirect to https://m.mediawiki.org/wiki/User_talk:Jorm_(WMF).

Event Timeline

Mattflaschen-WMF renamed this task from On mobile web, discussion link at bottom of subject page does not link directly to Flow to On mobile web, discussion link at bottom of subject page links to page which incorrectly says "There are no conversations about this page".
Mattflaschen-WMF raised the priority of this task from to Needs Triage.
Mattflaschen-WMF updated the task description. (Show Details)
Mattflaschen-WMF set Security to None.
EBernhardson triaged this task as Low priority.Mar 24 2015, 5:47 PM
EBernhardson added a subscriber: EBernhardson.

Ideally we'd only add this module if the talk page is wikitext. Is there a way in core to say $title->getTalkPage()->getContentType() ?
If so this would be an easy fix in MobileFrontend (we just would not run the JS)

Florian claimed this task.EditedMar 30 2015, 5:14 PM
Florian added a subscriber: Florian.

If i understand Mattflaschen right, the content model of flow is "flow-board", right? If so, we could just use:

if ( $title->getTalkPage()->getContentModel() !== "flow-board" ) {
  // load module
}

I would do it, after we have the confirmation what the content model is :)

EDIT: Found it: CONTENT_MODEL_FLOW_BOARD (https://github.com/wikimedia/mediawiki-extensions-Flow/blob/fd9b37b59c190192e06ea81cc2fe8370283131a6/Flow.php#L73)

We wouldn't check for flow-board - we'd check for wikitext or some other text type.
It's a shame content model is flow-board - it would be great to reuse HTTP content models
e.g. application/flow-board
then we could simply only load this for text based models.

MobileFrontend should have no knowledge of Flow :)
e.g.
if ( $title->getTalkPage()->getContentModel() begins with "text/" ) {

// load module

}

http://www.w3.org/Protocols/rfc1341/4_Content-Type.html
Note: Private values (starting with "X-") may be defined bilaterally between two cooperating agents without outside registration or standardization.

http://www.w3.org/Protocols/rfc1341/4_Content-Type.html
Note: Private values (starting with "X-") may be defined bilaterally between two cooperating agents without outside registration or standardization.

This is not an HTTP Content-Type. The HTTP content type is purely what is served over the HTTP connection, and we serve HTML5 across HTTP.

If you want to propose a *similar* scheme, that's another matter, but it shouldn't be called an HTTP content type.

However, I'm not sure it's as simple as you're proposing. For example, one of the JSON content types is text/json. Wikidata uses a JSON content type; however, I believe they also have special handling for history. You could say, "It should be application/json". But both text/json and text/xml are still pretty common.

Someone could easily make an XML content type. text/xml is recommended when the XML is "readable by casual users" (which would be nice, if possible).

The key feature that matters is not whether it's text (the definition of which is debatable) but whether it should use the default history handling, or custom history rendering.

We wouldn't check for flow-board - we'd check for wikitext or some other text type.
It's a shame content model is flow-board - it would be great to reuse HTTP content models
e.g. application/flow-board
then we could simply only load this for text based models.
MobileFrontend should have no knowledge of Flow :)
e.g.
if ( $title->getTalkPage()->getContentModel() begins with "text/" ) {

// load module

}

good point: Then the other way around: in fact, we can't parse any text except wikitext in our TalkOverlay, so we shouldn't load it on pages where the talk page has another model as wikitext :)

Change 200616 had a related patch set uploaded (by Florianschmidtwelzow):
Don't load mobile.talk on pages with no wikitext talk page

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

Sorry for confusion @Mattflaschen I was simply saying we should learn from other standards - obviously this is not a content type but I think we would be silly not to copy an established tried and tested pattern for our similar use case.

Change 200616 merged by jenkins-bot:
Don't load mobile.talk on pages with no wikitext talk page

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

Should be possible to test this on http://en.m.wikipedia.beta.wmflabs.org/wiki/Flow_QA?mobileaction=beta when it goes live there

Florian closed this task as Resolved.Mar 30 2015, 7:25 PM

Should be possible to test this on http://en.m.wikipedia.beta.wmflabs.org/wiki/Flow_QA?mobileaction=beta when it goes live there

verified