This patch introduces ParsoidParserCachePrewarm job
that is used to warm PC with parsoid outputs in order
to speed up page reads on large wikis.
Bug: T322427
Change-Id: Ib63a02d3cf5348b36f4f166ff6939f4d2e7fef6f
PageUpdateStatus provides clean access the the newly created
RevisionRecord.
Depends-On: Ia08c586198082ea47e8313d0d41835f9830fb29e
Change-Id: Id6963842321c4eaa3d7d029ad0b769f73433c103
MediaWikiTitleCodec: I removed the comment about dbkey being
"conveniently nullified" since that is no longer correct. The first
preg_replace() can return null, and that is guarded. The second
preg_replace() hopefully can't return null, because if it does, trim()
will generate a deprecation notice on PHP 8.1.
Some other self-explanatory changes.
Change-Id: Iad0ace821eba782c3033ec8abfeac461ac4e8ace
This is really hard to read. What is code, what is string? These
places are so simple, they really don't need the "{$var}" syntax.
Change-Id: I589dedb8c0193eec4eef500bbb896b5b790b727b
If a RefreshLinksJob is created with an improper/invalid title,
executing the job later will fail with a PageAssertionException
while trying to create a WikiPage for that title. Better check
the title when constructing the job, so the offending code is on the
stack when it happens.
Bug: T293291
Depends-On: I7dcfac0eacdd5b22bdf443e88f8e6ddb883b92cc
Change-Id: I77a622591836873415f097453da01ca7e61c41be
Expected value is the first parameter to assertSame() or assertEquals().
And turn to use assertCount() for some assertions aginst count of array.
Based on code search `assert(?:Same|Equals)\(.+,.+expected` and I look
through files roughly, so some assertions that don't contains 'expected'
are also fixed. In the meantime, some assertions that I am not clear
about are not touched.
Change-Id: I75798b60d29fd19b33f4fdf34ed3c788db420d01
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
