When using the "undo" function to undo an edit (or a series of edits), changes to all slots should be undone, not just changes to the main slot.
This means that the logic for undoing edits needs to be extracted from EditPage The editable slots should be made available for additional editing, as is currently the case for (most) single-content revisions.
At present, undo simply fails if multipleredirects to a special action that displays a diff with no editing capability when non-main slots are involved, see {T194412}200216}.
Note that undo presently allows manual editing of the content to be undone. This is not possible for all kinds of content (see ContentHandler::supportsDirectEditing), and EditPage also does not currently support editing multiple slots at once.
It would probably be acceptable to not offer the ability to manually edit during an undo (check with product/UX), at least if the undo spans multiple slots. Or manual editing is only offered for the main slot - this seems ok for the SDC use case, but may be surprising when multiple slots are text based. We should at least show a warning explaining this.
Proposed implementation:
Create an UndoAction that works for multiple slots, and functions be showing a diff, and a button to confirm the edit, with no editing ability. In Action::getActionName(), if $actionName === "edit", check if the page has multiple slots (a WikiPage is constructed towards the end of that method anyway). If it has multiple slots, set $actionName = 'undo', triggering the new code.
UndoAction may later gain editing ability, or may otherwise be consolidated with code that is being factored out of EditPage. For now, this approach allows us to implement undo logic that will work for SDC without touching the old behavior. Note that undo logic will have to be factored out of EditPage anyway at some point. This could act as a first step.
However: depending on how much of the logic in EditPage::internalAttemptSave needs to be replicated (especially, conflict resolution and various hook points, including edit filters), it may make more sense to at least have a partial refactoring of EditPage,Implementing this will depend on the updating of the edit form itself to be able to handle multiple slots. to avoid duplicating this logic.
Some considerations:
* Undo should not offer any free form editing ability for models for which ContentHandler::supportsDirectEditing returns false.
* Perhaps free form editing can be dropped from the undo function completely.At a high level, If we keep it,the edit form takes serialized Content data for each slot to populate the form. we'll need {T174033}.
* A diff for each slot should be shown for confirmation,The initial loading of the page (e.g. {T194731}.
* If undo supports editing,from an edit link) generally gets this data from a saved revision. it needs to supportWhen the user requests a preview! or diff, If it does not support editing,it gets this data from the user's submission. it cAn undo would show a preview right away, {T174036}get the data from the Content objects returned by `ContentHandler::getUndoContent()`.
Note that not all content models support direct editing of the content (see `ContentHandler::supportsDirectEditing`). The undo content for such slots must be preserved through the process of displaying the edit form, displaying any previews and diffs requested by the user, and finally saving the edit. The "edit" interface for such slots should probably display a diff or other indication that changes will be made to the slot. Any previews and diffs requested by the user while editing should include the changes to the uneditable slots.