We renamed many classes to be namespaced, but the `@covers` and
`@coversDefaultClass` annotations weren't updated properly.
PHPUnit didn't support short cover annotations with `use` statements,
these didn't trigger any errors yet, because they are class alias.
This patch is populated by a modified version of PhpunitAnnotationsSniff.
Change-Id: I6c602290a30099239b17d2dc0d67b1488b4eaeeb
To follow Message. This is approved as part of RFC T166010.
Also namespace it but doing it properly with PSR-4 would require
namespacing every class under language/ and that will take some time.
Bug: T321882
Change-Id: I195cf4c67bd51410556c2dd1e33cc9c1033d5d18
This reverts commit 27ee63f8c9.
Reason for revert: Serialized Messages are stored in the database
Bug: T323236
Change-Id: Ia8089201eedf3c0585bb7e970b3776a7e0882019
The files in `tests/phpunit/includes/` directory are now all
covered. Will do sub-directories of `/includes/` next.
Change-Id: I8d5655ce267b6d32cf3c7ee40dc5d2992631b5a6
This affects messages created using wfMessageFallback() and related
functions, in particular many messages used for navigation tabs in
skins.
Previous attempt in 11d7d97768,
reverted in c83b530f95 due to T302469.
This attempt doesn't introduce any new placeholders to avoid that
issue.
Bug: T300069
Change-Id: Ib0e282b3864caf345e42dd7af4a529f43ae7ba67
This affects messages created using wfMessageFallback() and related
functions, in particular many messages used for navigation tabs in
skins.
Bug: T300069
Change-Id: Ia8ba35419285cfa77197810ae9df99e522a0f4ba
* Added ParamType::OBJECT, which allows Stringable objects to be passed into MessageValue
Bug: T278482
Change-Id: Ib4990f87d4ad70b7525d7aa05c8b97e90c121674
Remove Message::$format and the $format parameter of
Message::toString(), soft-deprecated in 1.26 and hard-deprecated
in 1.36. Also make the signature of toString() stricter.
Bug: T146416
Change-Id: I19aa3e482968dea5164afb93b04a55f27c644ce6
It is not entirely meaningless. It might be an indicator that
the number of calls to a method is intentionally unlimited.
This is similar to e.g. an @inheritDoc PHPDoc comment that
marks a method as being "intentionally undocumented".
However, what's the meaning of being "intentionally
unconstrained"? Let's just not have any constraint then.
I feel all these ->expects( $this->any() ) bloat the test
code so much that it's never worth it.
Change-Id: I9925e7706bd03e1666f6eb0b284cb42b0dd3be23
It's the same and makes the test code much more readable, I
would like to argue.
Because of the was I split all the changes I made into smaller
patches this patch contains some other changes in the same
lines where I could not split them off. E.g. removal of
->any(), which is the default anyway and doesn't do anything.
Change-Id: Ib297b989d4aec33b31a4e33fe9d5032865b39be0
This functionality exists to enable the anti-pattern of calling a
format method, without using its return value, and then subsequently
calling toString() to parse the same message, the same way, a second
time with the format you just called.
For example:
```
$msg = new Message('laggedreplicamode');
echo $msg->plain();
// <strong>Warning:</strong> Page may not contain recent
echo $msg->toString();
// <strong>Warning:</strong> Page may not contain recent
echo $msg->escaped();
// <strong>Warning:</strong> Page may not contain recent
echo $msg->toString();
// <strong>Warning:</strong> Page may not contain recent
```
Deprecate this rare anti-pattern in favour of using the return value
from the formatting methods such as $msg->plain() and $msg->escaped(),
or for compat we can also support $msg->toString('plain') etc.
This commit also fixes an unintentional lie in the assertion message
of one of the unit tests, which was claiming that toString() is
unaffected by format calls, when in fact it is. (And is what we are
deprecating here).
This implicit formatting and the related $this->format field will
be removed in 1.37.
Bug: T146416
Depends-On: Ia257621fb421854bf13e2965b04009663711ba0a
Change-Id: Ibb22099ff8042406e441d6c7fab87537d3ac92aa
Ended up using
grep -Prl '\->setMethods\(' . | xargs sed -r -i 's/setMethods\(/onlyMethods\(/g'
special-casing setMethods( null ) -> onlyMethods( [] )
and then manual fix of failing test (from PS2 onwards).
Bug: T278010
Change-Id: I012dca7ae774bb430c1c44d50991ba0b633353f1
This is used quite a lot in the codebase and it's
a reason for a lot of usages of $wgLang. Time and date
seems generic enough to put into Message library -
we already have references to Wikimedia\Timestamp
library there.
Bug: T278482
Change-Id: If7cb5f5dcfa736b6530f731af9dc3af168812054
There is native support for all of this now in PHP, thanks to changes
and additions that have been made in later versions. There should be no
need any more to ever use call_user_func() or call_user_func_array().
Reviewing this should be fairly easy: Because this patch touches
exclusivly tests, but no production code, there is no such thing as
"insufficent test coverage". As long as CI goes green, this should be
fine.
Change-Id: Ib9690103687734bb5a85d3dab0e5642a07087bbc
This test has been said to be flaky, and I suppose it could be if
it somehow regularly manages to tick a second in between the two calls
to wfTimestampNow(). So let's make just one call and reuse the value to
see if that fixes it.
Bug: T232266
Change-Id: I8fbdfa2f906839423cc238cd3741b94435a84505
I wasn't sure how to convert the rest of the occurrences in core (there
are a significant number).
Bug: T200881
Change-Id: I114bba946cd3ea8a293121e275588c3c4d174f94
This avoids error-prone code written separately in every test. In
addition to no existing tests resetting the TitleFormatter (more
services probably need to be reset as well), they mostly reset only the
namespace cache on $wgContLang, which wouldn't help for any other
language.
The parser test runner still doesn't do this, but maybe it should.
Change-Id: I44b7a1aec48f14b0950907fa14bd0df80f674296
Deprecate the unnamespaced version and move it to includes/compat.
Bug: T147167
Depends-On: I39c805bfb98b32f32f3d0dc1eee9e823afe1c21a
Change-Id: I3780c7adf51683f3f7adb35a88f9a25a0a2e2530
Replaces \TestingAccessWrapper (defined in core) with
\Wikimedia\TestingAccessWrapper (defined in the composer package
wikimedia/testing-access-wrapper).
See https://gerrit.wikimedia.org/r/#/q/topic:librarize-testing-access-wrapper
for downstream patches.
The core version of the class is kept around for a while to avoid
circular dependency problems.
Bug: T163434
Change-Id: I52cc257e593da3d6c3b01a909e554a950225aec8
System messages may take parameters from untrusted sources. This
may include taking parameters from urls given by unauthenticated
users even if the wiki is a read-only wiki. Allowing <html> tags
in such a context seems like an accident waiting to happen.
Bug: T156184
Change-Id: I661f482986d319cf41da1d3e7b20a0f028a42e90
I was bored. What? Don't look at me that way.
I mostly targetted mixed tabs and spaces, but others were not spared.
Note that some of the whitespace changes are inside HTML output,
extended regexps or SQL snippets.
Change-Id: Ie206cc946459f6befcfc2d520e35ad3ea3c0f1e0
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: I46261416f7603558dceb76ebe695a5cac274e417
The old code was similar to Message::params(), but Message::params()
was unable to handle "special" parameters and received an overhaul
in 7f2663f, yet wfMessage remained broken. To avoid duplication,
wfMessage shall call Message::params() to correctly handle these
parameters.
CategoryMembershipChange::getChangeMessageText and its caller has
been updated so as not to take advantage of this bug.
Bug: T153747
Change-Id: I6667acf7e71c9db07fefc9fbb741c160e15823ff
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
