As a first step in a plan to reduce redundancy in OutputPage, replace
the $mIndexPolicy property of OutputPage with the corresponding
getter/setter methods in a ParserOutput held for the purpose of
storing metadata.
Bug: T301020
Change-Id: I6073f4033be936b669532ecf8104a8e5ff498e24
Why:
To facilitate the evaluation of conditions not directly
"known" by the lookup, eg: owned by extensions
What:
- Add ConditionalDefaultOptionsAddCondition hook which
runs before instantiating ConditionalDefaultsLookup allowing
to add conditions for evaluation in the $extraConditions
array.
- Evaluate the configured conditional default against the
extra added conditions after evaluation of "known"
conditions.
Bug: T376918
Change-Id: Ife6f96397eafd61fdb40528aac315ddde1ef2774
The upcoming Multiblocks project will make use of a Pinia store, which
is already shipped in MediaWiki via ResourceLoader. In order to continue
to test Vue components that make use of a store, we need the Pinia
testing utilities.
The 'pinia' package is locked to the same version that's in RL, 2.0.16,
while '@pinia/testing' is locked at 0.0.12, the same version used by
some extensions such as GrowthExperiments.
Bug: T251790
Change-Id: Ia88d987bf7e5afa1a17d63b4ebc96448ccec2f6c
processForm, parseExpiryInput and canBlockEmail are deprecated since
1.36.
getSuggestedDurations is deprecated since 1.42.
Depends-On: I5931525f95ff6eb76a2b30aa7a852cc86075276f
Depends-On: I6a570e503fee6676e7c54beb6f37575058a57339
Depends-On: I6890763dbe30cc33b2715e93c59cee331d8967b1
Depends-On: I99f49dd3f20032848cc7a191a6b46c5816f3bff2
Change-Id: Ibbf51d9de168d97c0ed3c827f02a356c8a579987
This was deprecated in 1.42 but did not previously emit deprecation
warnings.
Depends-On: I072b111b047cfe13e32a822678d68165d1c76f84
Depends-On: I2734383207b92f71bffc66ba2392a592a1df0954
Depends-On: I79bb5030c13e83f664da1635254f4bc171ed4f3e
Depends-On: If64a5239a40953f244657e60f95b2e938abfe447
Change-Id: Ifefd3dab43247d988b7c7ff7874c05c90fc8ce1f
This doesn't seem to be used anywhere except the tests and the
better API is to use $formatter->createBatch() API that
doesn't expose 'ugly boolean parameters' as described by
formatInternal method above so let's remove it.
https://codesearch.wmcloud.org/search/?q=formatStringsAsBlock
Change-Id: Ia7428f5dbdf6c76b7537ae3889aef077bb26c722
So far I've only seen very limited correct use of getDirMark
outside HTML which one was for the {{DIRMARK}} magic word,
majority of other uses were replaceable with actual HTML markup
so let's use soft deprecation to signal third party developers
they also can go through the same way and use HTML markup
instead of hidden control characters. In future if the magicword
was the only valid use of this we can just hard code this there
and hard deprecate and eventually remove this and if it had more
uses that made sense to keep this around we can undeprecate it.
Bug: T375975
Change-Id: Ie9b78102d58e81fbc6cb22fb85da4962ee2c70b5
In HTML context the recommendation is to use <bdi> HTML tag
instead of adding a hidden character that eventually will
end up be in clipboard as described in T27277 also and this
is now unused so let's just mark this as deprecated.
There are some getDirMark() uses however that are in HTML
which should be replaced with appropiate HTML tag which
is unrelated to this deprecation anyway.
Bug: T375975
Change-Id: I5cc15ff00ade5795428c7897df23e4dbac6147a5
Use
$request->getRawVal( 'key' ) ?? 'default'
instead of
$request->getRawVal( 'key', 'default' )
The ?? is more flexible, avoids a wrong type detection by phan and
avoids the evaluation of the default value if not needed.
Bug: T376245
Depends-On: I3ed6b85c0d117ed7cb3a8b79f73a3eb42977891e
Change-Id: I8b02f9297b76d04e21f8cb9194f3b85631956eca
This is done experimentally, with only a Names.php entry and
namespace translations, before we have actual localized strings.
For details, see https://www.mediawiki.org/wiki/Future_of_Language_Incubation.
I've tested it on my local MediaWiki instance, and it works
as expected: no user interface translations, but the namespaces
appear corretly in page titles, Special:AllPages, etc.,
when `$wgLanguageCode = 'nr'` is set in LocalSettings.php,
and the language name appears correctly in the dropdown in the
"Internationalisation" section in the Preferences.
Bug: T375377
Change-Id: I44cf6a6dabf2ade873506a78573db4f7783a9c99
