Some methods in the PageUpdater's class implements the fluent interface
design pattern. Use the fluent interface where need be.
Change-Id: If76a4b8c5070c20ed40038a4ee78e2d677de5180
This ensures that a DerivedPageDataUpdater is initialized earlier during
the edit process, so it can be used by hooks to access the state of the
ongoing edit.
This patch also cleans up PageUpdater a bit to make the internal information
flow more consistent with the idea that PageUpdater is acting as a
builder for a new revision.
Change-Id: I99abb7bdffb2b5ff5979ba5b1e56d39dba4cd3dc
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
See full rationale at I59068cfed10aabf6c6002f9e9312a6ef6e7e9441.
Using IDatabase for now instead of DBConnRef for better BC.
Change-Id: Ie75aaf46ba91779e8706b10efeefa9580857f489
Updates for the removal of the Revision class itself
and the various methods/hooks/variables removed in the
process, including:
- Update some documentation removing most references
to the Revision class and updating the MCR migration
notes to reflect the past tense for Revision methods.
- Change some capitalization from "Revision" to "revision"
to make it clear comments are about revisions in general,
not the Revision class in particular.
- Minor code tweaks including removing unused variables that
were around for the old hooks that were removed, and
removing the use of DeprecatablePropertyArray where no
longer needed for anything.
- Fix incorrect documentation for PageUpdater::getStatus(),
the status value changed a while ago to have revision-record
in addition to revision, and recently to only have the
revision-record, but ironically PageUpdater was never updated.
- Removed Parser::$mRevisionObject, used to be a Revision object
and was deprecated in 1.35, missed earlier because it was no
longer being set to Revision objects, always null.
- Add RevisionRecord typehints in DummyLinker to match those
in the corresponding Linker methods
This should be a no-op in terms of functionality.
Bug: T247143
Change-Id: I03bbb94fc29085855448780b1a5ad9063911ecc4
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
The removal of the Revision class led to this test failing, since
tt:1000 started to have content - not sure why but I assume something
in the Revision tests was clearing the store - the text
was "UTContent" which is used in many tests via helper
method MediaWikiIntegrationTestCase::getExistingTestPage()
which can create pages with that text.
Change-Id: I04c669ad8c8a7166138eabc973140205b60536a5
The following methods no longer support Revision parameters:
- CategoryMembershipChange::__construct
- ContentHandler::getUndoContent
- DerivedPageDataUpdater::prepareUpdate
- DifferenceEngine::getRevisionHeader
The following methods were removed entirely:
- Title::countAuthorsBetween
The following methods return arrays that formerly include
a 'revision' key that would emit deprecation warnings when
accessed and return a Revision object. The Revision object
has been removed from the arrays, and the 'revision-record'
key should be used to get the relevant RevisionRecord instead:
- PageUpdater::doModify
- PageUpdater::doCreate
- Parser::statelessFetchTemplate
The ParserOptions `templateCallback` option is a callback
that is called in Parser::fetchTemplateAndTitle() and should
return an array - the 'revision' key to that array used to
be a Revision object and was used if no 'revision-record'
was returned - it is now ignored.
Bug: T247143
Change-Id: I163ada88d649c75697aff4fa31a3a3c0bdef78b7
- EditPage::$mBaseRevision
- EditPage::getBaseRevision()
- Title::getFirstRevision()
- LinksUpdate::setRevision()
- LinksUpdate::getRevision()
- Article::$mRevision
- Article::getRevisionFetched()
- WikiPage::getOldestRevision()
- WikiPage::getRevision()
- ContribsPager::tryToCreateValidRevision()
To make things easier, instead of rewritting
the Revision tests that were using WikiPage::getRevision,
just delete them, its not worth the effort to rewrite
them since the class is going away. For the WikiPage
tests, replace uses of getRevision with getRevisionRecord,
manually converting to a Revision object where needed
Bug: T247143
Change-Id: I52bc1f49649f8bd25797e3f7a090bec9c63ac2d1
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
It is not entirely meaningless. It might be an indicator that
the number of calls to a method is intentionally unlimited.
This is similar to e.g. an @inheritDoc PHPDoc comment that
marks a method as being "intentionally undocumented".
However, what's the meaning of being "intentionally
unconstrained"? Let's just not have any constraint then.
I feel all these ->expects( $this->any() ) bloat the test
code so much that it's never worth it.
Change-Id: I9925e7706bd03e1666f6eb0b284cb42b0dd3be23
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
Code performing edits should not need a full User object, a UserIdentity
should be sufficient.
This is an important step to enabling cross-wiki edits.
Bug: T275509
Change-Id: I357772799e82ea88b1b85b605f76ebefc19ebf21
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
This patch touches all uncontroversial (I hope) places where a chain
of isset(), array_key_exist() and the ternary ?: operator can be
replaced with the much shorter ?? feature from PHP 7.
?? does the same. It checks if the element before the ?? is set and
not null. When this check fails, the element after the ?? is used.
Change-Id: Id612e2782ae928164b26b6f0de676c6c7d8302f3
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
My personal best practice is to not document @params when there
is a @dataProvider. I mean, these test…() functions are not
meant to be called from anywhere. They do not really need
documentation. @param tags don't do much but duplicate what the
@dataProvider does. This is error-prone, as demonstrated by the
examples in this patch.
This patch also removes @throws tags from tests. A test…() can
never throw an exception. Otherwise the test would fail.
Most of these are found by the not yet released I10559d8.
Change-Id: I3782bca43f875687cd2be972144a7ab6b298454e
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
* parent::setUp() should be first, and ::tearDown()
should be last
* Move tests that directly extend PHPUnit\Framework\TestCase
to /unit
Change-Id: I1172855c58f4f52a8f624e6d596ec43beb8c93ff
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
Advertize the fact that production errors resulting from corruption in
the content storage layer can be remedied using findBadBlobs.php.
Change-Id: I4eab773d0d2da57a545f211c2fef36146331c570
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
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
The name change happened some time ago, and I think its
about time to start using the name name!
(Done with a find and replace)
My personal motivation for doing this is that I have started
trying out vscode as an IDE for mediawiki development, and
right now it doesn't appear to handle php aliases very well
or at all.
Change-Id: I412235d91ae26e4c1c6a62e0dbb7e7cf3c5ed4a6
