User Details
- User Since
- Oct 10 2014, 8:08 AM (476 w, 5 d)
- Availability
- Available
- IRC Nick
- dues, duesen
- LDAP User
- Daniel Kinzler
- MediaWiki User
- DKinzler (WMF) [ Global Accounts ]
Yesterday
Mon, Nov 27
The underlying problem is that the REST framework uses MessageValue is was intended as a nicer replacement of Message. MessageParam works with MessageValue, but not with Message. The two should be made to work together more nicely...
Sun, Nov 26
Wed, Nov 22
See T351411#9338177 for some scenarios
Tue, Nov 21
To clarify a few points:
Sun, Nov 19
Fri, Nov 17
Looks like this is an actual bug. https://github.com/wikimedia/restbase/pull/1337 should fix it.
@Legoktm This works now:
curl -X POST -F "html=test" 'https://en.wikipedia.org/w/rest.php/v1/transform/html/to/wikitext/Mwbot-rs%2FDISPLAYTITLE'
The transform endpoint is now live, e.g. at https://en.wikipedia.org/w/rest.php/v1/transform/ (POST only).
But the key question is: would that speed up overall test times (for a subset of patches)? And, if so, would it result in broken builds when we run the full test suite?
Thu, Nov 16
Wed, Nov 15
Tue, Nov 14
@Jdlrobson @Gehel The fist step is to figure out where this should live, and who should own it. Ideally, APIs should be owned by the team that maintains the underlying logic (Cirrus), or team that maintains a similar component (RelatedPages), or a the team that consumes the API (native apps). The API Platform team can assist, but should not end up owning specific APIs.
Mon, Nov 13
Sun, Nov 12
Fri, Nov 10
According to Turnilo, the endpoint is used mostly by the Wikipedia app, and I suspect that it was built for that purpose. Maybe that means the Apps team owns it?
Thu, Nov 9
I disabled the tool.
I made a pull request: https://github.com/wikimedia/restbase/pull/1336
I think the fix for now is to return a 404 instead of failing hard.
Note that with this fix, page/MediaWiki:Editcheck-config.json will return a 404, but page/MediaWiki:Editcheck-config.json/html will return the rendered message (modulo a fix for T349868). That seems ok to me, but it means that page/MediaWiki:Editcheck-config.json/with_html will also return a 404. That's a bit awkward.
A while ago, I wrote a doc about why creating wikis is hard: https://docs.google.com/document/d/1EyRfxM39srUGB1bFt_8W36Lthqw8BXrKqnL8se_mgng/edit
The immediate cause of the error is this:
- HtmlOutputRendererHelper::getETag() calls getParserOutput(), and then calls ParsoidOutputAccess::getParsoidRenderID() on the ParserOutput object returned from getParserOutput().
- ParsoidOutputAccess::getParsoidRenderID() calls getParsoidRenderId() on that ParserOutput, but gets null and throws an InvalidArgumentException.
The ruprecht tool is still running on the grid engine. If it's no longer used, please stop the grid web services and/or properly delete the tool.
Wed, Nov 8
Tue, Nov 7
@santhosh ok, I filed T350661: Expose parsoid transformation API from MediaWiki core. for enabling it.
Mon, Nov 6
Some thoughts on this:
Required changes in MediaWiki Core: sandbox/urbanecm/community-configuration in Gerrit, see Gerrit
If there is anything we didn’t consider and we should know about, please tell us in the comments in this task.
Upon invocation of a maintenance script, Community configuration 2.0 converts the content of the wiki page.
In that direction three libraries have been evaluated and the current proposal is to use Opis/json-schema
I agree that #1 seems like the most future proof approach.
Fri, Nov 3
I imagine that for most, if not all, of these a redirect follow would generally not retain a Host: header from the first request.
Thu, Nov 2
Wed, Nov 1
In tools that perform edits (VisualEditor, DiscussionTools), I should see the block message, not an unrelated error.
We'll want a fresh start on dependency analysis. The Ruprecht projet was an early proof of concept.
The issue seems to be that the parsoid endpoints send a full URL in redirect responses, e.g. when redirecting from a page URL to a revision URL, e.g. /page/html/Dog to /page/html/Dog/12345. Since the target URL uses an external domain name, it will not be routed to the parsoid cluster, where the Parsoid extension is enabled on MediaWiki. The request will instead be routed to the public API cluster, where the relevant endpoints are unavailable, resulting in a 404 response.
Mon, Oct 30
This seems to only fail for messages that have non-wikitext content. This works fine, even though it's overwritten: https://fr.wikipedia.org/w/rest.php/v1/page/MediaWiki:Abusefilter/html
I'll take a look in a bit
I haven't done this yet, but I would recommend limiting these to autoconfirmed instead
Oct 25 2023
I made a patch that allows groups to be specified in a gadget definition, e.g.
Ah, I was unaware of this mechansim in Gadgets. Thank you for the explanation.