Fix two problems that made it difficult to convert between Message
and MessageValue, or to write code that could accept both of them,
as exemplified by the StatusValue class:
* Implement a common interface
* Use the same internal format for message parameters
While these changes should be compatible with most of existing code,
where the authors were courteous enough to simply call methods such
as Message::numParam() and not look inside the values they return,
it is potentially a breaking change for anything that depended on
the formatted params being arrays or accessed their keys.
Example patches: https://gerrit.wikimedia.org/r/q/topic:message-param
Notable changes:
* Message and MessageValue now both implement MessageSpecifier
(only Message implemented it before).
* Message::numParam() and other static methods for encoding params
now return MessageParam objects, instead of special arrays.
Use these MessageParam objects internally in Message.
* Narrow down the return type of MessageSpecifier::getParams() (it
was just `array`, allowing any type in the array). Narrow down the
types for Message::params() and MessageValue::params() to match.
* Deprecate MediaWiki\Message\Converter. As a replacement add
MessageValue::newFromSpecifier(), which is analogous to
Message::newFromSpecifier(), but without weird legacy edge cases.
* Make StatusValue::getMessages() return MessageValues. Remove code
that converted between Message and MessageValue, no longer needed.
* Update many type declarations and comments to use MessageSpecifier
instead of MessageValue, as well as a couple of tests that depended
on implementation details.
Bug: T358779
Change-Id: I625a48a6ecd3fad5c2ed76b23343a0fef91e1b83
Implicitly marking parameter $... as nullable is deprecated in php8.4,
the explicit nullable type must be used instead
Created with autofix from Ide15839e98a6229c22584d1c1c88c690982e1d7a
Break one long line in SpecialPage.php
Bug: T376276
Change-Id: I807257b2ba1ab2744ab74d9572c9c3d3ac2a968e
* Avoid square bracket or code syntax inside exception messages as
these are difficult to search for. Rephrase as a sentence instead.
* Swap order of $key docs.
* Improve $key docs to emphasize message existence. Non-empty-ness
is afaik a much more narrow edgecase than what this is used for
in practice.
* Make error message about invalid $key more globally correct instead
of assuming that when an empty array is passed, the only correct
value is a non-empty array, as the array may be an accident in
itself, which might be more likely given how rare passing arrays
as message keys is.
Change-Id: Iae66a62b983d39d4ab5cc1035bd9285c9ba3311a
* Add getters for the lists of valid types
(named cases() like in PHP 8.1 enums)
* Validate that the provided type is in the list
* Replace funky use of reflection in Converter
Change-Id: I8da89edbb943fae8920c15b1bc6856ce97a4de7a
It's an easy mistake to write:
$msgSpec = [ $key, $param1, $param2 ];
wfMessage( $msgSpec ); // WRONG
instead of
wfMessage( ...$msgSpec ); // correct
Message::newFromSpecifier( $msgSpec ); // correct
If you use the wrong form, your intended message parameters are used
as fallback message keys, and usually ignored (assuming your intended
message key exists).
It's not possible to catch this mistake in all cases, since it's all
arrays of strings most of the time. But we can try.
Change-Id: I0b40ad90a352dc640e64090cac4224219752dc01
get_debug_type() does the same thing but better (spelling type names
in the same way as in type declarations, and including names of
object classes and resource types). It was added in PHP 8, but the
symfony/polyfill-php80 package provides it while we still support 7.4.
Also remove uses of get_class() and get_resource_type() where the new
method already provides the same information.
For reference:
https://www.php.net/manual/en/function.get-debug-type.phphttps://www.php.net/manual/en/function.gettype.php
To keep this safe and simple to review, I'm only changing cases where
the type is immediately used in an exception message.
Change-Id: I325efcddcb58be63b1592b9c20ac0845393c15e2
In change I625a48a6ecd3fad5c2ed76b23343a0fef91e1b83 I am planning to
make Wikimedia\Message\MessageValue use it, and we try to pretend that
it is a library separate from MediaWiki, so it makes sense to move
MessageSpecifier to the same namespace under Wikimedia\.
Bug: T353458
Change-Id: I9ff4ff7beb098b60c92f564591937c7d789c6684
We have some code that expects that if you disassemble a
MessageSpecifier using its getKey() and getParams() methods,
then assemble a new MessageSpecifier using the return values,
you will get (at least approximately) the same message.
This was not the case with RawMessage, even though it implements
the MessageSpecifier interface, because its "keys" are not real
message keys, and this operation would mess it up.
Override the MessageSpecifier methods on RawMessage so that they're
compatible with how everyone expects a MessageSpecifier to work.
Add some tests for OutputPage, Message\Converter and Status
to verify some scenarios that would previously have failed.
Depends-On: I41991989515b4791bc1746f26bd404bf4f17dbdb
Depends-On: I612361dd20ff8aad4c0069f1c5af78e3e13b9692
Change-Id: Iddd14efa8b9536277c372257d5a7be135f26a540
Some syntax highlighters, in particular Gerrit's, incorrectly handle
code that uses a property named 'interface' (which is a PHP keyword).
https://phabricator.wikimedia.org/F55884039
Rename it to avoid problems.
Message isn't '@stable to extend', so this is not a breaking change.
I couldn't find any extensions that refer to it anyway.
Change-Id: I6676421222921b7bb1aeeefef79dd06072c1c2ac
When using MediaWikiTestCaseTrait::getMockMessage(), if the mock
message was passed as a parameter to another non-mock message, its
format() method was called, which is private and can't be mocked,
and causes "LogicException: Premature access to service container"
in unit tests. Call the public toString() instead.
Change-Id: I8718cf7890f05c09a6e5712ee3dc4d171a6637cf
In PHP 8, but not in PHP 7.4, every class with a __toString() function
implicitly implements the Stringable interface. Therefore, the
behavior of checks like "instanceof Stringable" differs between these
PHP versions when such classes are involved. Make every such class
implement the interface so that the behavior will be consistent.
The PHP 7.4 fallback for the Stringable interface is provided by
symfony/polyfill-php80.
Change-Id: I3f0330c2555c7d3bf99b654ed3c0b0303e257ea1
This functionality was introduced in 2021 (commit 349819dc5a)
to support the addition of UserGroupMembershipParam, which was
never used, and no other use case appeared.
Its existence is now preventing us from allowing serializing
of MessageValue objects as JSON (since the parameters can't be
guaranteed to be serializable).
Deprecate:
* method: MessageValue::objectParams()
* method: Message::objectParams()
* method: Message::objectParam()
* class: UserGroupMembershipParam
* constant: ParamType::OBJECT
* Passing Stringable objects to ScalarParam
Change-Id: I492edabb7ea1d75774b45eb9fd18261b39963f9f
Change the Message::getTitle() function to not use the
wiki's content language when generating links to pages in the
MediaWiki namespace.
Message::getTitle() returns the uppercased version of the message
name as a title object. For some languages, such as Azeri and Turkish,
this can lead to some transformations we don't want. For instance,
when you uppercase "i" in Azerbaijani, it becomes "İ" (dotted I),
leading to links to "MediaWiki:İpbreason-dropdown" on Special:Block.
Bug: T362654
Change-Id: Id37c226270c53352760790ddd461ca98920b5910
When displaying messages, the requested message key can be overridden
by hooks such as 'MessageCacheFetchOverrides'. If this happened,
display the overridden key when using &uselang=qqx, to help users and
developers track down where a message is coming from.
Bug: T363729
Change-Id: I81d814278ca810035066ce4632f617f30536f1ab
The new trait provides conveniance methods for logging and throwing
errors based on StatusValue instances.
Change-Id: Id7cbacb744bee79cd8a6f61291a26b36e6243053
Message::setContext() called $context->getLanguage(), loading the user
options from the database, which is unnecessary if
Message::inLanguage() is called immediately afterwards.
In a ResourceLoader module, RequestContext::getLanguage() throws an
exception due to MW_NO_SESSION being defined. For example, an exception
was thrown if any HTTP client error was encountered, since log message
formatting includes a call to Message::setContext().
So defer the call to RequestContext::getLanguage() by having
Message::setContext() make a closure which later fetches the language if
necessary.
Add an integration test which previously failed.
Change-Id: I326c7e3a9492952d721fb52f1868ab9c1033e683
Add @since to the replacement code (349819d)
Also notice UserGroupMembership::getGroupName in release notes, there
was no entry in the deprecation commit fb4e7a8
Bug: T325673
Follow-Up: Ib4990f87d4ad70b7525d7aa05c8b97e90c121674
Change-Id: Iae3a26dbc0b95b0d4edb59f03126295fc67c856e
* Added ParamType::OBJECT, which allows Stringable objects to be passed into MessageValue
Bug: T278482
Change-Id: Ib4990f87d4ad70b7525d7aa05c8b97e90c121674
The Action API is going to need to convert between the two at various
boundaries where it receives a Status from business logic.
Also when we make HtmlFormatter and the like, that'll initially need the
same conversion logic too.
Change-Id: Id5b216b033718f3ef38bfd4be1715218ee07bb93
Fixes an overstrict test in ListParam, and has TextFormatter convert
to Message recursively where necessary.
Change-Id: I387754b6857fbdeedea6afd222a2fdba1ebe1a9c
An injectable service interface for message formatting, somewhat
narrowed compared to Message.
Only the text format is implemented in this framework so far, with
getTextFormatter() returning a formatter that converts to the text
format. Other formatters could be added to MessageFormatterFactory.
Bug: T226598
Change-Id: Id053074c1dbcb692e8309fdca602f94a385bca0c
