Use more specific and less fragile assertions whenever possible;
most tests don't need to examine the internals of the status so
closely. Use StatusValue::getMessages() when necessary.
Change-Id: Ie4b3ebc03abb0e352e82394ced6ab9e733c83fb4
Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: Iae45fa269363be8ee05c598ea6926514ce817762
Normally two Message objects can be compared with `==`, and they will
compare equal if they have the same key, parameters and internal state
such as the selected language.
However, if you call `setContext()` on a Message, it will never
compare equal to any other Message object, because a unique closure
is stored in the `userLangCallback` property.
Most implementations of MessageLocalizer::msg() use `setContext()`,
so filtering out duplicate Message objects in StatusValue usually
didn't work. Luckily most uses of StatusValue use string message keys.
Change-Id: Id22075bf73d37fd139c2ef7d80c69eeb462a7b68
Follows-up Ibc4ce11594cf36.
> We lose useful coverage and waste valuable time on keeping tags
> accurate through refactors (or worse, forget to do so).
>
> Tracking tiny per-method details wastes time in realizing (and
> fixing) when people inevitably don't keep them in sync, and time
> lost in finding uncovered code to write tests to realize it was
> already covered but "not yet claimed".
>
> Given all used methods are de-facto and liberally claimed, and
> that we keep the coverage limited to the subject class, this
> maintains the spirit and intent. PHPUnit offers a more precise
> tool when you need it (i.e. when testing legacy monster classes),
> but for well-written code, the class-wide tag suffices.
Ref https://gerrit.wikimedia.org/r/q/owner:Krinkle+is:merged+message:Widen
Change-Id: I6d66d5db2ca15441d3f26d54b0bd53913976c684
StatusValue::replaceMessage() doesn't really work if given a
MessageSpecifier, and doesn't work at all if given a MessageValue.
StatusValue::hasMessage() and ::hasMessagesExcept() ignore the message
parameters when searching if given a MessageSpecifier or MessageValue.
Therefore, deprecate passing anything other than strings representing
message keys to these methods.
Change-Id: Icb4effc6c5319c12ba4ebeab447a0cef54f8e255
An array of MessageSpecifier objects is easier to deal with than the
"legacy error array" format, which is an array of whatever wfMessage()
accepts, which can be a bunch of different things.
Deprecate some existing getters.
Change-Id: Ibc4ce11594cf36ce7b2495d2636ee080d3443b04
The array spread operator is documented to behave identical to
array_merge. The syntax is just much shorter and easier to read in
situations like this, in my opinion.
Change-Id: I3b016e896e552af53d87d5e72436dc4e29070ce1
The result of wfEscapeWikiText() did not consider inclusion of a string
within table context, and so `!!` and `!` at start of line were not
previously escaped.
Additionally, if you are inserting the result of wfEscapeWikiText()
into a wikitext string, the result can inadventently form new tokens
at the left and right edges. For example:
{|
|<escaped string>
When the escaped string starts with a `-` or `+` it forms the `|-` or `|+`
token and changes the parse.
On the right side:
<escaped string>_FORCETOC__
is not a magic word unless the escaped string ends with a `_`.
Token-gluing can also occur with the double newline token denoting
a paragraph separator.
This patch adds additional cases to wfEscapeWikiText to armor
its output against all contexts in which the output may be
inserted.
Depends-On: I56147520620d56a4b98c2f22d1f469b49aed761f
Change-Id: I34f2fa8c329e6f6771453b2f94dc4afbec31dac8
Use modern array destructuring and such to make the code – so I
hope – much more readable.
Also fix a mistake in the Status test setup. This caused the mocked
Message::getParams() to return an array with string keys. This is
impossible in non-mocked scenarios. There is an array_values() call
in the Message constructor that doesn't allow string keys.
Change-Id: Ief09feb06c60d3ffbfa95fa8ef56b4a9829da680
This takes us one step closer to deprecating Status,
so we can isolate StatusValue from presentation logic.
FormatterFactory is introduced as a mechanism for
getting instance of formatters that need access to the user interface
language and other request dependent information.
Usage is demonstrated in thumb.php, SpecialCreateAccount, and
SearchHandler. The examples indicates that there is no work do
be done around ErrorPageError and LocalizedHttpException.
Change-Id: I7fe5fee24cadf934e578c36856cc5d45fb9d0981