Page MenuHomePhabricator

Hide last modifier bar on revision pages
Closed, ResolvedPublic3 Estimated Story Points

Description

Visit https://en.m.wikipedia.org/wiki/Leonard_Cohen?oldid=747517267
The box in the top says that the last modifier is Linealchamp.

Screen Shot 2017-06-06 at 3.34.40 PM.png (379×933 px, 94 KB)

The last modified bar at the end disagrees.

Screen Shot 2017-06-06 at 3.35.04 PM.png (248×946 px, 27 KB)

It shows the current editor too.

We should hide the bar in the footer which gives information that is not relevant (not appropriate) here.

Acceptance criteria

  • If a page is an old revision and I view it there is no last modified bar
  • If a page is a current revision and I view it there is a last modified bar.
  • MinervaNeue should not use MobilePage class - use methods in core.

Developer notes

Testing notes

  • Go to any article on BetaCluster that has more than one edit, example: https://en.m.wikipedia.beta.wmflabs.org/wiki/Planet
  • The footer should contain "Last edited {TIME} ago by {AUTHOR}
  • click "Last edited" link to see the article history page
  • on history page click the previous edit (not the latest one)
  • you should land on page saying "This is an old revision of this page ....."
  • when you scroll down to the footer "Last edited {TIME} ago by {AUTHOR}" should not be visible because you're viewing the historical page

Event Timeline

@Nirzar, what do you think? Should the last modified bar in the footer display information about the page or the current revision that's being viewed?

I'm also concerned that this might be a legal problem...

@bmansurov good catch. we should hide the bar in the footer which gives information that is not relevant (not appropriate) here.

@jhobs, since you're in charge of the chore wheel today, please update the description of the task per T153125#2877112 and move to the appropriate column. Thanks.

@Nirzar we have a legal obligation to link to the history... but even if we hide it, this also doesn't help guide us with what to do in the mobileview api - we still need to decide whether the behaviour there is correct.

@bmansurov please check with WMF legal before moving this to triaged but future.

jhobs triaged this task as Medium priority.Dec 15 2016, 5:31 PM
jhobs updated the task description. (Show Details)

@Jdlrobson we can include that in the top banner. it already next rev, prev rev, and it can have overall history link. let me put up a mock.

Doesn't seem to me that we clearly defined the fix and updated the description here.

Here is the functionality of this banner

  • see latest version as this is old version, compare diff with latest version
  • see who was editor of this revision, go to their talk or see their contribs
  • see next/prev versions
  • compare diffs with next and previous
  • know more about revisions
  • know more about perm links

LOL so many things.

workflow

  • User visits oldid page
  • notify user that this is NOT the latest copy of this article, give option to see the latest copy then
  • tell user, who edited this copy and when
  • let user see entire history
  • let user browse next and previous revisions
  • let user compare diffs with next/prev revisions. kind of a browser

revision-browser.png (1×750 px, 141 KB)

This takes care of all functionality except for visiting user talk or contribs. but you can do that by tapping on a user


if we don't want change anything. here's a complicated version as is

revision-browser-lite.png (1×750 px, 172 KB)

which has link to edit history.

The box is provided by core, so I'll need to dig in and see if we can move it. Not sure if that's worth the considerable work involved as we'd have to consult with community?

Seems like we can at least remove the last modified bar from the end of the article and leave a history link? Would that suffice or should we be more ambitious here?

Seems like we can at least remove the last modified bar from the end of the article and leave a history link? Would that suffice or should we be more ambitious here?

It's difficult to say Yes to Grade C as the way to go.

There is a Grade A answer here which i did not even explore due to the effort. I did Grade B and C. C being the last one, just adding another option to already complicated thing.

cc @ovasileva can take a call based on priority and value

@ovasileva this patch is now untouched for over a month. Is priority normal or low? TBH I think we're overthinking this - removing the last modified bar at the bottom of the page to avoid confusion is all that needs to happen here.

@Jdlrobson - to confirm, we would be removing it for old revisions?

Jdlrobson renamed this task from Mobile page always shows the last modifier to Hide last modifier bar on revision pages.Jul 13 2017, 5:52 PM
Jdlrobson edited projects, added MinervaNeue; removed MobileFrontend.
Jdlrobson updated the task description. (Show Details)
Jdlrobson set the point value for this task to 3.

Take the time to review the codebase and refactor so we consistently check if the page is a revision

This is how MobileFrontend decides whether to redirect to Special:MobileDiff: https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/dee07d4a2fc7e30395dc27014b214af4b2ca7ad5/includes/MobileFrontend.hooks.php#L258-L272

Change 376282 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/skins/MinervaNeue@master] Hide last modified bar on old revisions

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

Per acceptance criteria here is some refactoring for review:
https://gerrit.wikimedia.org/r/#/c/376281/

Change 376282 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Hide last modified bar on old revisions

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

issues have been addressed! @pmiazga is on it!

reviewed, looks nice. it's ready for QA

@ovasileva and @pmiazga I was taking a look at this and I'm not sure I understand the problem. In the screenshots, it appears to show the edit by Linealchamp, which is not the 'latest' edit. The footer shows the latest edit to the main article, which is now Jon Kolbert. It seems like this is the desired behavior. Am I missing something?

Ah, ok! Looks good to me. I tried it on a handful of browsers.

looks like we're all done here!