| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
Added in 2022 with I7d97c9e2d4 (c6a0d433ec) for Ie430acd075
(e82f11c246) which was (after a revert and re-apply) eventually
removed after the warmup completed (I852060c8a4, 3df4952385).
Bug: T322672
Bug: T387478
Change-Id: I1921b4f985fb27b2227aef4a0eba6751c1c0b8d5
|
|
|
|
| |
Change-Id: Ic9c1e2051775733672fe8a5378fd3b7ed0a3f652
|
|
|
|
|
| |
Bug: T353458
Change-Id: I3cf44dfe5425f2efb8409c83571c427447b053af
|
|
|
|
|
|
|
|
|
| |
In MediaWiki/Exception, to follow PSR-4 per plural vs. singular (this can be
changed later if people really care). Also, move the couple of exceptions in
here that were already namespaced in the MW-top-level into the new space.
Bug: T353458
Change-Id: I12ed850ae99effb699a6d7ada173f54e72f0570e
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
OpenAPI specs include an "info" section that includes strings such
as "title" and "description" that are intended to be human-readable.
Make all such strings translatable.
Bug: T385855
Change-Id: I15285be6d196c0e7fd7e922f23058d7c09b6b31a
|
|\ \ |
|
| |/
| |
| |
| |
| | |
Bug: T384942
Change-Id: I12c564245113226403298c472f93404dc6b28c2c
|
|\ \ |
|
| |/
| |
| |
| |
| | |
Bug: T382458
Change-Id: Iedd4526a516e8c8e45576a15f3a747a429a2f317
|
|/
|
|
|
|
|
| |
Extending the work began in T3847447, in a continued effort to auto-generate translatable messages in OpenAPI specs, refactor schemas for content.v1 endpoints to accept translatable strings.
Bug: T384750
Change-Id: I95b51021babbed1800ed53ee0066cbe83b3b7535
|
|
|
|
|
| |
Bug: T353458
Change-Id: I35864ad9bd48701703c51367d62f8ebde963c52d
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Why:
- Revision meta-data output was failingfor revisions with suppressed
user or comment
What:
- Handle suppressed user and comment gracefully
- add regression test
Bug: T386368
Bug: T387397
Change-Id: Ic6d3fc89d24030f5c3fd422637816de9976fc709
|
|
|
|
|
|
|
| |
As part of the effort to auto generate translatable messages in OpenAPI specs, refactor schemas for content.v1 endpoints to accept translatable strings.
Bug: T384747
Change-Id: I728f0932a770eba56c2ad8e26c74f88fa266a1f9
|
|
|
|
|
| |
Bug: T376607
Change-Id: I44bbba284e34e8ff53914d9a881598ccb5cb8aa8
|
|
|
|
|
|
|
|
|
|
|
|
| |
is_object is very rarely what we actually need. In many cases we know
exactly what the object can be, and should check for that specific
class or for null.
A database row is an instance of stdClass. Checking that with
is_object also works but is less correct and would allow stuff we
cannot accept in these places.
Change-Id: I1dc663d7325cabc059ef11c4845b0189208e907f
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
As part of an effort to increase translation coverage over automated OpenAPI spec generation, use established translation strings for all request body parameters.
Bug: T378375
Change-Id: If678d7177bd09e3bdc5bc0cd1605a43dc825eb5c
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add $string === false or $string === null where $string can have other
types than a string.
Also document null as possible return value in FileRepo.
Change-Id: Iaa29ba01c3fd6bea506debdc6f929edfe881c808
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Why:
- The REST API takes an optional renderid param when converting HTML
back to source wikitext, which is user-provided and may be invalid.
- Invalid render IDs cause an InvalidArgumentException to be thrown that
causes a 500 response.
What:
- Introduce a new error message for invalid render IDs in the REST API.
- Return a 400 with this new error message for HTML reverse-parses with
an invalid render ID.
Bug: T385568
Change-Id: I062419fe8952329a39781a49cdca2e94c3996447
|
|\ |
|
| |
| |
| |
| |
| | |
Bug: T3766077
Change-Id: I262958157bb60841a391a99ccd46794690b4febf
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | | |
Bug: T382455
Change-Id: Ia10c5226dad5162b35c4e9b139876de735cf4a1b
|
|\ \ \
| |_|/
|/| |
| | | |
tests"
|
| |/
| |
| |
| |
| | |
Bug: T376607
Change-Id: I5e9ecc2a8148ea7d25d616de255d0990b84fef89
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Same as Ia294bf4 did for 1-line comments. This patch removes slightly
more complex 2-line PHPDoc comments that don't add any new information
to the code, but literally repeat what the code already says.
They say "don't document the code, code the documentation", and we
are doing this more and more. We just tend to forget to remove the
obsolete comments.
Note I'm also removing a line of text in a few cases when it's very
short and literally says the same as the method name. Again, such
comments add zero new information.
Change-Id: I01535404bab458c6c47e48e5456403b7a64198ed
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Why:
- The Parsoid extension needs to support additional formats for
transformation, for backwards compatibility. We shouldn't fail
when an OpenAPI spec for the other kinds of output is requested.
What:
- Provide a trivial default spec when asked for a spec for pagebundle
or lint output.
Bug: T379705
Change-Id: I6ccac0573480736d25bce46ed95843c149e00bd2
|
|\ \ |
|
| |/
| |
| |
| |
| | |
Bug: T376607
Change-Id: I837b0a8471b8a2c8675d33852406d3ba4ce4ae05
|
|\ \ |
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I assume these are all either auto-generated by an IDE or the
language-level type declarations have been added later. In any case
the comments don't add any new information to what the code already
says. This is just extra clutter that makes the code harder to read,
I would argue.
There are many, many more comments like this. In this patch I
intentionally focus on the most trivial 1-line comments.
Change-Id: Ia294bf4ce0d8a77036842fe25884bc175c2b0e7d
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| | |
Bug: T379705
Change-Id: I6f1925f564e708be47cbc13a01a1b5d2d7b3da69
|
| |
| |
| |
| |
| |
| | |
ChangeTagStore
Change-Id: I68be30cf4f682a587f19227ef08808f0995f600b
|
| |
| |
| |
| |
| | |
Bug: T382264
Change-Id: Iec5f168629622a0094cbbaeff4f143d1c39e9bb6
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1078506 we added
the ability to specify path/query parameter descriptions as
MessageValue objects to expose them in a translatable way in
OpenAPI specs. Make the same possible for response body parameters.
Caveat: only schema and top-level property descriptions are translated.
Description translation in nested objects is not supported in this patch.
Bug: T379706
Change-Id: I68215ad55f2e8b2fec4315516e874192faba6595
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| |
| | |
Bug: T376603
Depends-On: I4193b9be4516717c7ce423131370a7d0b6ea8962
Change-Id: Ic2d9471ad446eb5f9d5e7072f1ef93f7196a20f8
|
| |
| |
| |
| |
| |
| |
| |
| | |
The ability to pass a StatsdDataFactoryInterface was deprecated in MW
1.43 and is now being removed.
Follows-Up: I2374731f6d37a191fc4a865d2665f2ca18182db1
Change-Id: Ie68c583c7ad3e5be95ddfc8369bd6953cfd099aa
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| | |
Parameter descriptions are currently parsed as strings. Using a MessageValue object instead will allow for OpenAPI specs to be internationalizable.
Bug: T376493
Change-Id: Ia2991f196c6d9b0810181f907f0a048393cddad9
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
When accessing slot content and meta-data, most code wants to only
access the main slot. Add convenience methods for making this less
awkward.
Originally, the intent was for all code to support arbitrary slots. This
hasn't happened, instead we spread SlotREcord::MAIN all over the code
base. It seems better to adjust the interface of RevisionRecord to
reality.
Change-Id: I8603f95c8e39d6fc3522a47f74657798e7f7c061
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Bug: T376493
Change-Id: Ia91f2bca14730599658e05446931e1426adb9eae
|
|
|
|
|
|
|
|
|
|
|
| |
In https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1078506 we added
the ability to specify path/query parameter descriptions as
MessageValue objects to expose them in a translatable way in
OpenAPI specs. Make the same possible for request body parameters,
which previously did not expose descriptions.
Bug: T378375
Change-Id: Idd1ff0cc12129c50355186d9c1c0f50266a227f7
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This avoids dependencies on the internals of Parsoid's load/storage
mechanism for data attributes.
Documents should also not be "prepared and loaded" when running
parser tests, after d07ee3a694f3b3372aea690d9104d241082810fb in
Parsoid.
Depends-On: Ic3c09444cef51767629a9f7fac9e79351bb1fc48
Depends-On: I753bbbfaf99fb486384b0fa97de71159abb504b3
Depends-On: I07b8d6f6c3006d238093b756df418b645ebd532a
Change-Id: I9e6b924d62ccc3312f5c70989477da1e2f21c86b
|
|/
|
|
|
|
|
|
|
|
|
| |
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.
Bug: T376493
Change-Id: I8cd4f77c23c113906d2d04697b9d3680487dea0c
|