Page MenuHomePhabricator

Selective delete of edits
Open, MediumPublic

Description

MediaWiki should provide a feature to selective delete a revision from page history (the effect equals to delete the whole page and then restore some of the revisions). This can be used to hide vandalisms from page history, where https://www.mediawiki.org/wiki/Help:RevisionDelete will keep vandalism displayed in page history.

To do this, while not affecting existing behaviour, a new page action is needed, that would delete only that specific revision. The name revisiondelete is already taken by another action, so the new one would need to be named to avoid any potential confusion. Suggest deletesinglerevision would make some sense. e.g. https://en.wikipedia.org/w/index.php?&oldid=1226465489&action=deletesinglerevision would only delete https://en.wikipedia.org/w/index.php?&oldid=1226465489

If no revision is specified, this probably should default to deleting the last revision of a page.

You'll also need:

  • A special page at [[Special:DeleteSingleRevision]] where one can enter the number of the revision to delete, and then delete it.
  • Logging of actions in the deletion log.
  • Links saying "delete revision" in various places, e.g. in the page history, where they can be easily accessed by admins, but incremental build-up of the steps above is probably possible.

The following would then also be likely needed...

  • A similar way to undelete a specific revision, as well; i.e. &action=undeletesinglerevision plus a special page.
  • A similar way to suppress specific revisions, i.e. &action=suppresssinglerevision

Most of this can probably be achieved by copying existing code for &action=delete, with minor alterations. However, it would be a medium-sized project to implement.

See also: T23312: Request for feature: RevisionMove (to move individual revision to another page)

Notes

  • Possible page actions are specified in: includes/actions/ActionFactory.php.
  • There is a specific delete action: includes/actions/DeleteAction.php which can form the basis of the new action.
  • You'll need a new special page in includes/specials/ for [[Special:DeleteSingleRevision]].
MediaWiki supports deletion of individual file revision via the oldimage parameter of action=delete API.

Original (vague and waffly) request:

Status: enhancement

Currently admins can delete a page with all its edits, and also can undelete all or some of an article's deleted edits.

Often when history-merging I have had, as a preliminary, to temporarily delete late edits (often a bot edit) that had been added to the source after the cut-and-paste event, and to temporarily delete early edits (redirects and miscellaneous) that were at the destination's name before the cut-and-paste event which caused the need for the history-merge.

To do that, I must delete the file with all its edits, and then to undelete most of its edits. That wastes administrator time and internet time and Wikipedia server time. It would be easier if, when deleting a page, if I could select which of its edits to delete.

The history display of non-deleted edits already has a column of small square clickables, one per edit; this column could also be used to select edits to delete.
That column of clickables should have controls for "unmark all" and "invert the selection". (Selective undeleting already has an "invert the selection" feature.)

Event Timeline

Aklapper changed the task status from Open to Stalled.Jan 12 2019, 11:10 AM
Aklapper added a subscriber: Liuxinyu970226.

@Liuxinyu970226: How it this related to page deletion?

Hi @Anthony_Appleyard, which underlying problem do you face which you think would be solved by "deleting an edit"? When is "history merging" of what performed? What "cut and paste events" do you refer to and how are they related to deleting an edit? Can you provide a specific example article where this would be helpful, and point out which exact edits you would move from where to where? Please add a more complete description to this report: Clear list of specific steps to reproduce the situation, as little details sometimes matter, so that nobody needs to guess which exact situation you face, describing actual results and expected results after performing the steps to reproduce.
You can edit the task description by clicking Edit Task. Thanks!

Aklapper changed the task status from Stalled to Open.Jan 12 2019, 2:32 PM
Aklapper added a project: MediaWiki-Page-diffs.

Can you provide a specific example article where this would be helpful, and point out which exact edits you would move from where to where?

I agree that a more concrete example would be helpful. Otherwise, perhaps the task should be closed as invalid due to incomprehensibility.

More simply :: sometimes in my work, I need to delete some edits of a page's edit history. But I cannot :: I must delete all of that page's edits, then undelete some of them. That wastes internet link time and Wikipedia server time. That is why selective delete is needed.

More simply :: sometimes in my work, I need to delete some edits of a page's edit history. But I cannot :: I must delete all of that page's edits, then undelete some of them. That wastes internet link time and Wikipedia server time. That is why selective delete is needed.

Oh, I get what you're saying now (after looking at the edit history of your comment). What if we have a feature that lets you select (perhaps with an option to invert the selection, to save time), certain revisions to be moved to a new page? So then you either move the revisions you want to merge, or move everything EXCEPT the revisions you want to merge, and then do your merge.

Or, just have the merge feature have an option to merge only certain revisions (again, with an option to invert the selection).

