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?

A limit of 5 edits per minute is incredibly slow (considering RESTBase let us run at 200 pages per second).

In T374683#10295353, @daniel wrote:

Bill correctly identified the root cause: the core endpoitn expects redirect=no (for consistency with index.php), while RESTbase expected redirect=false. We can just accept both, see https://gerrit.wikimedia.org/r/1087568.

In T354037#10295304, @daniel wrote:

When fetching HTML content for editing, use stash=true. That should return an ETag that can then be used with if-modified. I just tested it, it seems to work. Conversion of HTML that was fetched without stashing is unreliable, and always was. RESTbase was just more agressive about practive caching.

In T374683#10294780, @Legoktm wrote:

I'll give the revert ~20 more minutes to roll out fully and report back to see if things are fixed.

In T374683#10294694, @HCoplin-WMF wrote:

@Legoktm -- this was 100% an unintended breakage that we are working to resolve as we speak.

Most of my bots and tools that used RESTBase are now broken, and I suspect this is the cause based on timing. I expect there are probably 20-25 tools that are broken, and a similar number of bots across a number of wikis.

Upload does not go through, and Some("TODO".to_string()) is returned instead

Should be fixed now, I bumped up the memory: https://wikitech.wikimedia.org/w/index.php?title=Tool%3ARustup&diff=2240867&oldid=2236350

Sorry Magnus! I thought I had fixed this but guess not.

If you use the job framework (see https://wikitech.wikimedia.org/wiki/Help:Toolforge/Jobs_framework), there's a mariadb image which contains mysqldump.

In T378886#10286594, @Pppery wrote:

To be clear, I'm not blaming either of you - just highlighting a process failure that should be addressed.

Thanks for getting the update done; do we know if this is exploitable and merits backports?

The new ccorg interwiki has now been added, so I've submitted two patches:

• https://gerrit.wikimedia.org/r/1082873 <-- updates license text right away
• https://gerrit.wikimedia.org/r/1082874 <-- adds a new message; once deployed we can migrate https://commons.wikimedia.org/wiki/Template:Cc-pd-mark-footer (10M transclusions)

In T347982#9825643, @Reedy wrote:

The general lack of output on the command isn't helpful either:

our open source virtual event platform for Wikimania (eventyay.com)

In T377497#10255164, @Pppery wrote:

I'm not 100% sure what the purpose of allowlisting is here.

I think the point is to allow people to upload only from sites known to have free licenses to prevent upload-by-url from being misused as a vector for copyvios.

The Phabricator part of this was deployed, so we should be all set here!

with linter_cat = 25

Thanks, just deployed: https://gitlab.wikimedia.org/toolforge-repos/ldap/-/commit/7b5baa2b2f25f2ba2e88070bff8319fb20a062f4

I believe I filed this ticket because certain developers were strongly pushing the use of query builders in MediaWiki, so it seemed like a good general pattern for tools too. Maybe the tool author can check in with one of those MediaWiki developers for help? :)

In T376769#10223261, @matmarex wrote:

Hmm, they’re not even 404s, but 500s for me. Both the space and the ‘ń’ seem to cause that.

Deployed https://gitlab.wikimedia.org/toolforge-repos/ldap/-/commit/99594edfa46508acc8d3f286472e6f2dbd8c08e9

Ack, thanks for the explanation. I'll create a new /cn/ route then and will send a MR to update Phabricator's links too.