Why:
- ParsoidRenderID::newFromKey() validates incoming keys and throws an
InvalidArgumentException if a required key component was missing.
- It does so by eagerly destructuring the return value of explode(),
which causes a PHP Notice for invalid inputs as the expected offsets
won't exist then.
What:
- Check the count of key parts before destructuring.
- Add unit tests.
Bug: T385567
Change-Id: I1d936ae038f85ffa2e5d1d3d8a75fdc75e4c8ef8
(cherry picked from commit eec130925c081c2da1c475f9a9ce719e6838ca51)
Why:
- The test ClockTest::testShouldReturnCurrentTime is flaky.
- Ie48d9400cf3bb99467a16b9ea0cce6172e2e2568 recently augmented
the ConvertibleTimestamp library to allow faking hrtime(), which will
be a better solution for this class and test than the current
assertion.
What:
- Skip the test until core is updated to the latest version of
ConvertibleTimestamp.
Bug: T379562
Change-Id: Iae502ed0344f45f89da575f1c5d1e0fb9c1e4dfa
(cherry picked from commit a930114b4240ec311a56eef7f814f378cc3d5f88)
This can cause PHP to try to load the param value as a class, with
potentailly disastrous results (though it’s not quite clear if this can
actually cause attacker-supplied code execution or not).
Bug: T377912
Change-Id: I0239b3e65cf516c6fdf287882f05e47a01f963c1
(cherry picked from commit cdf11b23474024dfe39057993372f2126302e244)
This was seen in WMF production during a train deployment, where namespacing of classes,
which had been serialized (for example CacheTime), along with our PSR-4 definitions may result
in cases where PHP tries to load the same PHP file more than once. Combined with non obvious
error messages, require_once gives us better behaviour and error messages.
More explicitly:
In T378006, the autoloader is entered from class_exists(), and the class has a filename
resolvable with PSR-4 which is already loaded by a non-PSR-4 class name. Using require_once
would allow class_exists() to return false in that case.
In T372500, the autoloader is entered from unserialize(). It looks like require_once would
just give you a more informative error message.
Bug: T378006
Bug: T372500
Change-Id: I928f29198af9baf81a3cae604b3adf41595c2176
(cherry picked from commit 03dd4ae7ae0e2ce7e45f0bf2cb913642eef842a8)
Implicitly marking parameter $... as nullable is deprecated in php8.4,
the explicit nullable type must be used instead.
Followup to e662614f, using PHPStan.
Bug: T376276
Change-Id: I60d639b042b537bf2f531cc132f1b75a66b85acb
(cherry picked from commit da0a395efa7847916371f9c0a6b271faa022ff59)
Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: I73fb416573f5af600e529d224b5beb5d2e3d27d3
Changes to the use statements and some additions
are done automatically via script
This also updates @covers tag for the namespaced classes
Change-Id: I859ba6d05018c99710b744e2becab432410d3bca
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
Why:
To facilitate the evaluation of conditions not directly
"known" by the lookup, eg: owned by extensions
What:
- Add ConditionalDefaultOptionsAddCondition hook which
runs before instantiating ConditionalDefaultsLookup allowing
to add conditions for evaluation in the $extraConditions
array.
- Evaluate the configured conditional default against the
extra added conditions after evaluation of "known"
conditions.
Bug: T376918
Change-Id: Ife6f96397eafd61fdb40528aac315ddde1ef2774
And use that as much as possible. This makes bootstraping services much
faster since Language object is extremely heavy (specially to
initialize) and that's why in LanguageFactory it's behind a cache (see
LanguageFactory::getRawLanguage)
At the same time, most uses of Language object only need the language
code (after normalization and mapping and validation) and this allows
such change to happen fast and way more decoupled from Language object
that has more than 100 methods.
Bug: T376565
Change-Id: I1c3d94454896842939dfaad8cbf742e5a3ae5438
This adds support for serializing/deserializing objects which
implement the JsonCodecable interface from the wikimedia/json-codec
library used by Parsoid. JsonCodecable allows customizing the encoding
of objects of a given class using a class-specific codec object, and
JsonCodecable is an interface which is defined and can be used outside
mediawiki core.
In addition json-codec supports deserialization in the presence of
aliased class names, fixing T353883.
Backward and forward compatibility established via the mechanism
described in
https://www.mediawiki.org/wiki/Manual:Parser_cache/Serialization_compatibility
Test data generated by this patch was added in
I109640b510cef9b3b870a8c188f3b4f086d75d06 to ensure forward
compatibility with the output after this patch is merged.
Benchmarks:
PHP 7.4.33 PHP 8.2.19 PHP 8.3.6
BEFORE AFTER BEFORE AFTER BEFORE AFTER
Serialize: 926.7/s 1424.8/s 978.5/s 1542.4/s 1023.5/s 1488.6/s
Serialize (assoc): 930.2/s 1378.6/s 974.6/s 1541.9/s 1022.4/s 1463.4/s
Deserialize: 1942.7/s 1961.3/s 2118.8/s 2175.9/s 2129.8/s 2063.5/s
Deserialize (assoc): 1952.0/s 1905.7/s 2107.5/s 2192.1/s 2153.3/s 2011.1/s
These numbers definitely do not have as many significant digits as
written here. But they should be sufficient to demonstrate that
performance is not impaired by this patch and in fact serialization
speed improves slightly.
Bug: T273540
Bug: T327439
Bug: T346829
Bug: T353883
Depends-On: If1d70ba18712839615c1f4fea236843ffebc8645
Change-Id: Ia1017dcef462f3ac1ff5112106f7df81f5cc384f
In T340552, the official PHP OpenTelemetry client was effectively
rejected for inclusion in MediaWiki due to its size. Implement a minimal
tracing library instead that eschews conformance with the OTEL client
specification in favor of simplicity, while remaining capable of
emitting trace data in OTLP format and thus retaining compatibility with
any ingestion endpoint capable of handling OTLP.
In its current state, the library supports a basic feature set that
should be sufficient for basic tracing integration:
* Span creation, inclusive span activation and automatic parent span
assignment,
* Span attributes and span kinds,
* Basic resource (process/request)-level metadata generation,
* Data export over OTLP.
Additional functionality, such as trace propagation, can then be
incrementally added to the library.
Bug: T340552
Change-Id: Ibc3910058cd7ed064cad293a3cdc091344e66b86
This would allow us to force parsercache idhash and idoptions keys next
to each other so when e.g. depooling 1 of 4 hosts in a parser cache cluster,
the amount of cache misses due to rehashing will be ~25% instead of ~%50.
This is similar to the implementation in WANCache and the same structure
has been used to make it consistent.
Bug: T373037
Change-Id: I920fe76e45298aeee6acf725324a5e1ed2b57a37
Previously, parameter descriptions could only be specified as
strings. We want OpenAPI specs generated from parameter
definitions to be internationalizable, so allow specifying
descriptions as MessageValue objects, which can be translated
using normal MediaWiki mechanisms.
Associated improvements to ResponseFactory.
Bug: T376493
Change-Id: If1cbe4f7bfd5c375e64b802b666c0247d65b1ee0
*Most* implementations of ContentHandler::fillParserOutput() ensure
that the returned ParserOutput has had
ParserOutput::resetParseStartTime() called on it at an appropriate
time -- but not *all*. This is a belt-and-suspenders fix that ensures
that every code path which creates a ParserOutput has *some* "start
time" defined. This could be misleading if the parsing is done first
and the parser output is created at the very end of the parse, but in
all the code that I've looked at the ParserOutput is the first thing
created and so this default should be reasonable.
While we're at it, remove the parseStartTime from the serialized form
of the ParserOutput, because it is useless after the object is
unserialized.
Bug: T376433
Change-Id: I3bdf3996401a7d5ac4d8e1e5e6afb7ca410cbe6c
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
Why:
- The installer feeds several user-provided values, such as the site
name, directly into LocalSettingsGenerator.
- There, these get passed through escapePhpString(), the output of which
is safe when rendered into a double-quoted string, but fails if the
input string contained single quotes and was rendered into a
single-quoted string.
What:
- Consistently output all strings in LocalSettingsGenerator as
double-quoted strings.
Bug: T372569
Change-Id: I27bb3c31d8e9957b4880d0faba8b79d121126a11
Follows-up 4e596f5112 (I59266726ad), which fixed bug T318272, but
did not add a regression test for it.
Bug: T318272
Bug: T327158
Change-Id: Ia8af6671887d3914fdc761d8e5d10fd33fb40f88
The discovery endpoint provides basic information about accessing the
wiki's APIs, as well as a directory of available modules.
Bug: T365753
Change-Id: I161aa68566da91867b650e13c8aadc87cd0c428c
