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
I have run into numerous issues trying to utilize unsafe user
provided content as an argument to a Message instance. Specific
cases are enumerated in MessageTest.php
Typically the solution to using user provided text is to use
Message::rawParam, but this pushes escaping of the parameter to
the caller. This patch introduces Message::plaintextParams which
handles escaping of the string parameter to match the requested
output format.
The functionality is:
* plain and text: exactly like rawParams()
* escaped, parse and parseAsBlock: escape it but don't do brace expansion
Additionaly, similar to Message::rawParam, plaintext parameters are not
valid parser function arguments.
Change-Id: I320645cd23c98fea4bfc32ab22b7ef8d320957cb
The output of Message::text() should always be acceptable to pass into
external html escaping, such as when the response is returned over an
API request and escaped by the client side code. Calling ->text() on a
non-existent key was returning the entity encoded value which leads to
double encoding down the line, this patch fixes that oversight.
Bug: 66199
Change-Id: Ieec94d4e4c7e5c36e5e68bbf01792e96368e54e0
Message objects may be constructed with a list of keys as a
simple fallback mechanism. This patch assures consistent
handling of this case.
Change-Id: I458c0af3114754ddf3d721f6c374e249f482e4cf
- Swap "$variable type" to "type $variable"
- Added missing types
- Fixed spacing inside docs
- Makes beginning of @param/@return/@var/@throws in capital
- Changed some types to match the more common spelling
Change-Id: I783e4dbfe5f6f98b32b9a03ccf6439e13e132bcc
We've had the logic for stripping the outer <p/> element in three
separate places. The version in OutputPage was missing the '$' at the
end of the regex, that was most likely a mistake caused by the
duplication.
Also, extend the logic in order not to generate invalid HTML if the
input contains more than one <p/> tag. Added tests for this and the
previous behaviour.
https://www.mail-archive.com/mediawiki-api@lists.wikimedia.org/msg03188.html
Change-Id: I6bb3597898324556df912a23a7ffc9ff250b8f58
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Also added some missing @param.
Change-Id: I0056b4a8df243cfc0c5f25378de48f7a35170aca
Without this patch, it's not possible to get text in different
languages from the same Message object.
Change-Id: I0bb915b0d9205e78ac4599ced5efacacf2cf0240
This helps with testability to not have to rely on $wgLang
and setting globals in tests.
This also provides convenience, so one does not necessarily
need to call Message::inLanguage() if language is known
at time of constructing the message object.
Also added tests to cover this change.
Change-Id: I14ee98972c7be954e04398ece9e6103f96ab60dd
Reasons for touching this are:
* "@param type $var" were mixed in a lot of places. Both works but the
MediaWiki coding conventions suggest that specific order.
* Things like String and Bool aren't objects and shouldn't be uppercase.
* Tried to fill missing types in "@param $var".
* Tried to fill missing descriptions in "@return type" when I could.
* Removed duplicate descriptions if a @see is sufficend.
* Removed useless descriptions ("isUsefull returns true if usefull").
* Removed useless @return void.
* Replaces mixed[] with array (does have the exact same meaning).
* Tried to find better replacements for "varargs", phpDocumentor
suggest $var,...
* Order should be @since, @param, @throws, @return, @see. This is the
order Doxygen renders this.
There is always more to do but I think this is already much better
than before. Please feel free to put more change sets on top of mine
or request more changes by adding comments.
Change-Id: I05262ce06caabf79f68772302524ac91bbead1c6
Currently it only returns wikitext with templates expanded (like
Message's text() method).
Bug: 45844
Change-Id: I24b5b098f15d0a4194817f31f63e37be1179aae6
Account creation messages don't need to be parsed. This is
a temporary fix to follow up when double-parsing was accidentally
added in 69ea440003 (I402c6bebcfe).
Bug: 44718
Bug: 52191
Change-Id: I333d5468820994625348316ebf6c57d4df025284
Similar to numParams(), added functions for other parameters
that can be formatted by the Language class. Adds functions for
expiry, size, timePeriod, duration, and bitrate parameters so
that the formatting doesn't have to be done at the caller.
Change-Id: I7b435fcc11824ead55e4c0f5512418187eae9a6f
Also removed some unnecessary ones. I think I've caught them all.
The spaceless version already appears in core ~300 times (after
accounting for false positives when grepping). Some consistency would
be nice.
Change-Id: I607655b5f4366e66dc78730d5fd2f57ed8776cae
Also fixes Message::getKey() to always return a string.
Rationale:
Some code, like RollbackAction, assumes that Status::getErrorArray will
return an array of the form ( messagekey, param... ), but this was not
the case when a Message object was passed to the Status.
This change makes sure Status::getErrorArray will always return arrays
of the expected form. This is especially important since the messages in
the Status object may be provided by extensions.
In order to convert Message objects to arrays of message keys and parameters,
Message::getKey() needed to be fixed to return a single key always.
Bug: 49338
Change-Id: I0deaa9888e9d86726a8e41ca606c571f56190c91
Added spaces after/before parenthesis
Removed unneeded parenthesis around some statements
Broke a long line
Change-Id: I7fbe129f7bbf524dd0598ece2a9708643f08453b
