Page MenuHomePhabricator

Support slots other than the main slot in EditPage
Open, MediumPublic

Description

EditPage should allow editing of the content of any slot, not just the main slot. Which slot is being edited can be controlled with a URL parameter.

See also T174033: Refactor EditPage to allow multiple slots to be edited atomically [MCR]

NOTE: This mechanism would also allow a new slot to be added. This should not be done without some mechanism in place that governs what slots can exist on what page, to avoid proliferation or arbitrary slots.
NOTE: This ticket does not require any UI for picking the slot to edit. That would be useful, but should be tracked separately.

Related Objects

StatusSubtypeAssignedTask
Declineddchen
OpenNone
OpenNone
DuplicateNone
OpenFeatureNone
OpenBUG REPORTNone
OpenNone
StalledNone
OpenFeatureNone
DuplicateNone
ResolvedNone
OpenNone
OpenNone
OpenFeatureNone
OpenNone
ResolvedNone
ResolvedNone
OpenFeatureNone
OpenNone
OpenFeatureNone
StalledNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenFeatureNone

Event Timeline

daniel triaged this task as Medium priority.Sep 12 2018, 9:53 AM
daniel created this task.

Change 444459 had a related patch set uploaded (by Daniel Kinzler; owner: Daniel Kinzler):
[mediawiki/core@master] WIP Use PageUpdater in EditPage

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

Why is this separate from T174033: Refactor EditPage to allow multiple slots to be edited atomically [MCR]?

Change 444459 had a related patch set uploaded (by Daniel Kinzler; owner: Daniel Kinzler):
[mediawiki/core@master] WIP Use PageUpdater in EditPage

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

I said it there, but I'll say it here too: that change is not what we should do here. We should create the components illustrated in https://www.mediawiki.org/wiki/File:Edit_and_revision_rendering_data_flow_diagram.svg instead:

  • A value object to hold the user input ("User Input" oval). Maybe the same thing could also handle the "Data Input" oval.
  • An edit stash service, to check the stash for a User Input and return the RenderedRevision if one has been cached, and to insert a RenderedRevision into the stash.
  • Some service to do permissions checks on the User Input, if it's more complicated than just Title::userCan( 'edit' or 'create' ).
  • A service to do the "Sections, Edit Conflicts" transformation on the User Input (outputting a "Data Input" if those aren't the same thing).
  • A service to do the "PST, Make rev", converting a Data Input into an unsaved RevisionRecord.
  • A service on top of RevisionStore that does the updates to the page and recentchanges tables too, for the "Save Revision" box.
  • A service that does just the Secondary Updates after being given a RenderedRevision, e.g. a stripped-down version of DerivedPageDataUpdater.
  • Possibly a wrapper service to manage the flows through all these components (the colored arrows in the diagram). Or additional entry points on existing services, whichever.

Currently PageUpdater is trying to implement the red arrow flow. It together with DerivedPageDataUpdater tries to be the "Data Input" and implement the "PST, Make rev" and "Save Revision" and "Secondary Data Updates" all in one; we at least managed to carve RevisionRenderer out of the middle of it. Personally I think it should wind up being deprecated and removed, but let's leave that discussion for another time and place.

Change 460436 had a related patch set uploaded (by Anomie; owner: Anomie):
[mediawiki/core@master] [MCR][WIP] Introduce EditController

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