And some more clean ups, like using buildComparison, avoiding
traditional join (using WHERE condition), etc.
Bug: T311866
Change-Id: I11e168101bba92afa4122984b37aac5ac247dd8b
* Generate data files for 1.40 only since the new formats only
showed up in 1.40 and won't be present in the parser cache
for older MW versions.
Change-Id: I6f297e3091ec2faab7c2203c138800551b01e32a
There's a few remaining for the following conditions are met:
1. The wiki has FlaggedRevs installed.
2. The URL is to a wikipage redirect.
3. The destination page uses FR and has unreviewed changes pending.
In this case, FlaggedRevs uses onInitializeArticleMaybeRedirect
and calls RequestContext::getActionName which is then invalidated
due to changing the Title/WikiPage/ContentHandler from which actions
are determined.
This will be fixed in FlaggedRevs soon, but for now silence it while
we take that on carefully.
Bug: T323254
Change-Id: If86476da7bc76be49bad0780dc63d2255080aaa2
Use a generic hypothetical size for more complex objects, relying more
so on the value of $elapsed. The time elapsed from miss till set
attempt, and, the key query rate, are the biggest determinants of
duplicate key set spikes.
Use 2 second TTLs for cool-off/interim keys given the +/- 1 second
precision of key expiration within memcached. 1 second TTL keys can
sometimes count as expired 1ms after the key set.
Bug: T321634
Change-Id: Ic60d3ba3b16cd60a49c467ac3e19ecf95c1f27c0
Not only is this intensive to compute (and could be an attack vector),
it's also quite pointless as it's derived from thumbnails, which in
turn are derived concepts for which the implementation may change.
AFAICT, none of the consumers of this API even use this data (so it's
inclusion is negatively affecting them by slowing response times down)
It's also not consistently available: for most of the thumbnails, this
data is usually null.
Bug: T323125
Depends-On: I20d5c4358e225be7759ed38afb2267d6f811fa34
Change-Id: I65435ded5e8bea57f3e23e7e790ac007821bbd67
While accessing a SettingsBuilder instance via global state should not
be encouraged, we still need it sometimes. So use a static getter
instead of a global variable. That way, we can emit deprecation warnings
when we have proper alternatives available.
Change-Id: I0013bdab474710fd521532dd2653b3789e2ede34
The hook was underspecified, $article was passed by reference
but it doesn't make any sense to change it and none of the existing
implementations do, so clarify in the docs that it shouldn't be
done and drop related logic. Also improve documentation in
general.
Bug: T323184
Bug: T323254
Change-Id: I53dfc7e29adcd21bb8b3ca7a1df6d88819099f3c
In 81f69c2, I have only removed the callers. The method is
now dead code and should have been removed as well.
Change-Id: I556ed5398435f4d3a5f400e07e4819dd16e0df06
Remove workarounds for the lack of proper autoloading for aliased
parameter type declarations which was fixed in PHP 7.4.
Change-Id: Ic4485d06e7ad8d02859dc3e5c67867c4b084386f
For postgres, work around the lack of implicit type casting for assignments
like "column=(SELECT ...)" within the SET clause of UPDATE statements. While
implicit casting applies to "INSERT...VALUES", it does not apply to INSERT,
nor UPDATE, when the rows are selected from a Common Table Expression defined
using VALUES(). Query the table schema and explicitly set the types in this
case.
Change-Id: I0affc3a794dd640c5fedf765a5058c38dc353471
This pattern is used a few times in MediaWiki core already, e.g. in
ApiQueryBase::select() or UserOptionsMaintenance::updateOptions(); let’s
document it for others. See also MediaWiki code search:
https://codesearch.wmcloud.org/search/?q=clone.*[qQ]uery[bB]uilder&files=%5C.php%24
Bug: T311866
Change-Id: I1c677d9fe57209f9eaab62e5bc2c43519ed53713
This is identical to Parser::getTargetLanguage() in modern MediaWiki,
since 7df3473cfe in MW 1.19 (2012).
Bug: T318860
Depends-On: If5fa696e27e84a3aa1343551d7482c933da0a9b6
Depends-On: I87a7ceedce173f6de4bb6722ffe594273c7b0359
Change-Id: Ieed03003095656e69b8e64ed307c6bd67c45c1e7
