Page MenuHomePhabricator

[RFC] Multi-Content Revisions
Closed, ResolvedPublic

Description

Problem

Storing information within the page revision content, has the following benefits:

  • Part of page history, comparable and reversible together with other related content.
  • Editable by users at the same time as other content, and allows them to make a single atomic change.

We currently do this for categories, infoboxes and template data. But embedding this in wikitext has downsides. While it is possible to extract data via the Parser (as for categories), invoking the Parser has a cost. For that reason, we actually store some of the derived data in link tables, but that is only available for the current revision. The goal of MCR is to allow accessing individual slots of content without the overhead of the parser.

Other data is currently stored outside wikitext, such as template documentation, quality assessment, and more. MCR would allow bringing these into the subject page.

Solution

The idea of this RFC is to allow multiple Content objects to be associated with a single revision. A revision will have multiple slots, and each slot can be occupied by one Content object. The "main" slot being reserved for the primary content of the page (that is, for what is currently considered the content of the page).

For details, see https://www.mediawiki.org/wiki/Requests_for_comment/Multi-Content_Revisions.

Related Objects

StatusAssignedTask
ResolvedQgil
ResolvedQgil
ResolvedQgil
ResolvedRfarrand
ResolvedRfarrand
ResolvedQgil
Resolvedcscott
Resolveddaniel
Declineddchen
OpenNone
OpenNone
DuplicateNone
OpenNone
ResolvedAbit
OpenNone
OpenNone
OpenNone
DuplicateNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
Resolvedppelberg
ResolvedKrinkle
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
ResolvedLydia_Pintscher
ResolvedLydia_Pintscher
Resolvedbrion
Resolveddaniel
Resolveddaniel

Event Timeline

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

Question : History of old articles

If I understand correctly, this feature will potentially allow to view an article with the versions of the templates that existed at the time the wikitext was edited. Two questions arise then :

  • will that also work for deleted templates ?
  • will we be able to restore the revisions of version prior to multiple content revision deployment, say a 2005 revison of some article ?

@TomT0m No, Multi-Content-Revisions does not help with consistent display of old template revisions. Well, it does in cases where the use of templates is replaced by the use of slots - if e.g. template documentation was stored in a slot instead of a subpage, you would always see the correct version of the documentation for old versions of the template. But that would be because it would no longer use the template mechanism.

@TomT0m No, Multi-Content-Revisions does not help with consistent display of old template revisions. Well, it does in cases where the use of templates is replaced by the use of slots - if e.g. template documentation was stored in a slot instead of a subpage, you would always see the correct version of the documentation for old versions of the template. But that would be because it would no longer use the template mechanism.

Ok, I got confused. Does that mean that the documentation will not have its wikipage address anymore ?

Would this then be possible to have a special type of "reference" slot which would hold a pointer to another page revision ? I guess the parser could be modified to maintain those reference slots when page are saved.

For example the parser computes a new version of the page when its content is modified, and when he expands a template a hook triggers the slot mangager to store the revision number of the template with those "reference" slots - I guess this this kind of hooks or something similar exists since we got a list of the used templates on previsualisation of a page.

Tgr added a comment.Nov 17 2016, 8:09 AM

If I understand correctly, this feature will potentially allow to view an article with the versions of the templates that existed at the time the wikitext was edited.

You might be thinking of Memento (which is not related to this in any way).

daniel added a comment.EditedNov 19 2016, 3:23 PM

Ok, I got confused. Does that mean that the documentation will not have its wikipage address anymore ?

Yes, the documentation would be part of the template page proper, and would not have a separate title.

Would this then be possible to have a special type of "reference" slot which would hold a pointer to another page revision ? I guess the parser could be modified to maintain those reference slots when page are saved.

That would theoretically possible, but there are currently no plans to do this. I'm also not sure this would be the best way to tie a page revision to template revisions. So far, slots are intended to be editable, not derived. I have been thinking about derived slots, but the use cases for that idea all seem a bit contrieved, and would perhaps be better served by a more specialized solution, like a dedicated database table.

For example the parser computes a new version of the page when its content is modified, and when he expands a template a hook triggers the slot mangager to store the revision number of the template with those "reference" slots - I guess this this kind of hooks or something similar exists since we got a list of the used templates on previsualisation of a page.

