There is nothing the updates can do,
LinksUpdate also fails if there is no id for the given title on master
Bug: T271356
Change-Id: I7fb690bec8dbfadf71eb9caacb4edbfe6b785e73
Were not removed in doc review following creation
of hook interfaces. Fix line length where needed
Change-Id: I2eafffcf3a1c40d0f5613a893c53e0aa14eed6a2
This is micro-optimization of closure code to avoid binding the closure
to $this where it is not needed.
Created by I25a17fb22b6b669e817317a0f45051ae9c608208
Change-Id: I0ffc6200f6c6693d78a3151cb8cea7dce7c21653
Add constants for the core change tags, and use the constant's
phpdoc to describe them. Also document ct_params format.
Change-Id: I03e70df3598ad71d80a8d09af8a314e7200a1264
This is to prevent move and protection entries from being marked
with the mw-reverted tag. Thanks to DannyS712 for a suggestion on
how to fix it :)
Bug: T265312
Change-Id: I127acdec69d37b3d0886ac1b7059bf35f1233f51
The tag is added to reverted edits as described in T254074.
Functionality:
* Adding the mw-reverted tag to reverted edits (duh)
* Limiting the maximum depth of the update through a config variable
(mitigation #2 from T259014).
* Only applying the reverted tag after the edit has been somehow
approved. Only the patrol subsystem currently implements this, but
there's a hook that extensions can use (mitigation #4 from T259014, more
explanation in T259103).
* When performing the delayed update, it is checked whether the reverted
edit was reverted itself. If so, the update is ignored. This is
probably the only way to make the feature work due to the lack of an
explicit "disapproval" mechanism other than reverting.
* The update is also ignored if the revert is marked as deleted.
Technical design:
* The update code is in RevertedTagUpdate.php, which is a deferrable
update, but is not used as such. It's separated to allow for better DI,
testing and better code reusability in the future.
* The update is queued / ran using the Job subsystem. The relevant job
is in RevertedTagUpdateJob.php
* PageUpdater determines whether the edit is approved or not and passes
that to the DerivedPageDataUpdater.
* The BeforeRevertedTagUpdate hook lets extensions decide whether the
update should be ran right away or await approval.
* DerivedPageDataUpdater checks whether the edit is a revert and if so
either enqueues the job (if it's auto-approved) or caches the EditResult
for later use (if it needs approval).
* RevertedTagUpdateManager allows for easy re-enqueueing of the update
for extensions. Thus, it has a very minimal interface.
Other notes:
* The unit testing setup for RevertedTagUpdate is a bit complicated,
but it was the only way I could make this class testable while using
the static ChangeTags class.
Bug: T254074
Depends-On: I86d0e660f0acd51a7351396c5c82a400d3963b94
Change-Id: I70d5b29fec6b6058613f7ac2fb49f9fad9dc8da4
EditResultCache is meant to be an easy way for storing and retrieving
EditResults associated with revisions. It stores the data in the main
object stash which is supposed to be mostly persistent. In case the
main stash method fails, it falls back to trying to find the
EditResult in the ct_params field of revert change tags.
EditResultCache is to be used for delaying the execution of
RevertedTagUpdateJob until the edit is approved. The code for that
will be in the next commit in the relation chain.
This is a separate commit just for clarity.
Bug: T259103
Change-Id: I6c0c6556b6d98fcd131beb0957230ce7c7d268da
Advertize the fact that production errors resulting from corruption in
the content storage layer can be remedied using findBadBlobs.php.
Change-Id: I4eab773d0d2da57a545f211c2fef36146331c570
These were never meant to be part of the public interface and should not
ever have been marked with @since. They're only useful for constructing
the respective objects, which no outside users should be doing.
Change-Id: I86e01272d46fc72af32172d8a12b9180971d4613
Updated the doc block to reflect the changes made in
I9279230303a01461039ae8a4641d9897ce194f73
Bug: T259014
Change-Id: I6aeec4ba75f1e5ac939ef526171d7268902f1f57
This aims to persist the EditResult object associated with reverts
in the ct_params field of change_tag table for revert tags. This can
be later used for analytics or when performing a delayed
RevertedTagUpdateJob (see T259103).
The code doing that has to be in the RecentChange class, as only it
knows the relevant rc_id and rev_id.
Bug: T259733
Change-Id: I365cf44484aa5bf907128a075fcff890649504c4
Serializable EditResult will be required to save it for later use by
RevertedTagUpdateJob.
Additionally I decided to save the serialization format version in
case we want to modify it in the future.
Bug: T259732
Change-Id: I0cddc9c0439c8a59b5f66cea9e7db5bb151cb53b
Previously null edits were not properly marked in EditResult objects
provided by the PageUpdater. This change should fix it, by ensuring
the original revision ID is always set on the EditResultBuilder if
the edit is a null edit.
I've also added some code to test this, so we hopefully don't
encounter an issue like this in the future. :)
Bug: T257766
Change-Id: I04bb058c64483967617958d86aa40a67c31071cb
Based on the patch that introduces manual revert detection, this is
to create a software-defined change tag that will be applied to all
edits that restore a page to an exact previous state. This is also
for consistency with mw-undo and mw-rollback that will make a
"reverted" tag appear on reverted edits in the future.
Note about the REST API tests: in the next patch in this chain
I encountered even more issues with comparing returned changed tags
with expectations, so I decided it'd better if we just checked the
change tags applied manually in these tests. Otherwise we can run into
nasty race conditions, as the reverted tag is processed after sending
the response to client in the deferred update. It also makes the test
hard to maintain.
Bug: T256001
Change-Id: Ic367886f39faedcb823222b7d63bf4d5cb236ae9
The code for manual revert detection is ran when building the
EditResult and the edit was not marked as a revert yet. It's
based on a SELECT looking for recent edits that match the new
revision's SHA1. There is no index over rev_sha1 field, so we
limit the search to N most recent edits, in order not to cause a
full table scan.
I think this shouldn't break any extensions by setting the
originalRevisionId in situations that weren't expected, almost no
extension uses that anyway:
https://codesearch.wmflabs.org/search/?q=%5C%24originalRevId&i=nope&files=&repos=
Bug: T256001
Change-Id: I4e38b382391b42e252cb66584be1e174cdfe348c
For compliance with the new version of the table interface policy
(T255803).
This patch was created by an automated search & replace operation
on the includes/ directory.
Bug: T257789
Change-Id: I17e5e92e24c708ffc846945a136347670a3a20c7
As the EditResult class changes a few things slightly and may be
a bit confusing for developers, I clarified it a bit in the
comments.
It would be probably useful to document this properly on mediawiki.org,
which I'll do once a few things with EditResult are sorted out.
Bug: T254074
Change-Id: Ic8d654ce2c10f079c5a3f417cb2dc0f6e5d7b5b2
Exceptions classes are nearly always value objects, and should in most
cases by newable.
Bug: T247862
Change-Id: I4faa8ec6ea8bc44086cfc8075b32d10eea61e9df
This is a tiny change to use RevisionRecord's hasSameContent
method instead of comparing SHA1s directly. This should also be
marginally faster.
Bug: T254074
Change-Id: Ifbdbf889eab2167ae2510dc9760771c9d4c3c3e0
Once the Revision class is hard deprecated, we will still need to
run hooks that use Revision objects; even though the hooks will be
deprecated, Revision objects still need to be created for them.
To ensure that deprecation warnings aren't triggered by creating
Revision objects in deployed code, for deprecated hooks only
create the Revision object if the hook is registered.
All hooks that pass Revision objects have already been hard deprecated.
Bug: T246284
Change-Id: I7e718551822825cd390662bb201dd13e2e527e8b
This hook was introduced in 1.35 and the EditResult parameter makes
$originalRevId and $undidRevId params redundant.
I also uploaded cross-repo dependent patches for extensions that
already use this hook.
Bug: T254074
Depends-On: I3922d9a92242c9a6469058a2a2c2a95891e9e429
Depends-On: I52e7d6198c000100e9c1013ebc865c1f9b836fe4
Change-Id: I551702327c6e2b6dab9e0eda52f03ebb9382d050
EditResult is an immutable object created during a page update by
the PageUpdater using a builder object, the EditResultBuilder.
EditResult is a container for information on how the edit
interacted with the page and previous revisions. It also aims to
provide a standardized way of describing reverts and reverted
edits. It is as simple as possible, with no dependencies on the DB
or global variables. Most of the logic is encapsulated in the
builder.
PageUpdater::getEditResult() replaces the following methods:
* getOriginalRevisionId()
* getUndidRevisionId()
They are both available in the EditResult object.
PageUpdater::markAsRevert() replaces
PageUpdater::setUndidRevisionId()
Bug: T254074
Change-Id: Ie04c38043d9c295552e488109436ec1df20bb2ca
Clean up some technical debt; use MutableRevisionRecord instead of
manually constructing a Revision from an array, remove last uses of
RevisionStoreDbTestBase::revisionToRow and remove the method.
Each file can be reviewed separately (except that the removal of
revisionToRow depends on replacing its usage)
Bug: T246284
Change-Id: I0bdc069b21a5c41ef8f9e972c5b17ff189d4a741
