Yep; PHP is now GPL-compatible so it's totally fine to distribute built binaries under the GPL. I'll put up a patch updating the repo shortly.

Closing, this was deployed and there was no appetite (or maybe it would be fairer to say there was resistance) to delay it. Echo Chamber should be functional again for those who wish to use it.

Thanks @bd808 for approving, the tool should be usable again.

In T420154#11782718, @Trizek-WMF wrote:

What is the visible consequence for users, before and after the merge?

The new OAuth consumer is pending approval: https://meta.wikimedia.org/wiki/Special:OAuthListConsumers/view/56797921b0a88d17f8ea5d338f04b11d

I don't think it needs a tech news announcement personally, mediawiki-api-announce would be more appropriate.

Sorry, I didn't realize that the plan was to roll it out this week. I personally don't care very strongly about this (when I worked on Notifications like a decade ago it seemed pretty clear that they were ephemeral!), I mostly created the tool because MatmaRex asked for it in T383948#11625527 and it seemed fun. Not sure if he qualifies for Amir's request for "one user on any wiki" :-)

https://meta.wikimedia.org/w/index.php?title=Tech/News/2026/13&diff=prev&oldid=30270406

Heh, thanks for trying the tool so quickly :) Apparently a middle click went awry.

In T383948#11666369, @Legoktm wrote:

In T383948#11625527, @matmarex wrote:

Also, I wish we could document a way to export your notifications before they're gone. I think the action=query&meta=notifications API would be an acceptable way to do this, were it not for the fact that it is limited to 50 notifications – could we temporarily increase this limit to 2000? (perhaps with a rate limit to avoid issues) [I can write the patch for this]

I think it would be more useful to have a JavaScript snippet, possibly hosted as a Toolforge tool, which handles the continuation to fetch all notifications instead of temporarily raising the limit.

In T383948#11625527, @matmarex wrote:

Also, I wish we could document a way to export your notifications before they're gone. I think the action=query&meta=notifications API would be an acceptable way to do this, were it not for the fact that it is limited to 50 notifications – could we temporarily increase this limit to 2000? (perhaps with a rate limit to avoid issues) [I can write the patch for this]

Fixed in https://gitlab.wikimedia.org/toolforge-repos/fast-ec/-/commit/6d825f760b96f9c6004d976aaf2e660d95561639.

My main intent behind SecureLinkFixer was to avoid having bots constantly needing to edit basically every single page a bunch of times as websites gradually added support for HTTPS. So that's how I approach it, as much as reasonably possible it should be as if the actual wikitext URL was HTTPS. In practice the Linker hook already existed so that's what I used and ideally we'd be able to preserve that behavior (I'm a little out of date and don't know what OutputTransform applies to or doesn't apply to). I would expect that e.g. my bot that fetches Parsoid HTML would see URLs already modified to HTTPS.

In T418288#11648205, @Prototyperspective wrote:

@Legoktm You mean this would have to be solved by Commons admins? Or by who? And that was just an example, lots and lots of bot accounts do not have that flag. It does look like a technical issue. How to solve this?

This is an on-wiki issue, that account isn't flagged as a bot: https://commons.wikimedia.org/wiki/Special:UserRights/File_Upload_Bot_(Magnus_Manske)

This feels like a dissatisfying ending to a feature that's been on Wikipedias in one form or another since 2004. I was surprised to see it gone so quickly but also I forgot that I turned off compact links years ago, so maybe sorting is irrelevant to most users. I get the tech debt rationale broadly, but T253764#11632202 doesn't feel convincing because it's just static data that seems like it should be straightforward to have auto-generated instead of manually maintained (then again, no one did that for 20+ years so...).

It's back up now, sorry about that.

Was any integration or regression test added for this?

It's fixed :) https://en.wikipedia.org/w/index.php?title=Wikipedia:Articles_for_deletion/Purananoorru&diff=prev&oldid=1338973451

One question regarding editing, if I want to change the ID on the duplicate element, should I modify data-x-id or id (which is Parsoid generated)? And if it's the latter, should I delete data-x-id?

There's now https://gitlab.wikimedia.org/repos/mwbot-rs/rocket_mwoauth. It's being used in the masto-collab tool.

In T413375#11600956, @Bugreporter2 wrote:

You could just edit properly and not use VisualEditor.

I guess T148274: Implement a convenient way to link to ISBNs without magic links should be duped into this issue now?

