Stringify the title instead. This will help avoid running into the
PHP/HHVM serialization incompatibility described in T210528.
This is part 2: Once all servers have part 1 (and rollback is unlikely)
we can stop storing the Title objects.
Bug: T210528
Change-Id: If3acfeb42788bd675c3022cc1b49dccc9ac1ecbe
Stringify the title instead. This will help avoid running into the
PHP/HHVM serialization incompatibility described in T210528.
This is part 1: start stringifying and using the string, but continue
storing the Title object for the benefit of mixed environments where
some servers still only handle a Title object.
Bug: T210528
Change-Id: I07aac3aab2d4e27a7203f4e4fb3ce1b5d86c517c
Instead of silently winding up with a bogus Message object having most
fields invalidly set to null, just throw an exception.
Bug: T210528
Change-Id: I79313f8acf3ebb1ef12dac30c362aa10c715f40b
Steps to reproduce:
Old:
> $msg = new Message( 'brackets' )
> print $msg->getTitle()
Error from line 478 of /.../includes/Message.php: Call to a member function equals() on boolean
New:
> $msg = new Message( 'brackets' )
> print $msg->getTitle()
MediaWiki:Brackets
This got broken in 796d62d0.
Change-Id: I52cde36787e348378c4df18d90aa577a5600e06b
This fixes 26 of the phan-taint-check warnings on MW core. Some
are outright fixed, others are false positives that were suppressed.
This really only covers some of the easy ones. There are still
314 warnings to go.
Change-Id: I30463bc3a09fd4324d190de8533f51784764dd3a
It looks like this parameter has had a default since it was first
created, and somehow kept it even after a new parameter was added
to the end. codesearch.wmflabs.org suggests, and I could not find,
and calls to this function from any other code that would need
the defaulted param (probably because they fail due to the later
required parameter).
Change-Id: Iae6e736c5c957d9fccb6ab5813a3b5b02eeb3f6f
And deprecate passing false for ParserOptions::setWrapOutputClass().
There are three cases for the Parser wrapper: the default
mw-parser-output, a custom wrapper, or no wrapper. As things currently
stand, we have to fragment the parser cache on each of these options,
which uses a nontrival amount of storage space (T167784).
Ideally we'd do all the wrapping as a post-cache transform, but
TemplateStyles needs to know the wrapper in use in order to properly
prefix its CSS rules (that's why we added the wrapper in the first
place). So, second best option is to make *un*wrapping be a post-cache
transform and make "custom wrapper" be uncacheable.
This patch does the first bit (unwrapping as a post-cache transform),
and a followup will do the second part once the deprecation process is
satisfied.
Bug: T181846
Change-Id: Iba16e78c41be992467101e7d83e9c3134765b101
We still set the state in many cases for benefit of extensions, but all
calls within core should no longer be using non-default state.
Change-Id: I78b62ec33fcb8273acb9b3b4e9012215442be94c
Depends-On: I140ff32373430b61b92226689ef9b58cca317450
If you used wfMessage( 'foo' )->rawParams( 'bar"baz' )
there's a possibility of leading to xss, if the foo
message has a $1 in an attribute, as the quote characters
may end the attribute.
To prevent that, we convert $1 to $'"1 for after parameters,
so if any of them end up in attributes, the attribute escaping
will break the parameter name, preventing substitution.
This would of course break if someone intentionally inserted
a raw parameter into an attribute, but that's silly and I
don't think we should allow that.
This is similar to the parser strip marker issue.
Bug: T176247
Change-Id: If83aec01b20e414f9c92be894f145d7df2974866
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
For some varargs a variable name is added with suffix ,... as seen for
many other varargs
Some @param are swapped, because there are in the wrong order
Enable Sniff MediaWiki.Commenting.FunctionComment.ParamNameNoMatch
Change-Id: I60fec6025bce824d5c67563ab7b65ad6cd628ad8
I2b686228 was a quick bandaid, but resulted in the error message not
actually reporting the incorrect list type.
Change-Id: I2b2bd6ee66a78fadb31b3524dfe04bf9e1f45535
Changes:
- uses int instead of number as param and return value type,
- uses stdClass instead of stdObject
- fixes ResourceLoaderClientHtml constructor's $target param type:
it is string|null, not an array (previously misspelled as "aray")
- changes the type of references to XML parser in XMP lib to resource
instead of not existing XMLParser
Change-Id: I98c363ebc6658d1f4dcabad97a9a92f3fcd7ea8c
Message::params() wants to take parameters either varargs-style or as a
single array. But it also detects "special" parameters like those
returned from Message::numParam() as an array of parameters instead of
as a single "special" parameter.
Bug: T152603
Change-Id: Idef2437470eee843a17ff23f4cefe8f3132988bd
This allows for passing a list of values that will be turned into a list
in the context of the language for which the Message is being processed.
For example, currently you'd have to do
$msg = new Message( 'something', [ $language->commaList( $list ) ] );
which isn't going to give correct results if the message is later
changed to a different language with a different value for
'comma-separator'.
Now, you can do this instead
$msg = new Message( 'something', [ Message::listParam( $list, 'comma' ) ] );
and it will be listified properly no matter what language is later used to
parse $msg.
Change-Id: I66868c61832260870449998fef14c842f17753ee
If a Message object is a parameter of another Message object, it should
use the same language, use-database flag, and so on as the outer Message
when it's being stringified.
Change-Id: I92762a1a63c90a16e8581edc96bd1da699880157
Message::__toString() used the same formatting mode that the last
explicit transformation used:
$msg = new Message( 'foo' );
echo $msg; // escaped
echo $msg->plain();
echo $msg; // not escaped
This is not particularly useful and makes code review hard, so let's
get rid of it.
The same behavior with $msg->toString() is left intact (and logged)
for now.
Bug: T146416
Change-Id: Ia9b2a1dcf09d52348b2c6d8299fd849b809f6e74
Message formatting methods have a side effect on how string conversion
will work, which is a security problem waiting to happen:
$msg = new Message( 'foo' );
echo $msg; // parsed
echo $msg->plain();
echo $msg; // not parsed
This change logs Message -> string transformations which are
affected by a prior call in this way. The behavior will be removed
in a later patch (possibly replaced by something more explicit
if it turns out that something depends on it).
Bug: T146416
Change-Id: Id51cf6a5a937bc41a914f317e980ef42e4d385fb
If you have a non-existent message in the output, chances are its
user-controlled. If the message has the ->plain() or ->text()
format, the output used to be not safe for html. Obviously people
should not be using those format types where html is being outputted,
but sometimes that happens. I think we should prioritize always being
safe over the fallback content not potentially being double escaped.
Additionally switch the enclosing brackets to be fancy unicode
characters, to sidestep the escaping issue on the enclosing brackets.
So previously, wfMessage( 'script>alert(1)</script' )->text() would
have outputted <script>alert(1)</script>. Now it outputs
⧼script>alert(1)</script⧽. No sane message key will include
< or >, so this would really only come up if the user can control
the message key name.
This goes somewhat against T68199.
Change-Id: Ic8a60892b8e847e6021494c10968814aac391731
Instead of constructing a new Message from the Message as
a MessageSpecifier, just clone the existing Message which will preserve
subclass data.
Also, make use of this to simplify the logic in ApiBase::parseMsg().
Change-Id: I9545acb8da752c0c21e16d8b1d37d8802fcb329d
This can happen e.g. when something processes Status contents
and expects [$key, $param1, ...] and instead gets [$messageObject]
Change-Id: I346b35e08bd38ce231e16d0616438ea408b55bff
Improves Ida647973a which unified message handling for form fields
but did not make the functionality available to HTMLForm itself.
Change-Id: I2e6195ba13afbd8b993acb47409fab1be91c547e
This cuts the $wgLang and StubUserLang which is a bit cleaner.
It also makes it more reliable when load.php sets its
RequestContext user interface language.
Bug: T127920
Change-Id: I05302feb9b3ce9e4c29541e07a4260effc4b55b2
If the serialization is happening during PHP shutdown due to a Session
save, it can fatal because $wgLang is already gone.
Change-Id: I7d877be15ef8639f3b94b74bba763053ec289358
This allows them to be stored in the session, for example.
Note that properly serializing a Message requires that all its
parameters be serializable as well; we don't attempt to account for that
here.
Change-Id: I3a42a2a883e8eef900eeb02355fc3b064411f642
Some special pages or actions have a link for users with editinterface
rights to edit the message used in scroll down menu.
When the message is parsed for the scroll down menu the config
$wgForceUIMsgAsContentMsg is used, but that was not used for the edit
link.
Add a new function Message::getTitle and use it in all places in core.
Most benefit will have the edit link for MediaWiki:Licenses on
Special:Upload, because commons.wikimedia.org has that message in
$wgForceUIMsgAsContentMsg.
Change-Id: Ib800b9adcc9ae88ef53228b66838bf61d2065f0f
When a string is passed to Message::inLanguage(), it first checks
whether the message's current language's code is equal to the string, to
avoid a call to Language::factory(). But if the message's current
language is an instance of StubUserLang, it's probably less expensive to
just call Language::factory() than it is to unstub.
This also avoids a possible recursion warning from T56193, particularly
if inLanguage() is being used intentionally in an attempt to avoid that
warning.
Change-Id: Ia09adec05cfbb09c09e07c6be1e2d613435664d9
* Remove unnecessary use of ReflectionClass. It was testing
internal properties that aren't part of the API. Using the
getters instead.
* Remove need for func_get_args that was making the test more
complex and the data provider hard to read. Simply maintain
it as array of expected params and array of variadic arguments.
* Rename tests to more closely match tested methods.
* Rename data providers to provide*, and make them static.
* Reorder tests to more closely match logical order of the class.
* Improve line coverage from 31% to 67%.
Also:
* Remove testParams (dupes testConstructorParams).
* Add tests for RawMessage class.
* Add tests for transformation and parsing.
* Add tests for wfMessage().
* Add tests for Message::newFrom*.
* Add tests for "$*" replacement.
* Add tests for __toString.
Change-Id: I2b183a66f9e9f51bd800088e174b1ae4d3284d8d
