The global function wfWikiID() is deprecated since 1.35 and it's usages
should be replaced with WikiMap::getCurrentWikiId().
Bug: T298059
Change-Id: I22d96b7aec17323d15a9bc401d4511ad2ee14165
In retrospect, I rushed the previous patch: we really need a way to tell
which deletion an ID belong to (and whether it was scheduled). So make
both result getters return an array with known keys that can be used
programmatically. Right now the class can only delete a single page, and
thus there's a single constant and this change is effectively a noop.
The deletionWasScheduled() method, introduced in 1.37, was
hard-deprecated out of an abundance of caution. There are no known uses
on codesearch, so it can probably just be removed in the next release.
Also reorder constructor params to DeletePage -- BacklinkCacheFactory is
a service injected by the factory, hence it shouldn't be grouped
together with value objects injected by the caller.
Change-Id: I32679b7cacc638ec3e9dc5b8dfe9bcc794b22ecf
Results in passing a user where previously the fallback
to $wgUser was being used, mostly in tests.
Bug: T255507
Change-Id: Iabe24315b23c0ad1272353186425e71974528d23
JobRunner catches all exceptions and hides them in the status array,
meaning that it is not obvious when a job fails during a test case.
So, introduce MediaWikiIntegrationTestCase::runJobs(), which runs jobs
and asserts various things about the returned status array.
Depends-On: I4f4790c5d16a0767790eeff202e0be8fcdaeda93
Depends-On: I118f9e3f8950fd82d7b02baed6705b29fd6ab7d5
Change-Id: I63603aa158f77df4b40add096cb248f3b24979f4
It's the same and makes the test code much more readable, I
would like to argue.
Because of the was I split all the changes I made into smaller
patches this patch contains some other changes in the same
lines where I could not split them off. E.g. removal of
->any(), which is the default anyway and doesn't do anything.
Change-Id: Ib297b989d4aec33b31a4e33fe9d5032865b39be0
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
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
* parent::setUp() should be first, and ::tearDown()
should be last
* Move tests that directly extend PHPUnit\Framework\TestCase
to /unit
Change-Id: I1172855c58f4f52a8f624e6d596ec43beb8c93ff
Deconstructing non-sparse, numerically indexed arrays directly in
foreach (a.k.a. using the list() syntax in foreach) is possible since
PHP 5.5.
The possibility to use string array keys as well as non-sequential
numeric keys in array deconstruction was added in PHP 7.1.
Change-Id: I56a48552a45f61cedc291b306cad8548fc70d485
* Remove ILoadBalancer from UserEditCountInitJob constructor,
since it is not a parameter and not a Job property.
It is not needed during Job construction.
* Use ConvertibleTimestamp instead of MWTimestamp since no
MW-specific methods or behaviours are needed here.
* I don't know if UserEditCountInitJob is always safe to de-duplicate,
but this should be decided in the Job class, and is not the
responsibility of calling code that creates/queues a job.
I don't know for sure why this is publicly part of JobSpecification,
but I guess it is there for internal use when serialising jobs,
not for external use in the way it was used here.
I'm assuming for now that its use means it is safe and I moved it to the
UserEditCountInitJob class. If this is not the case and de-dupability is
actually dependent on the parameters, then that logic should reside
in the UserEditCountInitJob constructor.
* Document for which internal use clearUserEditCache() is public.
This way during refactoring the method can be easily found and
made private if that caller is no longer needed.
* Remove needless Job::factory() indirection in the
UserEditCountInitJob test suite. This added overhead that is not
part of the test's purpose, and also risks making the test break
because Job::factory() allows types to be mapped to different
implementations. But, this test suite is meant to cover the
UserEditCountInitJob class implementation specifically.
Change-Id: I6fef4d297b1c0169f95906822e30b4addab7eaf4
The method UserEditTracker::getUserEditCount (as well as the old User class
logic it replaced) calculates the user's edit count and writes it to the
database if it was not computed yet. However, it attempts this write even if
MediaWiki is in read-only mode, causing errors as this method is frequently
called on read requests as well.
As a fix, move the edit count initialization to the job queue, which will avoid
trying to open a source DB connection (and thus cause a read-only error) on
installs that do not use the DB-based job queue. This change requires a
workaround in UserGroupManagerTest.
Bug: T259719
Change-Id: I6d1c8e9038ae1f98f47bdb2495aecc21654b24c0
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
Done with `composer fix` and suppressing the rest (i.e. sniffs for
global variables, which for core should be suppressed anyway).
Additionally, add `-p` to `phpcbf`, as otherwise it just seems stuck.
Change-Id: Ide8d6cdd083655891b6d654e78440fbda81ab2bc
I'm not sure what the benefit was of having this service being injectible
via the constructor. I mean, I wish *all* services would be injected. But
there are more services used in this class, and no other is injected.
Also it seems the only test that was ever setting the ParserCache service
to something else was not even using it: As far as I can see the test
case testJobSpecRemovesDuplicates() is not triggering the code that uses
the ParserCache service.
Change-Id: I65f5c654d36ffecfd914e97cd8069eb99f76c5c6
The ClearUserWatchlistJob removes all of a user's watchlist items.
This adds the watchlist_expiry table to this, to avoid leaving
any orphan rows there. Any existing orphans would be cleaned up by
the purgeExpiredWatchlistItems.php maintenance script.
Bug: T249782
Change-Id: I06d22618d80cc91a75192a8bb80eb5f4345828ed
This should be the exact same. Its more a style change than anything.
So why do it then?
* I believe this is much less confusing than code mentioning a weird
"standard class". Barely anybody knows what this is, and what the
difference between "object" and "stdClass" is.
* The code is shorter.
* It's even faster. In my micro benchmark it's twice as fast.
Change-Id: I7ee0e8ae6d9264a89b6cd1dd861f0466ae620ccc
After I86d26e494924eec24e7b1fb32c424ac1284be478 the job is
no longer instantiated on submission, only upon execution,
so deduplication flags and dedup info are no longer available
to kafka queue.
Bug: T204761
Depends-On: Ieb2604e65177736606aed351c6658b7df748dcee
Change-Id: Ibf95638a2ad218a83347db6749e2e7c9e8dbe0db
Add public, protected or private to function missing a visibility
Enable the tests folder for the phpcs sniff
Change-Id: Ibefce76ea9984c47e08c94889ea2eafca7565e2c
assertSame() is guaranteed to not do any type conversion. This can be
critical when acciden tially comparing, for example, 0 to 0.0.
Change-Id: Iffcc9bda69573623ba14af655dcd697d0fcce525
* Remove logic for saving slow-to-render parser output. This has
not worked ever since DerivedPageDataUpdater was introduced.
* Make the logic to use cached output actually work. This was
also broken since DerivedPageDataUpdater was added. In order
to pass the output, add a known-revision-output parameter
to both WikiPage::doSecondaryUpdates() and
DerivedPageDataUpdater::prepareUpdate().
* Also factored out some helper methods from runForTitle() in
RefreshLinksJob to make it more readable and avoid the need
for multiple transaction round commit calls. This makes the
case of multiple-title jobs less likely to break again.
* Make use of RefreshLinksJob::runForTitle() return value.
* Add unit tests for multiple-title job case.
Change-Id: I0cd13c424a87653b5a7253c42cd48fe43befd692
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
