This patch introduces a ParsoidOutputAccess service for
getting parsoid outputs and warms the cache with pregenerated
outputs.
It also introduces a config variable in ParsoidCacheConfig that
is turned off by default for controlling the cache warming.
Bug: T301371
Change-Id: I6152c42ea765d94093d8d62598b1b4278314adec
All revision related classes are namespaced MediaWiki\Revision
instead of MediaWiki\Storage since 1.32. The old namespaced
class names are deprecated and only kept for backwards-compatibility.
Bug: T305784
Change-Id: Ia0030814ce2176d06e2898acffe533d31633fccb
This reverts commit dab7b16741.
Reason for revert: This was inaccurate/incomplete &
looks like we will not need this after all
Bug: T286362
Change-Id: I6d63d69f180d193f99986ce6878617d63cfb2b6d
PreparedUpdate represents an in-progress edit. It can be used to access
information about the edit from hooks that do to have access to the
PageUpdater. Ideally, the PreparedUpdate or PageUpdater would be passed
to the hook as a parameter. Handlers of legacy hooks may use
WikiPage::prepareUpdate() to access it.
Bug: T242249
Needed-By: I23324a31e06e7e6f28077085c0ade05db63e9a35
Change-Id: Id5ba40a21cc4547205adf2f3a1f725c3a69c24d8
WikiPage is not the right spot to compute all the revert
related stuff - we already figure out manual reverts when
building the EditResult, lets figure out rollbacks and undos
in there as well.
Change-Id: I9fdc5f24c1db1eb0452b90bf4af1ef5ffbce6cb8
Note: this contains a b/c incompatible change to
SlotRoleHandler, but it's never used in any extensions
and never was used.
Change-Id: I898ab18467f7f8c605a579cc6236859b9d86c7f5
Additionally it switches the query from DB_PRIMARY to DB_REPLICA.
I understand the idea with a quick revert, but I do not think
it can be that quick - to revert a newest revision of a page,
an editor or a bot needs to actually read it first, and reads
come from a replica. So we know at least some replicas already
had the latest revision showing to the user. Very likely by the
time revert is made, we'd have it in all replicas. If not - oh well,
we can't be perfect. But we shouldn't really do such a query on
primary - it's too heavy.
Change-Id: I2fae8dbe5f19635f4d99e26242e3b08ddad8f8af
Inline creation of single-use variables
Use $this->createMock() and createNoOpMock()
for FutureChangeTags.
Change-Id: I7d6632f61bc634279f62cefde9c7935143661c65
Use one line instead of three to document variable types.
Make ContentHandlerFactory final again, no need to make
non-final.
Use MockServiceDependenciesTrait to simplify creation
of PageUpdaterFactory in unit tests.
Use Wikimedia\Rdbms\LoadBalancer instead of deprecated
alias \LoadBalancer.
Follow-up: I2a060bfa8ac098edf24fc4d51212eeb7ddf3942d
Change-Id: I63b18f71cb6e40c971511e71e8475d49ef530d71
We can create a BlobStoreFactory with mock services,
the only testing is for the domain of the blob store
being set correctly, which does not require any integration.
Change-Id: I6c4d3f53b3931e3517374ae582208910b56b64f3
This introduces 2 new tags to track changes in media usage
across articles. These tags are both hidden & disabled by
default.
Bug: T266067
Change-Id: Ia230eadf7dcf6f52facab17b92293f25de38bb1c
This is the default anyway when using ->with(). The test code
becomes so much more readable without this, I would like to
argue. Let it just say "with these values".
Because of the way I split my changes into multiple patches
there are a few other changes in this patch I could not split,
e.g. removing unnecessary ->any(). This is the default anyway
and doesn't make the test more specific.
Change-Id: I34990799fa9258ba8dc64c7e78ec43f7903b7681
Ended up using
grep -Prl '\->setMethods\(' . | xargs sed -r -i 's/setMethods\(/onlyMethods\(/g'
special-casing setMethods( null ) -> onlyMethods( [] )
and then manual fix of failing test (from PS2 onwards).
Bug: T278010
Change-Id: I012dca7ae774bb430c1c44d50991ba0b633353f1
This reverts commit 5a0bfa9d98.
Reason for revert: caused a train blocker (T278429) plus Daniel says it's "super expensive"
Bug: T278429
Bug: T266067
Change-Id: I6724b4bc02d29c12c3fe18cc1e8fa17a443257d5
Providing a PageIdentity to getRevisionById removes the need
to look up page related data, and to construct a Title.
Bug: T275531
Bug: T273284
Depends-On: I8d0dc30ecd0c0c65c337170d271c2e2531914686
Change-Id: I683362ccd669acf2aadf56853afeb1ca6dee6f8c
This introduces 3 new tags to track changes in media usage
across articles. These tags are both hidden & disabled by
default.
Bug: T266067
Change-Id: I3e7acafe0b2266cf6e253dfef42fa6c666424469
As we convert the RevisionRecord to using Authority,
we no longer need Title instances, so we can convert
that to PageIdentity.
Ideally, we'd part away from using Title at all, but:
1. For foreign wikis PageIdentity has stronger validation,
so calling PageIdentity getId() on Title will break things.
There's still a lot of code depending on lax Title guarantees,
so we keep it.
2. A lot of code still depends on Title, so we try to pass it
through even if we don't nesessarily need to, to save cost
on recreating it later on.
Bug: T271458
Depends-On: I287400b967b467ea18bebbb579e881a785a19158
Change-Id: I63d9807264d7e2295afef51fc9d982447f92fcbd
These are not only 100% identical to the actual code, but also:
* It's error-prone. Some are already wrong.
* These test…() functions are not meant to be called from
anywhere. What is the target audience for this documentation?
* There is a @dataProvider. What such @param tags actually do is
document the provider, but in an odd place. Just looking at
the provider should give the same information.
* The MediaWiki CodeSniffer allows to skip @param when there is
a @dataProvider, for the reasone listed.
Change-Id: I0f6f42f9a15776df944a0da48a50f9d5a2fb6349
Most of these are found by the not yet released I10559d8.
I remove the type MockObject in some cases when the calling
code really does not need to know if he get's a mock or the
real thing. However, I do this only in places that are very
closely related to the fixes.
Change-Id: I26a4c3c5a8ae141bf56161b52b54bce7e68f2e30
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
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
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
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
Add public, protected or private to function missing a visibility
Enable the tests folder for the phpcs sniff
Change-Id: Ibefce76ea9984c47e08c94889ea2eafca7565e2c
This changeset resumes work on T89432 and related tickets
by porting an initial set of tests to the new unit test suite
separated out in I69b92db3e70093570e05cc0a64c7780a278b321a.
The tests were only ported if they worked immediately without
requiring any changes other than changing the test case class
to MediaWikiUnitTestCase and moving the test to the new suite.
If a test failed for any reason (even trivial misconfiguration),
it was NOT ported.
With this change, the unit tests suite now consits of a total
of 455 tests. As before, you can run these tests via the following
command:
$ composer phpunit:unit
Bug: T84948
Bug: T89432
Bug: T87781
Change-Id: Ibb8175981092d7f41864e641cc3c118af70a5c76
This changeset implements T89432 and related tickets and is based on exploration
done at the Prague Hackathon. The goal is to identify tests in MediaWiki core
that can be run without having to install & configure MediaWiki and its dependencies,
and provide a way to execute these tests via the standard phpunit entry point,
allowing for faster development and integration with existing tooling like IDEs.
The initial set of tests that met these criteria were identified using the work Amir did in
I88822667693d9e00ac3d4639c87bc24e5083e5e8. These tests were then moved into a new subdirectory
under phpunit/ and organized into a separate test suite. The environment for this suite
is set up via a PHPUnit bootstrap file without a custom entry point.
You can execute these tests by running:
$ vendor/bin/phpunit -d memory_limit=512M -c tests/phpunit/unit-tests.xml
Bug: T89432
Bug: T87781
Bug: T84948
Change-Id: Iad01033a0548afd4d2a6f2c1ef6fcc9debf72c0d
