WikiPage::doModify: Reuse old revision while null-editing
authorZhuyifei1999 <zhuyifei1999@gmail.com>
Sun, 5 Feb 2017 15:20:25 +0000 (15:20 +0000)
committerKrinkle <krinklemail@gmail.com>
Sat, 4 Nov 2017 00:54:18 +0000 (00:54 +0000)
commit3271ce97734b9b10ceab92c527cede1a579e56e0
tree84338430d05b7479f035ac88ae01960c1709ad21
parent93d7ac1bec4b4aeead73f3cba55ff0e8ed1625ab
WikiPage::doModify: Reuse old revision while null-editing

The expected behavior for a null-edit is that the cache gets fully
purged as if another edit has happened, without actually inserting
a new revision into the database. Old implementation was to create
a new Revision instance, copy some of the private instance properties
from the old Revision instance, and skip database insertion. This
method is, unfortunately, prone to errors, as hooks and parsers
expect the given revision data to be equal to whatever the latest
revision is in the database, including timestamp and edit summary.

An alternative solution would be to maintain a method that copies
all the needed data from one revision to another; however, the extra
maintenance cost would be that it would be annoying to maintain it.
This implementation simply reuses the old Revision instance given
by the caller (WikiPage::doEditContent), as it is the latest
revision that hooks and parsers expect.

This patch fixes the error where, after null-editing, the
revision-related magic words, such as {{REVISIONDAY}}, are changed
to the values given by the null edit, instead of the latest revision.
Old behavior was caused by the parser parsing with incorrect
revision data.

Deprecate Revision::setUserIdAndName. It was a hack added in
147f79e for the same bug, addressing {{REVISIONUSER}}, but failed
to address the other magic words, including {{REVISIONDAY}}. I
failed to find any other usage of this instance method.

Bug: T135261
Change-Id: Ifce6a753effb98123574bff45ff59b5c9780f0c2
RELEASE-NOTES-1.31
includes/Revision.php
includes/page/WikiPage.php