Implicitly marking parameter $... as nullable is deprecated in php8.4,
the explicit nullable type must be used instead
Created with autofix from Ide15839e98a6229c22584d1c1c88c690982e1d7a
Break one long line in SpecialPage.php
Bug: T376276
Change-Id: I807257b2ba1ab2744ab74d9572c9c3d3ac2a968e
For decades MediaWiki has allowed "extra" px modifiers in image size
specifications, for example `100pxpx`. It has been suggested since at least
2008 (T15500#174968) that this behavior should be deprecated. This is
not localized, so (for example) on eowiki we allow `100rapx` as well (!).
As one small step toward eventually removing this weird corner case behavior
add a tracking category whenever it is used on wiki.
In the process, emit deprecation warnings for
ImageGalleryBase::setWidths() or ::setHeights() if called without
ImageGalleryBase::setParser() having been set. The ::setParser() method
already includes in its documentation that "If you do not set this and
the output of this gallery ends up in parser cache, the javascript will
break!", so please set the parser appropriately.
Bug: T15436
Bug: T15500
Bug: T372935
Change-Id: If86d949189a7d105595404d21447477499873b03
Add the same no-arg options for language code that
{{#dir}} and {{#bcp47}} have, for consistency:
* `{{#language}}` will return the name of the *target language*
(for articles, the content language; for messages, the user language)
The default value for the "in language" argument should be the autonym.
This was working previously but only via a baroque code flow path for
invalid language codes. Make this a bit clearer and add tests.
Since non-autonym language code translations are added via the
[[Extension:CLDR]] in production, hook LanguageGetTranslatedLanguageNames
in the ParserTestRunner to ensure that we can test this.
Followup-To: Ice1c671c5b3cc077d2bb80ea5dc25c5eabbfeb36
Followup-To: I19c3e91a924e080f37dc95a0d4e61493583b533e
Change-Id: Ibf6e7f194cc056eadb48a5ad8e6d01a761d9351c
Template:Bcp47 is one of the most used templates in Wikimedia Commons.
Providing its functionality as a parser function, tied to MediaWiki's
language-handling code, reduces code duplication and will allow us to
reduce template usage on commons.
As with the {{#dir}} parser function, support one special case:
* `{{#bcp47}}` will return the BCP-47 code of the *target language*
(for articles, the content language; for messages, the user language)
Note the following slight differences from [[Template:BCP47]] on Commons,
documented in an added parser test:
* 'simple' maps to 'en-simple' (not just 'en')
* 'roa-tara' maps to 'nap-x-tara' (not 'it-x-tara')
Bug: T366623
Change-Id: Ice1c671c5b3cc077d2bb80ea5dc25c5eabbfeb36
Template:Dir is one of the most used templates in Wikimedia Commons,
this tries to provide parts of its functionality in hope we can
perhaps simplify or get rid of the template eventually for clarity and
performance reasons.
As a convenience, `{{#dir}}` and `{{#dir:}}` are synonyms for
`{{#dir:{{PAGELANGUAGE}}}}`: they return the direction of the target
language. For articles, the target language is the content language;
for messages, the target language is the user language.
In addition, to avoid confusion between BCP-47 language codes and
MediaWiki-internal language codes, an optional second parameter can be
supplied. If the second parameter is the (localizable) string
'bcp47', the language code given in the first parameter will be
treated as a BCP-47 code. For example: `{{#dir:sr-Cyrl|bcp47}}`.
(See LanguageCode::bcp47ToInternal() for a description of the
differences and overlaps between MediaWiki internal and BCP-47
codes. These overlaps *so far* don't result in any case where
encouraging editors to be precise about which set of enumerated
string values they are using for consistency with other
language-related functions, and because MediaWiki internally
differentiates between BCP-47 codes and internal codes.)
Bug: T359761
Change-Id: I19c3e91a924e080f37dc95a0d4e61493583b533e
Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: Ia35b2d3105880631dd26ec974068b000ac7f4b6b
Handle them as invalid pages and return 0.
Do the same for revision... parser functions.
These parser function would add the interwiki link target to
ParserOutput::addTemplate and get stored (without the interwiki prefix)
in the templatelinks table, which is wrong. Just keep them out and
handle them as invalid.
Bug: T355706
Change-Id: Ife799789ff5e5953471a28ce37f4dfa7f763299e
StubUserLang was meant to avoid the cost of looking up the user
preferences on requests which don't need it. There's no point in using
it if you are going to unconditionally call a method on the resulting
object.
StubUserLang proxies to RequestContext::getLanguage() via __call(),
which has a cost. Originally this cost was avoided on subsequent calls
by overwriting $wgLang, but this mechanism is not effective if you retain
a reference to the StubUserLang.
Removing the potential for Title::getPageLanguage() to return
StubUserLang simplifies the type declarations for methods that call it.
Bug: T160814
Change-Id: I12ad75c2496ca727580aac55e860178d15febb6e
It's going to be a bit small and narrow but it's better than sitting in
the root of includes/ plus I hope we can hollow out SiteStatsUpdate
class into the third one and or move this under a better directory in
the future.
Bug: T321882
Change-Id: Ia503b53b31ca00600f8c18b61a2652c3e146494e
This patch aims to fix T320338#8334752, any message parsing that
happened when (pre)viewing a page should use the actual timestamp of
the last saved revision. The title is the same as the current page
only for context.
For the case reported in T320338#8334752, edit notice should indicate
the time since the last edit properly.
Bug: T320338
Change-Id: I2a5d44087e74efa4a7e2bb1b75036506e8e3823a
Using a standard wfMessage(...)->escaped() in the context of a parser
function or tag hook is wrong, because it'll use the current user's
language and pollute the cache. In reviewing MediaWiki extensions a
lot of them do this wrong.
This provides a helper to make it more likely that folks will get this
right.
Bug: T202481
Change-Id: Ic6dfd111c173b97a959c27e18fa83cc572326fa6
The motivation is to make the code less confusing. I hope this is the
case.
?? is an older PHP 7.0 feature.
??= was added in PHP 7.4, which we can finally use.
Change-Id: Id807affa52bd1151a74c064623b41d950a389560
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
The second parameter to userAdjust() should be supplied with empty
string, which tells it to use the site-default timezone offset
instead of the user settings.
See also the $parser->getRevisionTimestamp() and another use of
userAdjust() above.
Bug: T320338
Change-Id: I05fc1e00f2b954ad04141072967b09ebec146f3e
This patch only adds and removes suppressions, which must be done in the
same patch as the version bump.
Bug: T298571
Change-Id: I4044d4d9ce82b3dae7ba0af85bf04f22cb1dd347
Reduce code duplication by having the "magic variable" implementation
of `revisionid` invoke the corresponding "parser function"
implementation with no arguments. This reduces code duplication and
also supports consistent results from direct invocation of the parser
function with no arguments in the future.
Bug: T204370
Change-Id: I2dc4799559f440511b4584a73513c17d5b0f1ff0
Reduce code duplication by having the "magic variable" implementation
of `revisionuser` invoke the corresponding "parser function"
implementation with no arguments. This reduces code duplication and
also supports consistent results from direct invocation of the parser
function with no arguments in the future.
Bug: T204370
Change-Id: I4200e4f05a8987b509349832d6d0b164acbe0dd8
Eliminate a difference between the magic variable (no-arg) and
parser function (1-arg) forms; aka the difference between
{REVISIONTIMESTAMP}} and {{REVISIONTIMESTAMP:{{PAGENAME}}}}.
This is a follow up to I8d25755e4d92bd91988cfb706d85bdb170abb207.
The magic variable contains a MAX_TTS optimisation which reduces
the use of vary-revision-timestamp, since it has severe performance
implications; this patch applies the same optimisation to the
parser function.
The ParserTestRunner has a small issue with test setup:
ParserOptions::setTimestamp() was called with a unix-format timestamp,
where it expected a TS_MW format timestamp. This issue was
fixed, along with tweaking the test timestamps so that a timestamp
coming from ParserOptions would still be distinguishable from one
coming from the revision.
Bug: T204370
Change-Id: I883d42d67013b6fb0da57c61e715b51d3a807879
Reduce code duplication by having the "magic variable" implementations
of:
revisionday, revisionday2, revisionmonth, revisionmonth1,
revisionyear, revisiontimestamp
invoke the corresponding "parser function" implementations with no
arguments. This reduces code duplication and also supports consistent
results from direct invocation of the parser function with no
arguments in the future.
Bug: T204370
Change-Id: I8d25755e4d92bd91988cfb706d85bdb170abb207
The following magic variables also have "parser function" forms, where
the first argument is a user-supplied title:
pagename, pagenamee, fullpagename, fullpagenamee, subpagename,
subpagenamee, rootpagename, rootpagenamee, basepagename,
basepagenamee, talkpagename, talkpagenamee, subjectpagename,
subjectpagenamee, pageid, cascadingsources, namespace, namespacee,
namespacenumber, talkspace, talkspacee, subjectspace, subjectspacee
Refactor the code so that the magic variable form invokes the parser
function form with no arguments to reduce code duplication. We also
tweak the behavior of parser function when invoked with no arguments,
although this change will not be directly visible because the parser
always prefers magic variables over parser functions, so the parser
function is never actually invoked with no arguments.
A future patch may allow the parser function to be invoked with a
hash prefix (I895087c546dc820c77c0dda596dfeb72586b87cc) in which case
consistency will be more important.
Note that `revisionuser`, `revisionid`, `revisionday`, `revisionday2`,
`revisionmonth`, `revisionmonth1`, `revisionyear` and
`revisiontimestamp` are also of a similar form and could be included
in this list, but their magic variable and parser function
implementations do not appear to be consistent. This will be
addressed in future patches.
In addition, the following magic variables have a "parser function" form
where the presence or absence of the first argument selects "raw" output:
numberofarticles, numberoffiles, numberofusers, numberofactiveusers,
numberofpages, numberofadmins, numberofedits
Similar to above, refactor the code so that the magic variable form
invokes the parser function form with no arguments to reduce code
duplication (and to support future direct invocation of the parser
function with no arguments).
Bug: T204370
Change-Id: Iaec33fb40a2d9884daf2852ed6a6a3b53c9d3863
The check is only relevant when calling Title::getTalkPage/getTalkNsText
Check exists since the addtion of the functions in a4fafb0
Bug: T317582
Change-Id: I2e36fd963b2f943ed67a93c2573008b2d1fb094b
* This patch relies on extensions setting a flag in their Parsoid ext.
config indicating that a specific tag handler needs nowikis stripped
from #tag arguments.
In the #tag parser function implementation, Parsoid's SiteConfig is
looked up to see if nowiki needs to be stripped.
* This need not be limited to nowikis, but to support extension use in
{{#tag:ext|...}} more generally, we would need to either
(a) implement the #tag parser function in Parsoid natively; OR
(b) find a way to call Parsoid from extensionSubstitution
Soln (a) needs Parsoid to support parser functions natively.
If this general support becomes necessary, a later patch can
generalize this appropriately.
Bug: T272939
Bug: T299103
Depends-On: I6a653889afd42fefb61daefd8ac842107dce8759
Depends-On: I56043e0cb7d355a3f0d08e429bb1dbba6acb4fba
Change-Id: I614153af67b5a14f33b7dfc04bd00dd9e03557d0
This corresponds to the `namespace` parser function, but between PHP 5.3
and PHP 7, `namespace` was a reserved name that couldn't be used as a
function name. It was made "semi-reserved" by the PHP 7 context-sensitive
lexer, and MW currently requires PHP >= 7.3.19.
Change-Id: If8a1401c38b9140bb40a3381845a0d115546422a
PHP 8.1 doesn't like passing nulls around, and in context the empty
string makes more sense anyways as the default value for unspecified
options.
Bug: T313663
Bug: T313662
Change-Id: Ica9460716129481f9cb1ebff3b660d2d1bb15f55
Now largely automated:
VARS=$(grep -o "'[A-Za-z0-9_]*'" includes/MainConfigNames.php | \
tr "\n" '|' | sed "s/|$/\n/;s/'//g")
sed -i -E "s/'($VARS)'/MainConfigNames::\1/g" \
$(grep -ERIl "'($VARS)'" includes/)
Then git add -p with lots of error-prone manual checking. Then
semi-manually add all the necessary "use" lines:
vim $(grep -L 'use MediaWiki\\MainConfigNames;' \
$(git diff --cached --name-only --diff-filter=M HEAD^))
I didn't bother fixing lines that were over 100 characters unless they
were over 120 and triggered phpcs.
Bug: T305805
Change-Id: I74e0ab511abecb276717ad4276a124760a268147