In an edit history of non-deleted edits (e.g. https://en.wikipedia.org/w/index.php?title=Scuba&action=history ), the details of each edit include a small square check. That is to select edits to be hidden. But with some reprogramming it could also be used to select edits for other purposes.

When an administrator has selected some edits, there could be options for him to ask for various things to be done with them, e.g.: (1) Deleting them. (2) Moving them to another pagename (i.e. renaming them). (3) Delete them and rename them at the same time.

If he asks for those pages to be moved, if there are already non-deleted edits at the new pagename, the system could ask the user: "There are already edits at (name); do you want me to delete them? Or do you want me to merge them with the edits which you are moving in?".

(It would also be useful for him to be able to move (rename) deleted edits while keeping them deleted.)

When an administrator has selected some edits, there could be options for him to ask for various things to be done with them, e.g.: (1) Deleting them. (2) Moving them to another pagename (i.e. renaming them). (3) Delete them and rename them at the same time.

This is how a lot of forum software works; you select threads in a sub-forum, or posts in a thread, and then there's a drop-down menu of moderation options such as deleting the selected items, or moving them, etc.

I wonder, if we have checkboxes for page deletion of specific revisions (aka sending them to the archive table), if anyone is going to complain that people will confuse this with revision deletion (aka "changing visibility of selected revisions").

Maybe for now, it's best to just implement the "move revisions" feature (although people might complain that too could be confused with the "move page" feature). Perhaps we should ask wikitech-l what they think.

@Anthony_Appleyard So basically you want something along the lines of this, it sounds like. https://upload.wikimedia.org/wikipedia/mediawiki/d/d2/Screenshot-localhost-2019-02-26-23-07-41.png

(The dropdown box needs to be moved up a bit; I'm still experimenting with HTML/XML forms)

"Archive," by the way, is just another word for "move to the archive table," aka use the page deletion tool on those revisions (except without getting rid of the page entry), as opposed to the revision deletion tool.

Would you actually use a "delete them and rename them at the same time" option pretty frequently? What's an example of a situation where you would do that?

! In T213617#4987163, @Setian wrote:
Would you actually use a "delete them and rename them at the same time" option pretty frequently? What's an example of a situation where you would do that?

Sometimes when history-merging, I must temporary delete some edits. If the page already has deleted edits, the newly-deleted edits should be kept apart from the already-deleted edits, to avoid a mix-up. (That could also be achieved by letting the admin temporarily move the already-deleted edits to another name while keeping them deleted.)

! In T213617#4987163, @Setian wrote:
@Anthony_Appleyard So basically you want something along the lines of this, it sounds like. https://upload.wikimedia.org/wikipedia/mediawiki/d/d2/Screenshot-localhost-2019-02-26-23-07-41.png

(The dropdown box needs to be moved up a bit; I'm still experimenting with HTML/XML forms)

"Archive," by the way, is just another word for "move to the archive table," aka use the page deletion tool on those revisions (except without getting rid of the page entry), as opposed to the revision deletion tool.

Currently, when non-deleted edits have been selected with the small square check-boxes, the available options of what to do with the selected edits, are:
*(1) Change the visibility of selected revisions. (I tend to call it "hiding")
*(2) Edit tags of selected revisions

Of these:
(1) seems to be distinct from ordinary deleting. In my experience, an edit can be hidden, or deleted, or neither, or both at the same time.
(2) seems to be to hide edit-comments that contain inappropriate matter.

Your "localhost/test" example seems to also have these options:
*(3) Archive selected revisions.
*(4) Move selected revisions.

About (3), as regards the meaning of "archive", I have read:-

  • Help:Archiving a talk page
  • Wikipedia:Historical archive
  • Help:Archiving a source

(4) looks useful.

Adding this option would be useful:
*(5) Delete selected revisions.

The situation is complicated by the fact that there are two tables for storing revisions, the archive table and the revision table.

Page deletion moves rows from the revision table to the archive table, while revision deletion only changes the rev_deleted value, while keeping the rows in the revision table.

When a revision row is still in the revision table, you can use action=history to see that data (the revision's timestamp, user, comment, etc.). After a revision row is moved to the archive table, you have to use Special:Undelete to see that data.

Pretty much everyone agrees we should just get rid of the archive table, since the use of two separate tables requires us to use separate tools (e.g. action=history and Special:Undelete; Special:Contributions and Special:Contributions; etc.) for dealing with them.

We can probably implement what @Anthony_Appleyard is looking for without changing the underlying infrastructure, but it would amount to investing more in a system that ultimately needs to be scrapped and replaced.

I have now read https://www.mediawiki.org/wiki/Manual:RevisionDelete and https://www.mediawiki.org/wiki/Manual:Revision_table

The entry https://www.mediawiki.org/wiki/Manual:Revision_table#rev_deleted says that "rev_deleted ... This field is reserved for the RevisionDelete system. It's a bitfield in which the values are DELETED_TEXT = 1; DELETED_COMMENT = 2; DELETED_USER = 4; and DELETED_RESTRICTED = 8." Does this show that "revision deletion" is what I listed at (1) above, i.e. what I thought of as "hiding" edits, and not the same as the ordinary deleting and undeleting of edits or pages that users often ask me to perform? Or what?

I have now read https://www.mediawiki.org/wiki/Manual:RevisionDelete and https://www.mediawiki.org/wiki/Manual:Revision_table

The entry https://www.mediawiki.org/wiki/Manual:Revision_table#rev_deleted says that "rev_deleted ... This field is reserved for the RevisionDelete system. It's a bitfield in which the values are DELETED_TEXT = 1; DELETED_COMMENT = 2; DELETED_USER = 4; and DELETED_RESTRICTED = 8." Does this show that "revision deletion" is what I listed at (1) above, i.e. what I thought of as "hiding" edits, and not the same as ordinary deleting and undeleting of edits or pages that users often ask me to perform? Or what?

Yes, the rev_deleted field is what stores data about the visibility of a revision.

I can't find any records from MediaWiki 1.1 or 1.2, but page deletion, using the archive table, has been with us going back at least as far as MediaWiki 1.3. The old way of removing a particular revision from view, while keeping everything else visible, was to delete the whole page and then restore everything but the revision(s) one wanted gone.

In MediaWiki 1.5, the database schema was restructured, and revision deleting, means changing visibility of revisions, was introduced (along with the rev_deleted field, which was used to store that data). This was a lot more efficient because it didn't require moving a bunch of rows back and forth between the revision and archive tables just for the sake of getting rid of a small number of rows pertaining to revisions that needed to be removed from public view.

However, we never totally got rid of the archive table, and to this day, the two systems exist side-by-side with each other. If it were to be redesigned from scratch, though, there would be no archive table, and "page deletion" features would be implemented by some different, more efficient mechanism that would eliminate the need to EVER move revisions to an archive table or vice versa. E.g., the page would simply be marked as "deleted" (perhaps by making a change to some field in the page table) and that would be the end of it.

Anyway, whatever we do with regard to that, it looks like it will be necessary (or at least useful, cleaner, and more efficient) to implement at least part of what you suggest, which is the feature to move revisions from one page to another without using page deletion (i.e. without moving anything to the archive table). I see that you've filed that as a separate task, T23312.

The need for selective archive-table-based deletion of revisions might in the long run be eliminated by deprecating the archive table, depending on what kind of system ends up replacing it.

See https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard#Deleting_part_of_of_page%27s_edit_history for this idea re-surfacing. I do much history-merging in the English Wikipedia, and in the course of that I have picked up a few things.

There are 2 processes involved here:

  • (1) Deleting, as accessed by a web page name of type "https://en.wikipedia.org/w/index.php?title=''page_name''&action=delete", or is done if an AfD discussion yields "yes".
  • (2) Hiding, as accessed by the 2 long clickables at top right of a Wikipedia edit history display as seen by an admin, marked "Change visibility of selected revisions" and "Edit tags of selected revisions".

:*Above, I was writing about deleting. Please do not confuse these two processes.

An important difference between deleting and hiding (as defined in the message above) is that, if a page is moved, hidden edits move along with it, but deleted edits do not move along with it. This is important in history-merging and history-splitting. @Setian @Aklapper @Izno . We need to keep both facilities: deleting and hiding.

I'm not sure that this is a duplicate of T381460 given that this seems to be a vague non-specific request to be able to split page histories, whereas T381460 is/was a specific request for a specific useful feature.

Bugreporter2 added a project: patch-welcome.
Bugreporter2 updated the task description. (Show Details)

As part of my Clinic Duty rotation, I am summarizing the below insights. However, I cannot move this task because of the quoted error.

  • The task description appears to have sufficient information for someone to come up with an approach and implement a solution for the task.
  • The previous comment, a minor one, on this task was in 2024. Meaningful discussion on this task occurred in 2019 and 2020.
  • There is value to addressing vandalism, and I am unclear as to the priority of solving this problem in the context of our team goals. If I could move this task, I might move it to the Bugs & Chores column of our MWI team workboard, for when someone wants to work on the task for fun.
  • @aaron moved a related task, Request for feature: RevisionMove, to "Radar (other teams work)" in September 2025. Should this task go there, too?

Access Denied: T213617
You do not have permission to edit this object.

Users with the "Can Edit" capability:
This object has a custom policy controlling who can take this action.
These rules are processed in order:

  • Allow task author
  • Allow administrators
  • Allow members of any projectTrusted-Contributors, WMF-NDA
  • Allow subscribers

If no rules match, deny all other users.

BPirkle subscribed.

Moving to Radar based on handling similar task T23312: Request for feature: RevisionMove, so they'll stay together.