* Inject dependencies from the constructor and use those instead.
* Make getSystemInfo() static since its sole purpose is to collect
global state. This also means it can be safely called from the
Installer without needing to construct this class and its unsafe
dependencies as the Installer was doing previously.
* Remove private 'id' member. This cached the fetchOrInsertId()
return value but was never used.
* Remove selectField() fallback IGNORE-mode insert from fetchOrInsertId().
This existed to handle concurrent writes, but this isn't possible
since all this runs inside a DB_MASTER lock.
* Add missing call to $cache->makeKey().
Avoid passing unformatted strings directly to BagOStuff methods.
Bug: T270540
Change-Id: I984526020ea4d5f0fd6f72b6be527edaf6ab0917
This patch implements the BanConverter class for Balinese. Its purpose is to transliterate Balinese in Balinese script to Latin script. Latin to Balinese is not currently supported, because (1) the Latin transliteration is not fully one-to-one, (2) I'm not aware of any users who currently need Latin to Balinese.
The converter supports three distinct Latin transliteration variants: ban-dharma, ban-palmleaf, and ban-puri-kauhan-ubud. All three variants have been requested by different Balinese community members working with Balinese palm-leaf manuscripts. ban-puri-kauhan-ubud is the default, as it is the most familiar to lontar scholars, but Balinese Wikisource users will be able to select their preferred variant via a user script.
Conversion is accomplished via ICU Rule-Based Transliterators, bindings for which are available through the Intl extension.
This patchset adds the abstract class LanguageConverterIcu and has BanConverter inherit from it (makes future ICU-based LanguageConverters easier).
Bug: T263082
Change-Id: Ic3a46a215fbf020a022726e6b130b1d25496e284
The InterwikiLoadPrefix hook isn't compatible with Parsoid, as it is
unidirectional and doesn't support enumerating all valid prefixes
(T270444). Set/reset $wgInterwikiCache to mock the interwiki table
for parserTests and other unit tests instead.
This is a soft deprecation, as the used-in-production
Extension:Interwiki still uses InterwikiLoadPrefix, although not in a
way that would break Parsoid (since $wgInterwikiCache is set in
production).
Bug: T270444
Change-Id: If2507017c99c4ee42c104a0890bc45a84d7239d5
Needs to call parent::tearDown() after the table reset.
Use direct assertion and MediaWikiTestCase abstraction
where possible
Change-Id: Iad00569867e6f9a4579ae93b22fc0f570cde6bd7
Deprecated since 1.35, not compatible with PHPUnit 8. This could've
happened earlier, but here we go.
Unused in known repos (except for the sniff looking for this usage):
https://codesearch.wmcloud.org/search/?q=assertType%5C(&i=nope&files=php&repos=
Bug: T192167
Change-Id: I479cf71d0941c35096d21686077b4d1cbc4f898d
The problem was that when using $user->getBlock
within checkCondition (APCOND_BLOCKED) caused a infinite
recursion as calling getBlock eventually leads back to checkCondition.
The fix here is to stop using userHasRight as that is the cause of the recursion.
This also fixes testGetUserAutopromoteBlockedDoesNotRecurse test so it
shouldn't fail.
Bug: T270145
Change-Id: Ic751eba70730de286bbd55772bd7562459fb30b4
Emit deprecation notices in the constructor
if falling back to $wgUser, and fix core
calls
Bug: T246861
Depends-On: I51117931d527a3bdda468b48de577a7faafbcd69
Change-Id: Ibd0a8ffd0494c17a378cc43e6b6164166130adf4
If I try to run ApiMainTest with GlobalPreferences enabled, it takes
forever (or at least some number of minutes) to run. This is because
when @depends is used to transfer data from one test to another via
the return value, PHPUnit runs Enumerator::enumerate() on the data. When
it contains a reference to the active TestCase, PHPUnit ends up
iterating through its internal data structures, which takes a long time.
My conclusion is that @depends with a return value should be considered
harmful. Stop doing it in ApiMainTest. Stop recommending it in
SampleTest.
Change-Id: I63e94f2886a4ee4b3fd0ea6b19cd2fb67ba912de
Some User methods fail if they are called before $wgRequest is
set. But according to the Setup.php comment, it is only set for b/c.
The global request object can be lazy-initialised at any time.
This is sufficient to avoid T263911 (loss/obfuscation of the $wgServer
error message).
In tests, try to keep $wgRequest and RequestContext::$request in sync.
Introduce MediaWikiIntegrationTestCase::setRequest() which sets both at
once, and use that instead of setMwGlobals() or direct assignment.
BlockManagerTest was accidentally exploiting the fact that the global
context request and $wgRequest were separate objects. Making them the
same causes session cookies to appear in the response, breaking the
cookie counts. Use a new response for the test.
Bug: T263911
Bug: T245940
Change-Id: I2be99f7251a837bc6b62be0b152038157dec10f2
Not all classes are matched correctly in feed output because of
regex used. Fixed it by updating regex and adding unit tests
Bug: T36801
Change-Id: I6e7a883caee2a36c11966991b19ba93c229683cf
This patch adds a method named WikiPage::doUserEditContent() as an interim
replacement to existing deprecated ::doEditContent() method. The new
method requires $user to be passed as a parameter and no longer supports
passing in the unused $serialFormat parameter. The new method otherwise
behaves identically compared to the old doEditContent() method.
Bug: T255507
Change-Id: Ibc0052b27a6d3cda3eb9663b95b4f45116dcc9f1
Previously, the order of styles outputted by this module was
arbitrary, based on the order of the feature files passed in.
This was not how it was intended to work - the ResourceLoaderSkinModule
should be aware of the correct ordering.
In the case of normalize for example - it should always be the first
file output.
The implementation is adapted to check for valid features once in
the constructor and to also consider a DEFAULT_FEATURES value has been
set.
We use the FEATURE_FILES constant to determine
the order of CSS output.
This is all documented in the class.
Bug: T269618
Change-Id: Iecbf11b5f09882e55d694651210d6d132d3cd412
This replaces the 'requirements' from parser tests (hooks and
functionhooks) with a more flexible 'options' clause to allow
additional file-level requirements/options to support running parser
tests in multiple modes. (For example, with the legacy parser or in
one of two parsoid modes.)
Bug: T254181
Depends-On: I636bd1f2c8aee327acbbd1636e2ac76355f1d80e
Change-Id: I58373d135c3a804f4ce9967112c338435f5cd4b6
Several important extensions (Disambiguator, ProofreadPage, and
SoftRedirector) use the GetLinkColours hook to add additional CSS
classes to links on article pages. Parsoid previously relied on
backdoor knowledge of the way Disambiguator used the page property
table to support these, but they should be exported properly from the
API.
Bug: T237538
Change-Id: I945940aa872541d7e01f1e543ca854231c857fe2
Should be a no-op, doesn't actually reduce the places where $wgUser
is set, just reduces the number of hits in codesearch and makes the
future migration of LanguageConverter to not use $wgUser a bit
easier
Bug: T243708
Change-Id: Ieb04b0e760dd37e037a95408ef429ac5c510f1d9