Based on https://en.wikipedia.org/wiki/Wikipedia:Bots/Noticeboard#c-The_Anome-20260204155000-Legoktm-20260204003800 this seems like it was a misunderstanding on what was going away.

I don't have a strong opinion on how this is implemented (really I haven't thought about it), I do want to flag one potential area for improvement though. The signature for the hook is:

public static function onLinkerMakeExternalLink( &$url, &$text, &$link, &$attribs, $linktype ) { ... }

In T412630#11563619, @Redmin wrote:

Personally, I have been running my bot on bnwikibooks to just add color declarations wherever Linter complains about them being missing,

In T412630#11555962, @Jonesey95 wrote:

The template is perfectly readable in both dark mode and light mode, despite the lack of an explicit color declaration alongside the bgcolor declaration. Furthermore, when I inspect the problem element, I see that color:black is indeed being assigned to it, inherited from the .infobox parent element. So the element that is tagged as missing a color actually does have one, and it's working fine.

Edited the description to use the category names instead of the numerical IDs.

Trying to edit https://te.wikipedia.org/wiki/%E0%B0%AE%E0%B1%82%E0%B0%B8:Message_box gives "Scribunto module" content is not allowed on page మూస:Message box in slot "Main" which feels related but might be a distinct issue?

I wonder why page_content_model was wrongly set though. Is this the same issue as T108663#1741046? :/ If so, might be worth resurrecting a modified version of https://phabricator.wikimedia.org/source/mediawiki/browse/REL1_43/maintenance/fixDefaultJsonContentPages.php;848a9f279f42ed0edb0c83bde65254585bc829cb but for Scribunto.

This is basically implemented now, I think there are still some rough edges, like the save page message not indicating what wiki the page was saved on, but I've been using it for the past few hours and it's pretty functional. Thanks to @XtexChooser for doing the first part in mwapi last year :)

Please re-open if that wasn't sufficient.

P.S. I added you to https://www.mediawiki.org/w/index.php?title=Mwbot-rs&diff=8101926&oldid=7828836, please feel free to update it if you'd like to be credited differently. I couldn't find a wiki account under your username so I linked to gitlab.

Sorry, I had missed your initial ping. Thanks for the patch, it's great!!

@GalStar no objection to moving it in the monorepo, I had kept it separate since it didn't have any intra-project dependencies whereas most of the monorepo depends on each other.

Thanks all!

In T392834#10773349, @elukey wrote:

