Something is going wrong with the way we use WANObjectCache in
getBlobBatch. This patch introduces a test case that should help narrow
down the cause.
Bug: T235188
Change-Id: I2d06c09609874440992e6c90d3ebfa15400ac302
Handler to return page history via the Core REST API.
Includes two parameters for pagination:
older_than
newer_than
Also includes a "filter" parameter with possible values:
bot
anonymous
reverted
Bug: T231558
Bug: T231597
Change-Id: Ie35d8be6c96b468794f8acf80a5fb50e4cd17c3c
This was previously removed because Special:Contributions could not show
contributions from IP ranges. It now does.
Bug: T233082
Change-Id: I2ec45807ca515a83309e8dbecce53840951e2d5f
Normally there shouldn't be more than one Language object in existence
at a time because of $mLangObjCache, so there's no need for a
MapCacheLRU for grammar transformations. Just make it an instance member
of Language.
If someone directly called the Language constructor instead of
factory(), or meddled with $mLangObjCache, with one of the three
languages that have transforms defined, and called
getGrammarTransformations() on both distinct objects, this change could
result in duplication of an array of about 50 elements. I think the risk
is acceptable.
The change should be covered acceptably by existing tests for LanguageHe
and LanguageRu. (There's not much to test.)
Bug: T201405
Change-Id: I483bafbbb7d109b670596f16381def9e3bd26d89
This replaces the static Language methods getFallbackFor(),
getFallbacksFor(), and getFallbacksIncludingSiteLanguage(). There is
100% unit and integration test coverage for the new class.
One deliberate functional change: I changed one place where we threw
MWException to InvalidArgumentException.
Bug: T201405
Depends-On: Ie7a89f6ed7d52a0bc01672019ff92e7ee105a1f3
Change-Id: I49222eb55f1feec5b1dcd40f364cffe0c8801855
In commit 5940aa6344 in 2008 (SVN r35745),
these were accidentally changed from U+F011 (a private use area character)
to U+0011 (a control character). The control characters are certainly
incorrect, as they can't even be used in MediaWiki page titles. Having
a private use area character here is surprising to me, but it was
apparently used since 2006 as a substitute for U+A657, which was only
introduced in Unicode 5.1 in April 2008, hence the aliases.
I noticed this problem when I was doing some work analyzing MediaWiki's
date formats, and my editor warned me that this is a "binary file" :)
Change-Id: I5df29b0072d6dec8dcb8c7492d8b9623c93fdbf3
The previous code to allow relative paths (via "path": true) was
limited to only string values, which led to needing a non-static
registration callback function.
Bug: T231855
Change-Id: I4e82f38627f2f0d50d8b05a8c02b5a35342f6526
forcelinkupdate and forcerecursivelinkupdate are not limited to links
updates – content handlers can register arbitrary other secondary data
updates to perform.
(Both parameters also immediately update the parser cache for the
canonical parser options, but this does not seem worth mentioning.)
Change-Id: I5f3c8d1c22a08fee816121374620f207698c2715
