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.
- Mentioned In
- T28918: RFC: Provide clean interface to register content editing interfaces
T189220: Ensure that relevant extensions are MCR-aware
T204303: Investigate MCR support gap for Jade purposes
T200297: Review Jade data storage and architecture proposal [RFC]
- Mentioned Here
- T174033: Refactor EditPage to allow multiple slots to be edited atomically [MCR]
Why is this separate from T174033: Refactor EditPage to allow multiple slots to be edited atomically [MCR]?
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.