elukey@mwmaint1002:/home$ sudo du -hs /home/* | sort -h | tail
...
11G	/home/legoktm

The home dirs may be a quick one for a cleanup, we have a total of 62G used there, but there are few big ones.

@Legoktm

In T382424#10415772, @Ammarpad wrote:

It's not limited to this particular parser function and the problem did exist before its introduction.

It seems the same reponse format from the parser is used for 'invalid input' and 'function not found' cases, and so Scribunto has no way of differentiating these.

I've started https://www.mediawiki.org/wiki/Extension:Scribunto/New_Lua_version. Please add other new Lua features that would be useful there (I've already copied @Od1n's comment above).

In T178146#10738397, @Reedy wrote:

@tstarling Got any updated opinions about this in 2025?

I pushed a 1.2.0 tag. On the production side, there's nothing worth upgrading for.

In T374683#10623045, @daniel wrote:

Report for what incident? The missing ETags? The handling of the redirect parameter? Both were regrettable bugs, but not substantial operational issues or problems with broad impact on users.

Also, is "puppet groups" a good label for this? Is there a better term?

Let's do it. Here's what I rigged up locally (will push to GitLab in a bit).

See T319104: mwbot-rs: Support operation on multiple wikis. I had always imagined that mwbot would have the logic to support multi-wiki operation and mwapi would continue to stay single-wiki for simplicity. I'm not really fixed on that concept and would love to see some progress on this, so feel free to give it a shot.

In T385156#10513430, @thcipriani wrote:

Also IANAL the privacy policy seems ambiguous here to me.

To expand on that, if we think it's older cached content, shouldn't there be a corresponding change that has fixed it for new entries? And given there's a max time limit on varnish content, said change would've needed to be deployed within that time window.

@HCoplin-WMF is there a reason no incident report was ever written for this? (If it was, I couldn't find it when searching https://wikitech.wikimedia.org/wiki/Incident_status)

In T357603#10505456, @akosiaris wrote:

I 'll take a closer look tomorrow but this is indeed possibly older cached content. See for example

The endpoints don't seem to always be equivalent. For example, a POST request to https://en.wikipedia.org/api/rest_v1/transform/wikitext/to/lint/User%20talk:Loganwasgood returns:

[{"type":"night-mode-unaware-background-color","dsr":[59,7185,47,2],"templateInfo":null,"params":[]},{"type":"night-mode-unaware-background-color","dsr":[241,2032,95,2],"templateInfo":null,"params":[]},{"type":"night-mode-unaware-background-color","dsr":[339,2029,213,6],"templateInfo":null,"params":[]},{"type":"night-mode-unaware-background-color","dsr":[2033,7182,47,2],"templateInfo":null,"params":[]},{"type":"night-mode-unaware-background-color","dsr":[2081,4771,111,0],"templateInfo":null,"params":[]},{"type":"night-mode-unaware-background-color","dsr":[2193,4771,83,2],"templateInfo":null,"params":[]},{"type":"night-mode-unaware-background-color","dsr":[4772,7179,114,0],"templateInfo":null,"params":[]},{"type":"night-mode-unaware-background-color","dsr":[4887,7179,83,2],"templateInfo":null,"params":[]}]

Closing as declined since I don't think we can support this until Parsoid supports editing parameters as HTML instead of wikitext. (Please re-open if I'm mistaken)

This is done in parsoid 0.10.0-rc.4; aiming to do a stable release soon. I was peeking at the git log and it was a team effort by myself, xtex, mirror-kt and CountCount :)

In T295648#7504773, @matmarex wrote:

(The code doing that can do it to Parsoid HTML too, and it will need to be introduced when we start trying to use Parsoid HTML for page views, but we didn't need it so far, so it's not there.)

@Peachey88 should be fixed now, I've worked around the MW bug.

See T374683#10495069.

For better or worse, all the requests I've tried on test.wikipedia.org are returning etags 🙃

This has become a much bigger issue because RESTbase is now redirecting to the REST API.

I found T357603: REST API: ETag missing from some responses from page HTML endpoint which seems to be the cause. In the prior example, when I remove ?redirect=false, an etag shows up:

$ curl -I 'https://en.wikipedia.org/w/rest.php/v1/page/Wikipedia%3ARequests_for_adminship%2Ftheleekycauldron_2/html'| grep etag
etag: W/"1170967427/fbb0a9e1-da83-11ef-9f0b-99a171ff8019/view/html"

In T374683#10469299, @daniel wrote:

In T374683#10460920, @Legoktm wrote:

I didn't see a linked patch for the etag stuff but I assume someone checked/addressed it? I can't reproduce the failure on test.wikipedia.org.

The page/html endpoint returns an etag. There's no patch because that didn't change - as far as I can tell, it has been returning etags for a long time. What failure were you trying to reproduce?

In T374683#10457996, @HCoplin-WMF wrote:

@Legoktm -- do you have any final concerns? If not, I think we should be good to go :)

In T354037#10397337, @daniel wrote:

@Legoktm There may be no need for stashing or etags at all if you use the output of https://en.wikipedia.org/w/rest.php/v1/page/Earth/html?flavor=edit. flavor=edit makes it embed all the parsoid annotations in the HTML, which should allow the transform endpoint to turn HTML back into wikitext without the need for stashed state.

How do we move forward here @daniel?

There are both security and legal issues here.

In T383533#10452837, @dchan wrote:

Thanks @Legoktm! Hmm, this is technically tricky because the source is in typescript, which would require a whole extra compilation system in our build process. But I think we are ok because:

1. PeerJS is MIT licensed
2. VisualEditor is MIT licensed

Time is a flat circle, back to loading extension information from PHP it seems :) This was proposed as part of the original RfC even:

Reading and parsing a JSON file will be slower than loading a PHP file due to APC and other factors. However, we can mitigate that by providing a script to "compile" all the required JSON files into their PHP equivalents.

I released mwapi 0.6.1 by backporting just this fix. Thanks for reporting!

For some reason multipart::Part::stream wasn't working, when I switch it to:

I spent a few minutes looking at this today, I started by getting:

In T374683#10297761, @daniel wrote:

The responses were also not returning an etag header, as previously expected.

That shouldn't have been the case... you are seeing the etags now, right?