This could be done with a DB table that associated a revision ID of the "transcluder" with a revision ID of the "transcluded" in each row. Simple enough to do, and would be stable against moving the template being renamed, etc. It's going to be a big table, though. And quite a change in how things work. As Tgr pointed out, there is the Memento extension that does this with some limitation. It's a feature that has been discussed time and time again, but never gained enough traction to be properly implemented.

Just for clarity, as I've worked on this task but not actually commented, we in Editing see MCR as very important to our long-term plans. The use cases laid out at Multi-Content Revisions#Use Cases cover a lot, but I'll just pull out the four that we see as most vital:

  • The structured media info work, as almost goes without saying;
  • Rejigging templates to have dedicated template, styling, data, and documentation slots, with UI to match;
  • Rejigging files to have a fused history for the blob and the description, removing UI confusion; and
  • Moving to a structured-data approach for categories.

Lots of others are also important, but those are the most useful.

daniel moved this task from Inbox to Project on the User-Daniel board.Jan 5 2017, 7:03 PM
cscott added a comment.EditedJan 11 2017, 8:13 PM

If we use MCR for annotation storage, it would be useful to have a canonical URL for the contents of a specific slot. That might be an API URL, like https://en.wikipedia.org/api/rest_v1/page/html/Main_Page/749836961/<slot number> or else a user-visible URL like https://en.wikipedia.org/wiki/Main_Page/<slot name> or https://en.wikipedia.org/wiki/<Slot>:Main_Page or even a quasi-API URL like https://en.wikipedia.org/wiki/Special:redirect/slot/<revision>/<slotname>. Thoughts?

(cc @MarkTraceur)

Addshore removed a subscriber: Addshore.Apr 3 2017, 9:52 AM
Deskana added a subscriber: Deskana.Jun 7 2017, 2:09 PM
-jem- added a subscriber: -jem-.Jun 23 2017, 10:51 AM
Ayack added a subscriber: Ayack.Jul 6 2017, 7:05 PM
Rical added a subscriber: Rical.Jul 16 2017, 2:04 PM
Restricted Application added a subscriber: PokestarFan. · View Herald TranscriptAug 1 2017, 10:28 AM
Nirmos added a subscriber: Nirmos.Oct 11 2017, 2:34 PM
daniel moved this task from Inbox to Epic on the Multi-Content-Revisions board.
Smalyshev removed a subscriber: Smalyshev.
Krinkle updated the task description. (Show Details)Jan 10 2018, 5:30 PM
Krinkle updated the task description. (Show Details)Jan 10 2018, 5:35 PM
Krinkle updated the task description. (Show Details)Jan 10 2018, 5:37 PM
Rical added a comment.Jan 10 2018, 8:20 PM

As assigned to T135845, I would use dedicated pages to exchange structured datas between several central or local Lua modules.
These pages could content:

  • the first and actual versions of several modules
  • the story of mediawiki versions in each wiki to help coders to better describe new bugs
  • the options to manage these exchanges: central or local, priorities of some modules as managers, used structures...
  • the places where find i18n translations...
Pppery removed a subscriber: Pppery.Oct 1 2018, 6:55 PM

I assume this can be closed now?

Rical added a comment.Jan 5 2019, 9:43 AM

There are other data than those provided for RFCs related to the content of a page.
They will be available thanks to T168726: Create a syntax documentation page for Special:PageData.
A PageData could contain:

  • The first and current versions of several Lua modules,
  • The history of mediawiki versions in each wiki to help coders to better describe new bugs,
  • The options for managing these exchanges: central or local, priorities of certain modules as main, structures used ...
  • Places to find translations i18n ...

These datas are related to the content of the page but not to the revisions.
These 2 tasks could benefit from similar and compatible functions and codings.

daniel closed this task as Resolved.Jan 8 2019, 2:52 PM

This RFC is done. The storage layer of MCR is implemented and deployed. Further refactoring and new features building on top of that will be discussed in separate RFCs if needed.

ahmad added a subscriber: ahmad.Jun 4 2019, 8:23 PM