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
To properly support content models that do not support redirects
during historymerge we have to do some cleanup, else after merging
all revisions of a page, a corrupted page will be left with a page id
(because it was not deleted) but no live revision (because they have
been all merged to the destination page).
This will lead to cascade of exceptions in Wikipage, RevisionStore,
RevisionStoreRecord, PoolWorkArticleView as well other various paths
that will attempt to interact with these, because page and revision
mismatch is considered a logic error almost everywhere.
The failure does not happen for content models that support redirects
because they are immediately creating new (latest) revision for the
old corrupted page. But we cannot require all content models to support
redirects, may not be feasible and can hinder forward compatibility.
This patch fixes this for content models that do not support redirect.
Now after merging all revisions of a page to another page, and the
source content model does not support redirect, empty content will be
created to aid proper deletion of the page afterwards.
Creating the content before deletion is necessary, else proper
deletion is not possible because many calls to revision-related methods
will throw exception during the deletion if we just use the original
corrupted page which does not have proper revisions now.
Bug: T93469
Bug: T263340
Change-Id: I07109445288633e3ddece4190f0c1c2b10372384
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
Deprecating something means to say something nasty about it, or to draw
its character into question. For example, "this function is lazy and good
for nothing". Deprecatory remarks by a developer are generally taken as a
warning that violence will soon be done against the function in question.
Other developers are thus warned to avoid associating with the deprecated
function.
However, since wfDeprecated() was introduced, it has become obvious that
the targets of deprecation are not limited to functions. Developers can
deprecate literally anything: a parameter, a return value, a file
format, Mondays, the concept of being, etc. wfDeprecated() requires
every deprecatory statement to begin with "use of", leading to some
awkward sentences. For example, one might say: "Use of your mouth to
cough without it being covered by your arm is deprecated since 2020."
So, introduce wfDeprecatedMsg(), which allows deprecation messages to be
specified in plain text, with the caller description being optionally
appended. Migrate incorrect or gramatically awkward uses of wfDeprecated()
to wfDeprecatedMsg().
Change-Id: Ib3dd2fe37677d98425d0f3692db5c9e988943ae8
If $wgContentHandlerUseDB is false and
$wgMultiContentRevisionSchemaMigrationStage is not SCHEMA_COMPAT_OLD,
RevisionStoreFactory::getRevisionStore() throws. This is coming up in
some seemingly unrelated code changes, perhaps due to access of stale
service objects, but I'm not sure because I can't reproduce locally. So
this is a shot in the dark to fix it.
Change-Id: Id29a62e1f537fa1b2016aac396773b728e238cda
In PHP, `strtotime('tomorrow')` evaluates to the first midnight
after the current time.
Which means on Aug 14 at 23:59:59, strtotime('tomorrow') refers
to a timestamp merely 1 second in the future (Aug 15 00:00:00).
This causes the test to fail because this timestamp is computed
in a data provider, before the test itself starts. In order to
pass, it needs to be far enough in the future that it will also
be after the point in time where the test creates the page and
revisions in question.
Fix this by:
* ... moving it into the test itself, where even plain time()
should probably suffice, but that's for another time.
* ... using +24*3600 instead of strtotime().
Bug: T201976
Change-Id: Ice5d54af4fb7cffa8db9b657796ba6ebecdaffa0
The unit tests spend nearly half of their run time resetting the user table for
each test. But the majority of tests do not depend on the user table having the
exact value that the setup code resets it to, and do not need to modify the
user objects they require to run.
Fix that by providing an API for tests to get User objects, and to indicate
whether the User object will be subject to destructive modification or not.
This allows User objects to be reused across multiple unit tests.
Change-Id: I17ef1f519759c5e7796c259282afe730ef722e96
This reduces the runtime of database-bound tests by about 40%
(on my system, from 4:55 to 2:47; results from Jenkins are
inconclusive).
The basic idea is to call addCoreDBData() only once, and have
a addDBDataOnce() that is called once per test class, not for
every test method lie addDBData() is. Most tests could be
trivially be changed to implement addDBDataOnce() instead of
addDBData(). The ones for which this did not work immediately
were left out for now. A closer look at the tests that still
implement addDBData() may reveal additional potential for
improvement.
TODO: Once this is merged, try to change addDBData() to
addDBDataOnce() where possible in extensions.
Change-Id: Iec4ed4c8419fb4ad87e6710de808863ede9998b7
* New class ApiMergeHistory handles action=mergehistory
* Merge History functionality moved from SpecialMergeHistory to
MergeHistory
* SpecialMergeHistory now uses MergeHistory for actual merging
* Unit tests and i18n messages for above
Bug: T69742
Change-Id: Ic5078307dae78a2b3687e34a5d0a584988d483a1
