Ever since 184658eb32, the output of a non-existing message will be
HTML safe, regardless of output format, so we can treat non-existing messages
exactly the same as messages that do exist.
The pre-existing "int keyword - non-existing message" parser test verifies
that no change in output has ocurred in this patch.
Change-Id: I0e32be14f1b420d7f222ac3c76e1cc266f912b69
The getConverterLanguage() method was added in March 2012 in commit
561424c266 as a workaround for a regression
in mediawiki 1.19. It was an indirection which checked the global variable
$wgBug34832TransitionalRollback to return a different converter language
for Chinese wikis.
When this temporary bugfix was reverted in January 2013 in commit
a3fbdaaa2c, the temporary global variable
was removed, but not the getConverterLanguage() indirection. Since then,
new code in the parser seems to have faithfully used getConverterLanguage()
instead of getTargetLanguage(), even though they are identical and the
need for getConverterLanguage() has long since passed.
Strike a small blow for elegant minimalism by removing the completely
unnecessary Parser::getConverterLanguage() indirection. Well, sort
of: since this blight has been slowly growing inside Parser.php for
so long, we need to deprecate getConverterLanguage() first just in
case any external dependency has been infected. Next release we
can finally excise the unnecessary method.
Change-Id: I567c29c9c7699020955699b76cbe8578d02e2fe6
$length is user input, so cast it to an int before passing it to min().
If there is nothing to add at that point, return immediately.
In PHP 7.1+ this raised a warning of "A non-numeric value encountered"
because min() will return the junk value, returning a string. Then we
try and subtract an int from it (return value of mb_strlen()),
triggering the warning.
Added a parser test to verify the behavior, and confirmed that it
triggers warnings without the patch.
Bug: T180403
Change-Id: I614750962104f6251a864519035366ac9798fc0f
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
https://secure.php.net/manual/en/function.implode.php defines the order
of arguments as
string implode ( string $glue , array $pieces )
string implode ( array $pieces )
Note:
implode() can, for historical reasons, accept its parameters in
either order. For consistency with explode(), however, it may be less
confusing to use the documented order of arguments.
Change-Id: I03bf5712204e283f52d3ede54af9b9ec117d4280
Used by the `setWidths` and `setHeights` methods to make sure we are
using correct values.
Makes `parseWidthParam` static to be used in the gallery class.
Bug: T129372
Change-Id: I38b9ef0ea26e3748ad5d5458fadd2545f677ef93
This ensures that if GENDER is fed wfEscapeWikitext()'d version
of a username, it will normalize it.
See discussion on T182800.
Note, we do not need to worry about the case of a user named
"Project:*foo" as such namespace prefixes are illegal in
usernames.
Change-Id: Ic5a8fc76c28dca43ce8e334ef1874c2673433f00
Stub objects are confusing as heck and are a performance optimization
that really aren't fit for the modern era. They were designed to avoid
loading the actual code from the disk back in the days when bytecode
caching wasn't always gonna be there.
It's 2017. If you're using HHVM, you've got a bytecode cache. If you're
using any reasonably recent version of PHP then you've got the opcode
caching enabled by default in basically every distro-related build.
Nothing actually relies on this object being a stub (that'd be silly),
so only references are basically things force unstubbing (also kind of
silly) the object. Once remaining code referencing this in extensions
are all cleaned up then we can remove the class itself.
Change-Id: I15df24aeeb729e8e764792daa933377f35042fab
It's unreasonable to expect newbies to know that "bug 12345" means "Task T14345"
except where it doesn't, so let's just standardise on the real numbers.
Change-Id: I6f59febaf8fc96e80f8cfc11f4356283f461142a
Apparently it is possible for Parser::mParserOptions
to not be set in some cases. I'll try again later.
This reverts commit bda74bff6e.
Bug: T146433
Change-Id: Idb6d1b20995d5f86b712abb386ab987356c4f560
wfEscapeWikiText() used $wgEnableMagicLinks, but that could result in an
inconsistency when something modifies the magic link related
ParserOptions.
In general, most uses of wfEscapeWikiText() are in parser functions or
when message parsing, so the Parser is a logical place for it.
A future patch will make it easy to use Parser::escapeWikitext() in
message parameters.
Change-Id: I0fd4d5c135541971b1384a20328f1302b03d715f
Revision::getSize() might return null when the revision.rev_len field
is null. That should never happen normally (the field should get
backfilled as part of the update process), but we've also had a bug
where rev_len was not being recorded for empty pages (see T135414 for
details). It's saner to return a number here rather than empty string,
and 0 should actually be correct for all pages affected by that issue.
Bug: T20998
Change-Id: Ie12f0be24f00aaf8b90b25c4921a97df3b789369
Ignored restricted DISPLAYTITLE warning isn't really relevant for the casual reader
so don't show it in the page output. Instead show it above the edit box.
Bug: T135949
Change-Id: I009dd865bec7b6e3a7492c49db97074483f93ee4
Added to "Pages with ignored display titles" category
(message key: "restricted-displaytitle-ignored")
Follow up to I6ae6d5d0e567ba9c86e46c32240ee51a2ca5d8d1
Bug: T135949
Change-Id: I9e0f8b1e3d39a62c13191bea6734fb136e976e0c
If a page contains a call to DISPLAYTITLE that is ignored because of
$wgRestrictDisplayTitle, output a warning.
Bug: 26546
Change-Id: I6ae6d5d0e567ba9c86e46c32240ee51a2ca5d8d1
This adds a magic word to get the protection expiry for a page for a
given action.
Usage is {{PROTECTIONEXPIRY:action}}.
Bug: T19354
Change-Id: Ia1a20e313781789480dc082bdc7f585c4f0e28df
This doesn't fix all the files under includes/parser -
some of them deserve their own patches.
Bug: T102614
Change-Id: I2fcbc19ee337e1b7db4635b5e5f324c651b4d144
* Urlencode and extension tags don't play nice. The current behaviour
is pretty broken. For example,
{{urlencode:<pre id="one">two</pre>}}
outputs
<pre id="one">two</pre>
which isn't exactly urlencoded.
* Just drop the unexpanded content; anything more seems unsafe. There's
precedent for this already in anchorencode.
* Noticed in the infobox caption for enwiki/%22F%22_Is_for_Fugitive
Change-Id: I0ec5d2fdeb71f762036464f65029afd029e8b4a1
Xhprof generates this data now. Custom profiling of various
sub-function units are kept.
Calls to profiler represented about 3% of page execution
time on Special:BlankPage (1.5% in/out); after this change
it's down to about 0.98% of page execution time.
Change-Id: Id9a1dc9d8f80bbd52e42226b724a1e1213d07af7
When #tag is given a tag that it doesn't recognize, re-emit it as a
regular tag instead of giving an error. This allows for it to be used with
transparent tags and HTML tags.
Change-Id: I0ceee8a4fdaf2d3142054a108f445ff06597c31a
