aboutsummaryrefslogtreecommitdiffstats
path: root/includes/Status
Commit message (Collapse)AuthorAgeFilesLines
* Merge "Streamline StatusFormatter::getPsr3MessageAndContext a little"jenkins-bot2025-03-141-9/+8
|\
| * Streamline StatusFormatter::getPsr3MessageAndContext a littlethiemowmde2025-02-131-9/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This code was introduced via Id76f554 and later updated via Iddd14ef. While it's apparently intentional to *not* use an `instanceof Message` check as that would include unknown subclasses, I think we can safely assume that RawMessage and ApiMessage do have a predictable interface. Both Iddd14ef as well as the test cases in StatusFormatterTest seem to agree. I found this while searching for awkward usages of get_class(). Change-Id: I0555e7a92f94a3672833ff0de86d10786ca212db
* | Split MessageParser out of MessageCacheTim Starling2025-02-211-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MessageCache has enough to do without also being a parser. Split a MessageParser class out of MessageCache and make it a service. * MessageCache::parseWithPostprocessing() becomes MessageParser::parse() because every caller wants postprocessing so it makes sense to use the shorter name for this. * MessageCache::parse() becomes MessageParser ::parseWithoutPostprocessing(). I changed the return type from ParserOutput|string to ParserOutput, which is a followup to I8a1fa84e650d920d07d74722d8059d5afeedec6b. Narrowing the return type does not break b/c so it is possible to make this change for both variants. * In the new methods, a null title is always a convenience alias for a placeholder title (Special:Badtitle). This reflects the convention in Parser::setPage(). The old MessageCache::parse() retains its b/c fallback to $wgTitle. MessageCache::transform() had the potential to fall back to the title used in the previous call, a fragile mechanism which I removed without deprecation. * For consistency, allow a string language in all new methods. * In EmailNotification, clean up an early attempt at global state avoidance. Change-Id: I05ab21508d5f8394189fd41ac6a2254ac0e0d785
* | Replace call_user_func with dynamic function callUmherirrender2025-02-131-1/+1
|/ | | | | | | | Use modern php syntax to call a callable. Reduce the stack trace to improve performance and better IDE and static analyzer support Change-Id: I9ef131032a662a3b8db69aa7079dbd51f88f575a
* Add $linestart to parseWithPostprocessingIsabelle Hurbain-Palatin2024-11-251-1/+5
| | | | | | | | | | | | | The call to getText in Echo::DiscussionParser (line 1293) seems a good fit for the usage of MessageCache::parseWithPostprocessing to replace it, but it is called with a $linestart parameter that we can't pass to this method anymore. Hence, we reintroduce the parameter with a default value of true as it was used in the method, using the same argument order as Parser::parse(). Bug: T293512 Depends-On: Iab08f6272b2995a42b0732ad82e73e6beb796cd7 Change-Id: Icdab9cec8b40baa090b450994fd82dcbb7a83afe
* Merge "Add type hints to detect bool/null message params"jenkins-bot2024-11-141-1/+3
|\
| * Add type hints to detect bool/null message paramsBartosz Dziewoński2024-11-141-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | Add more precise type hints to every method I could find that takes message params as arguments, so that Phan will warn if bool or null is passed, which is deprecated (T378876). Errors found in this repository thanks to these checks are fixed in I286a4a51e879bdf61f65c87dc078621c51045bee. Bug: T378876 Change-Id: I3e0df790ff9db2fa630f82408a7254a359fe61ca
* | Merge "StatusFormatter: Allow passing context to getPsr3MessageAndContext()"jenkins-bot2024-11-132-10/+12
|\ \
| * | StatusFormatter: Allow passing context to getPsr3MessageAndContext()Bartosz Dziewoński2024-11-032-10/+12
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a common usage pattern for this method: [ $message, $context ] = $this->statusFormatter->getPsr3MessageAndContext( $status ); $this->logger->error( $message, [ 'extra' => $myExtraContext, ] + $context ); With the new parameter, it can be more concisely written as: $this->logger->error( ...$this->statusFormatter->getPsr3MessageAndContext( $status, [ 'extra' => $myExtraContext, ] ) ); (If only the method name wasn't so awfully long…) Change-Id: Ib14cab701dd0e3c2a729a6cc7ae626f0d1be1f8f
* / Remove getText usages in the vicinity of MessageCacheIsabelle Hurbain-Palatin2024-11-091-5/+5
|/ | | | | | | | | | | | | | | | | | This is the fifth patch of a series of patches to remove ParserOutput::getText() calls from core. This series of patches should be functionally equivalent to I2b4bcddb234f10fd8592570cb0496adf3271328e. Here we handle the case of MessageCache, which requires a bit of refactoring to start deprecating the fact that MessageCache::parse can return either a string (if not a top-level parse) or a ParserOutput (at top-level), which callers typically use to decide whether to run getText on the output or not. We provide a MessageCache::parseWithPostprocessing method that handles this case and runs the pipeline at the desired level, and returns a ParserOutput always. Bug: T293512 Change-Id: I8a1fa84e650d920d07d74722d8059d5afeedec6b
* Make Message and MessageValue compatibleBartosz Dziewoński2024-10-191-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* status: Log getMessage()/getWikiText() calls on good StatusesMáté Szabó2024-10-041-17/+29
| | | | | | | | | | | | | | | | | | Why: - Calling getMessage()/getWikiText() with a good Status is a logic error that converts the Status being operated on into a fatal one. - However, this error is never logged anywhere, which can make it difficult to diagnose such cases, as seen in I17166e988bf389a5b03d4a74f539f7bec7f5997f. What: - Add a warning-level log for the case when getMessage() or getWikiText() is invoked with a good Status. Bug: T374436 Change-Id: I3efae5c4c336156924f1c9b4186fa9142aaed9ca
* Add namespace to includes/api classesJames D. Forrester2024-09-251-1/+1
| | | | | Bug: T353458 Change-Id: I3ea6b08c5018ba03ba45c5766e1f46e12f6b8597
* Move Language and friends into Language namespaceJames D. Forrester2024-08-102-2/+2
| | | | | Bug: T353458 Change-Id: Id3202c0c4f4a2043bf97b7caee081acab684155c
* Status: Document wikitext escaping of parameters in StatusFormatterBartosz Dziewoński2024-08-062-0/+43
| | | | | | | | | | | | StatusFormatter escapes all message parameters that were provided as strings (rather than within MessageSpecifier objects) with wfEscapeWikiText. This annoying behavior was not documented. I copy-pasted the same comment to all methods that do this. If there's a better way, let me know. Bug: T368821 Change-Id: I26cee41bf8cc591a68839d462c38d746d6bfcad4
* Namespace MessageSpecifier under Wikimedia\Message\Bartosz Dziewoński2024-07-281-1/+1
| | | | | | | | | | 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
* Merge "language: Improve behavior of RawMessage used as MessageSpecifier"jenkins-bot2024-07-161-5/+5
|\
| * language: Improve behavior of RawMessage used as MessageSpecifierBartosz Dziewoński2024-07-161-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | status: Use HTML lists in StatusFormatter::getWikiTextDaimona Eaytoy2024-07-011-1/+1
|/ | | | | | | | | Using a wikitext list results in lack of support for messages that, in turn, contain bullet lists, as the inner list items would be put on the same level as the outer list. So, use plain HTML instead. Bug: T368830 Change-Id: Ie834aea8469a74c6de7374ad20882e94f674f15d
* StatusValue: Add a getter for MessageSpecifier listBartosz Dziewoński2024-04-101-0/+2
| | | | | | | | | | 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
* Standardise all our class alias deprecation comments for ease of greppingJames D. Forrester2024-03-191-3/+1
| | | | Change-Id: I7f85d931d3b79da23e87b4e5692b2e14be8fcaa0
* Namespace Message, move to appropriate directoryJames D. Forrester2024-02-142-2/+2
| | | | | Bug: T353458 Change-Id: I088cbc53fbcdb974e5b05b45a62e91709dacc024
* Namespace includes/contextJames D. Forrester2024-02-081-2/+2
| | | | | Bug: T353458 Change-Id: I4dbef138fd0110c14c70214282519189d70c94fb
* Namespace ParserOutputJames D. Forrester2023-12-141-1/+1
| | | | | | | Most used non-namespaced class! Bug: T353458 Change-Id: I4c2cbb0a808b3881a4d6ca489eee5d8c8ebf26cf
* StatusValue: Allow passing arbitrary data to augment resultAmmarpad2023-11-281-3/+1
| | | | | | | | | | | | | This allows extensions and hooks to pass around additional data about the operation result arbitrarily to supplement value and errors. When two StatusValue instances are to be merged, it's responsibility of the caller to ensure either only one has this extra data or none, but never both (since the type is unrestricted). If necessary, the caller should merge them before invoking StatusValue::merge. Bug: T326479 Change-Id: Ibe3f1f8b81bcfcb18551d3ca4cda464e4bdbcbce
* Introduce StatusFormatterdaniel2023-10-272-230/+425
| | | | | | | | | | | | | | | 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
* Follow-up f4e68e0: Add in-code comment on alias for when it was addedJames D. Forrester2023-08-281-0/+3
| | | | Change-Id: I182908a5daae8ab6014432085af15b0c2c188ffd
* Reorg: Move Status to MediaWiki\Status\Amir Sarabadani2023-08-251-0/+500
This class is used heavily basically everywhere, moving it to Utils wouldn't make much sense. Also with this change, we can move StatusValue to MediaWiki\Status as well. Bug: T321882 Depends-On: I5f89ecf27ce1471a74f31c6018806461781213c3 Change-Id: I04c1dcf5129df437589149f0f3e284974d7c98fa
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-21 19:27:37 +0000