@Taketa this happens when you try to restore a version with different structured data. (depicts or captions) If no structured data was altered, you get the plain text.

@AlexisJazz Thank you for your response. So if I understand correctly Commons made a switch and all pages with old structured data that are mixed with new structured data do not show properly. However it works fine in both the old structured data and the new structured data. Is that correct? So what I would like to be sure of is that the new structured data also shows ful texts, this has not been removed. All the best.

In T225897#5297407, @Taketa wrote:

@AlexisJazz Thank you for your response. So if I understand correctly Commons made a switch and all pages with old structured data that are mixed with new structured data do not show properly. However it works fine in both the old structured data and the new structured data. Is that correct? So what I would like to be sure of is that the new structured data also shows ful texts, this has not been removed. All the best.

@Taketa changes to wikitext will be shown as well, and the wikitext can be accessed for restoring old revisions.

You can read the announcement for this change in the SDC talk page archives, it should help explain why this change happened and how this change works.

Same with this file https://commons.wikimedia.org/wiki/File:Annamie_Paul_in_Toronto_Regent_Park.jpg

You can in fact restore the old version by clicking the big blue "publish changes" button at the bottom. "Publish changes" is the standard messgae for saving an edit, it's a bit confusing here.

What is indeed not possible is to view the entire old text. This cannot be done the "normal" way if there is structured data attached to the page, since you would oly get the old text, not the old data, and things would get confusing.

It would not be terrible hard to at least show the old text (and data). For this, we would just have to present a diff between an empty page and the old revision, instead of the diff between the old revision and the current revision. I think it could be a multi stage process: first, show the "from empty" diff that shows all content. Then, if desired, show the diff that represents the revert. Then, the user can approve the revert.

I wanted to copy some text from the old edit and add it to the current page.

Why not simply make multiedits impossible? If someone wants to change both the file page and structured data they can make 2 edits. There is no reason to allow something that will fuck up the system :-)

In T225897#6362219, @MGA73 wrote:

Why not simply make multiedits impossible?

@MGA73: Feel very free to "simply" write a patch. :) Also see https://www.mediawiki.org/wiki/Requests_for_comment/Multi-Content_Revisions

As a Commons administrator, I often have to deal with vandalism to file pages with structured data, especially page blanking. Often, there will be conflicting intermediate edits that make a simple undo, rollback, or restore unusable. In these cases, I would normally view the wikitext of an un-vandalized revision, copy the relevant section, and fix the page. However, the diff view of the "Restore a revision" interface makes this task much more difficult. While I can copy the hunks, I must either copy them individually or spend time removing the extra characters introduced by the diff view. This makes the task of reverting vandalism much more time consuming.

FYI this url https://commons.wikimedia.org/w/index.php?title=File:Megacriodes_saundersii.png&action=edit&oldid=354969698 (the equivalent url to that on wikipedia) redirects via http 302 to https://commons.wikimedia.org/w/index.php?title=File:Megacriodes_saundersii.png&action=mcrrestore&restore=354969698

Tagging PET to have another look at this. It's something that came out of the initial MCR implementation, and was meant as a placeholder for a more complete solution. Perhaps someone from PET (me, I guess) could work on this with someone from the structured data team to get this done.

I'm not sure how to fit this into PETs processes and priorities, but it (see T225897#6315977) seems small enough that we should just go and do it, rather than burning energy on discussion.

It seems that structured data breaks old revisions. Not just for random files but for ALL files. So soon we have 60 million files on Commons where the old revisions are broken.

In T225897#6557227, @MGA73 wrote:

It seems that structured data breaks old revisions. Not just for random files but for ALL files. So soon we have 60 million files on Commons where the old revisions are broken.

The old revisions are not broken. It's just the interface that is very awkward making it hard to access these revisions. Take for example https://commons.wikimedia.org/w/index.php?title=File:Megacriodes_saundersii.png&action=history , you can see the content of all revisions at https://commons.wikimedia.org/w/api.php?action=query&prop=revisions&titles=File:Megacriodes_saundersii.png&rvlimit=50&rvprop=timestamp|user|comment|content&format=json .

@Naike and @daniel, is this something PET can get to anytime soon? Thanks!

My updated understanding of what's going on here:

Before the introduction of structured data, a user could click to edit an old revision, and if they saved that (possibly edited) old revision then that would become the new latest revision.

With structured data this no longer makes sense, because structured data is not added/edited on the edit page, but on the "read" version of the page. Say the current revision of a page is n, and structured data was added in revision n - 1. If I click on revision n - 2 and then click edit and save, what should happen - should the structured data added in n - 1 be removed? It's not clear that it should.

To work around this, the PET added an 'mcrrestore' page that shows a diff, and has a 'publish' button that allows the user to restore the old revision. If a user is looking at an old revision, and there are structured data differences between the latest revision and that revision, then clicking 'edit' redirects them to the 'mcrrestore' page

What we propose to do to improve this is, if a user clicks to view an old revision where there have been structured data edits between now and the revision then:

• instead of the 'edit' tab on the old revision page, there will be a 'view source' tab that will show the wikitext at the time of the revision (similar to how protected pages work atm)
• there will be a link to 'mcrrestore' above the read-only text (or perhaps as a tab in the "head" of the page if it's not hard to figure out how to do)

I have updated the task description to more accurately reflect the problem and its causes.

Change 642481 had a related patch set uploaded (by Cparle; owner: Cparle):
[mediawiki/core@master] Show read-only wikitext if editing old revision with non-main-slot diffs from latest

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

Change 642481 merged by jenkins-bot:
[mediawiki/core@master] Show read-only wikitext if editing old revision with non-main-slot diffs from latest

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

In T225897#6665615, @Etonkovidova wrote:

Checked in production (commons wmf.20) and in betalabs commons (tested more in depth there).

Production got rolled back to 1.36.0-wmf.18 (rMW040d7a43ca57) so broken again.

Tested on production and works as expected. See for example https://commons.wikimedia.org/w/index.php?title=File:John_Quinton_Pringle_(1864-1925)_-_Poultry_Yard,_Gartcosh_-_GMA_37_-_National_Galleries_of_Scotland.jpg&action=edit&oldid=518956340

Thanks for fixing this.