Manual:Reverts/zh
还原编辑是（广义上）撤销其他编辑者这一行为的编辑。 这一编辑会创建页面的新版本。
本页概述了MediaWiki支持和认可的各种类型的编辑还原，主要面向开发人员。 其还讨论了如何将扩展与MediaWiki核心中存在的编辑还原相关机制集成。
编辑还原类别
MediaWiki认可三种还原的方法。
撤销
UI
可以使用出现在页面历史、差异视图、最近更改以及其他位置的撤消链接来执行撤销。
撤消链接指向带有undo和undoafter参数的index.php?action=edit，这些参数指定应撤消哪些编辑。
undo– 要撤消的最后一个修订的ID。undoafter– 最后一个“好”修订版本的ID。 下一个修订版本将是被撤消的第一个修订版本。
API
回退可以通过使用action=editAPI的undo和undoafter参数执行。
其行为与index.php?action=edit等同。
机制
从undoafter（不含）到undo（含）的所有修订版本都将还原。
从技术上讲，EditPage将undoafter和undo修订版之间差异的相反值应用于页面的当前版本。
如果无法做到，则会显示常规编辑表单，并且此次编辑不视为撤消。
之后，将向用户显示编辑表单，可以在其中进一步修改展示的内容。
自版本1.36起，如果用户在保存前对内容进行了任何修改，则此次编辑不会标记为撤消。 这是为了防止用户将任意编辑标记为撤消。
undoafter和undo可以指向任何修订，但不必位于应用撤消的页面上。 这意味着理论上可以为页面的任何任意更改设计撤消。
其他内容类型
如果您的扩展实现了一个新的ContentHandler，其可以覆盖getUndoContent方法，以便自定义您的内容类型处理撤消的方式。
Rollback
UI
可以使用页面历史、差异视图、最近更改以及其他位置出现的回退链接来执行回退。
回退链接指向index.php?action=rollback，并带有额外的参数，以确保回退正确的更改集。
API
回退可以通过action=rollbackAPI执行。
其行为与index.php?action=rollback等同。
机制
回退功能可以还原页面最后一个编辑者所做的编辑。 在处理破坏时，这通常是个有用的场景，因为通常一个用户最近所做的所有更改都应该被恢复。
当页面的所有修订都来自同一用户时，无法进行回退。
手工回退
| MediaWiki版本： | ≥ 1.36 |
手工回退无需任何特殊UI或API，其只是有人通过将页面恢复为旧版本的方式编辑页面。
有时，这是通过导航到页面历史记录中页面的旧版本，单击编辑（打开常规编辑表单，但会预先填充该修订版的内容）并保存来完成的；有时只是手动编辑最新版本（尤其是在还原一个小更改时）。
软件会自动在限制内推断何时编辑将页面恢复到旧版本。
每次进行编辑时，MediaWiki都会查看页面的一些最新修订版本（由$wgManualRevertSearchRadius指定，默认为15），并查找具有匹配内容的最新修订版本。
如果找到这样的修订版本，则该编辑被标记为“手工回退”，即页面被恢复到旧版本。
可以通过将$wgManualRevertSearchRadius设置为0来完全禁用该功能。
其他编辑还原类别
对于multi-content revisions，还有两个index.php的操作：mcrundo（与撤消相同，但适用于修订版的所有插槽）以及mcrrestore（将所有插槽恢复为旧版本）。
一旦多内容修订更好地与编辑逻辑集成，这些内容就会消失。
“编辑还原”标签
默认情况下，每个被MediaWiki视为还原的修订都会标有适当的编辑标签。
每个标签都可以使用$wgSoftwareTags配置是否单独禁用。
- Undo:
mw-undo - Rollback:
mw-rollback - 手工回退：
mw-manual-revert
自版本1.36起，编辑还原的附加数据与每个标签一起保存在change_tag表的ct_params字段。
数据是与编辑关联的EditResult对象（见下一节），编码为JSON。
通过扩展读取编辑还原的信息
| MediaWiki版本： | ≥ 1.35 |
版本1.35引入了EditResult类，在保存编辑时构造。 此对象在其页面历史记录的上下文中封装了有关编辑效果的信息，最重要的是：
- 该编辑是否为还原
- 使用了哪种还原方法
- 此还原的“基本”修订版本是什么
- 哪些修订被还原
此对象通过PageSaveComplete钩子传递给扩展。
“已被回退”标签
| MediaWiki版本： | ≥ 1.36 |
在1.36版本中引入了一个新的更改标签 – mw-reverted用于标记已被回退的编辑。
计划与执行
该标签应用于使用作业队列计划的名为revertedTagUpdate的作业。
保存编辑后，DerivedPageDataUpdater会将作业添加到队列中。
如果您的wiki有一个繁忙的作业队列，并且您在进行编辑还原和应用标签之间遇到重大延迟，则可能需要在单独的队列中执行作业或确定其优先级，具体取决于您的设置。 见:以了解详情。
执行条件
如果满足以下所有条件，则将在保存编辑后计划更新：
- 该编辑是MediaWiki认可的任何类型的还原。 见#编辑还原类别。
- 被恢复的编辑数小于或等于
$wgRevertedTagMaxDepth。 - 撤销修订版本本身不会标记为已被回退或被删除。
- 该编辑被视为自动批准，根据您的设置，其可能具有不同的含义：
- 如果您通过配置
$wgUseRCPatrol在wiki上启用了巡查，则自动批准等同于自动巡查的编辑。 因此，只有拥有autopatrol权限的用户可以立即应用回退标签。 - 如果您安装了内容管理扩展，例如FlaggedRevs，则其可以告诉MediaWiki编辑是否自动批准。 具体如何确定取决于扩展。 （见#扩展集成。）
- 如果您通过配置
如果巡查子系统或扩展停止了还原的标签更新，则稍后可以在其他用户批准编辑时重新安排更新。 在巡查的情况下，当编辑被巡查时，就会产生这一情况。 有关如何在扩展中与此功能集成的详细信息，请参阅下一节。
mw-reverted标签总是不会应用于与日志操作相对应的虚拟修订（例如页面移动和更改保护），即使其出现在一系列已还原编辑的中间，以避免暗示相关操作已被撤消。
autopatrol权限授予给更广泛的用户组。
扩展集成
涉及某种修订批准机制的扩展可以挂接到已还原的标签功能中，以让MediaWiki知道何时执行已还原的标签更新。
第一部分是BeforeRevertedTagUpdate钩子。 其是在计划更新之前调用的，如果编辑不被自动批准，并且需要进一步审核，则扩展可以使用此挂钩来阻止更新运行。
如果更新已停止，则稍后可以使用RevertedTagUpdateManager服务由扩展重新安排更新。
- Approving a revision :
$revertedTagUpdateManager = MediaWikiServices::getInstance()->getRevertedTagUpdateManager();
$revertedTagUpdateManager->approveRevertedTagForRevision( $acceptedRevisionId );
FlaggedRevs
If you have installed the FlaggedRevs extension, the revert will be considered auto-approved if either:
- FlaggedRevs配置为不在页面上使用。
- 用户具有
autoreview权限。 - 此编辑由编辑者还原。
- 否则该编辑有资格进行自动审核。
如果还原没有被自动批准，则之后可以通过简单地审查编辑来批准这一编辑。