Page MenuHomePhabricator

Integrate page meta-data as a new content model revision slot for consistency and atomicity
Open, Needs TriagePublic

Description

It would be very nice, once T107595: [RFC] Multi-Content Revisions is done, to provide all page-related meta-data in a single content (sub)slot.

Benefits

  • This would allow most of the oddities of page-level changes to be shown more consistently and readily to users (for example, this diff page isn't very clear).
  • It would also allow common double-edit actions to be replaced with a single, atomic, mutli-part edit for less work on the part of editors and more clarity (albeit needing a little more complexity in the tools) – for example, altering a page's protection status and adding/removing a protection template.
  • This would enable a richer set of behavioural modifications to be done by MediaWiki itself rather than e.g. per-wiki JS gadgets – for example, special edit notices for members of a category (though this example will be fixed directly before this work is started).

A possible (not exhaustive) list of such meta-data:

  • Title changes ('moves'); this would fix T10731: Show logs for moved pages corresponding to old page name etc. and allow much more readily
  • Title over-ride changes (DISPLAYTITLE; see question below)
  • Protection changes
  • Language link changes
  • Category inclusion changes ([[Category:Foo:]]; note these are (?)intentionally relatively-positional to establish the page render order)
  • Category sort title changes ({{DEFAULTSORT:…}})
  • Redirect state changes (see question below)
  • Other log-action changes which alter the state of the page (e.g. in FlaggedRevs, changing the 'accepted' revision pointer)
  • Non-positional behavioural switch changes (e.g. addition/removal __NOTOC__, __NOEDITSECTION__, __INDEX__, __HIDDENCAT__)
  • Page content model changes
  • Others…

Some open questions:

  • Would this be derived or primary?
    • If the former, what does that mean more generally? Is it more useful in that state?
    • If the latter, would we pull all the items out of the 'wikitext' slot but show them there on edit as a synthetic page to allow editing through that interface as well? Does that mean normalisation of existing wikitext sequencing? How beneficial vs. disruptive would this be for users? Are there any desired behaviours we currently have or in future would like to have that this would prevent?
  • For things which are specific to the wikitext content model but are thought of more generally (e.g. Categories), is opening up this meta-data to those pages a good thing?
  • For things which are currently specific to the wikitext content model but are actually about MediaWiki rather than wikitext – most obviously, redirect states and title over-rides – are these things we'd want to move out of the content model and into MediaWiki generally? See T45049: [Regression] Allow moving of pages between models (wikitext -> js / wikitext -> css).
  • What'd we do about other meta-data like things that don't work in this model (e.g. positional behavioural switches like __TOC__, labelled-section transclusion and translation extension markers, etc.)?
  • What'd we do about meta-data inherited through transclusions? (Category membership most obviously.)
  • How can we make this nicely extensible (e.g. for Flagged Revisions to add additional data)

Related Objects

StatusAssignedTask
OpenNone
OpenNone
OpenNone
Resolvedbrion
Resolveddaniel
Resolveddaniel
Resolveddaniel
Resolveddaniel
Resolveddaniel
Resolveddaniel
OpenNone
OpenNone
Resolvedawight
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
Resolvedovasileva
OpenNone
OpenEdtadros
OpenNone
OpenNone
Resolveddaniel
ResolvedJdforrester-WMF
Resolveddaniel
ResolvedJdforrester-WMF
ResolvedJdforrester-WMF
OpenNone
DuplicateNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
Opendaniel
Resolveddaniel
Resolveddaniel
OpenCCicalese_WMF
OpenNone
Opendaniel
Resolveddaniel
Invaliddaniel
DuplicateNone
ResolvedAnomie
ResolvedAnomie
ResolvedAnomie
ResolvedAddshore
Resolveddaniel
ResolvedAnomie
ResolvedNone
DuplicateNone
StalledNone
Resolveddaniel
ResolvedAddshore
Resolveddaniel
ResolvedMarostegui
ResolvedAddshore
ResolvedMarostegui
ResolvedTgr
DuplicateNone
ResolvedAddshore
Resolveddaniel
OpenNone
OpenNone
OpenNone
Resolveddaniel
Resolveddaniel
Resolveddaniel
ResolvedTgr
ResolvedTgr
ResolvedTgr
ResolvedBstorm
ResolvedCCicalese_WMF
OpenNone
OpenVedmaka
OpenNone
OpenAnomie
Resolveddaniel
Opendaniel
ResolvedAnomie
ResolvedAnomie
OpenAnomie
OpenNone
OpenNone
Opendaniel
OpenNone
OpenAnomie
Resolveddaniel
Resolveddaniel
InvalidTgr
ResolvedAnomie
ResolvedAnomie
OpenNone
OpenNone
OpenNone
Resolveddaniel
DuplicateNone
ResolvedAnomie
ResolvedAnomie
ResolvedTgr
ResolvedTgr
OpenNone
OpenNone
Resolveddaniel
ResolvedBPirkle