I completely missed Hooks.php! Guess I'll file another patch to cover that one... 😅

I don't have the permission to edit Campaign-namespace pages on Commons. @Robertsky (or anyone with the right perms lurking), can you test if this is still an issue on your end?

Experiencing the same thing on Jueteng; everything below the etymology sections seems to be greyed out. I checked the source and there's nothing popping up I can see that should be an issue.

Might be better to just attach the mw-disambig and mw-redirect classes to these and allow user CSS to style them, just like we normally do on parses. Not sure how expensive that might be performance-wise.

Found a temporary solution. This should work for now until T365144 goes through.

Bad news: the way the filter works is inherently incompatible with QueryBuilder.

Got this checked by a DBA to make sure it's safe, see T364144 for the general sentiment.

I've got the previous patch working on the latest commit of Nuke (as part of Wikimedia-Hackathon-2024), i.e. converted it to use the new QueryBuilder system. Lots of reusable stuff, so might as well just improve that patch rather than create a new one. Uploaded it under the same patch (541077).

In T43351#9767132, @Samwalton9-WMF wrote:

I think this is worth putting in Tech News:

Nuke will now correctly delete pages which were moved to another title.

I've updated Xiplus' patch to work on the latest revision of Nuke for Wikimedia-Hackathon-2024. Nuke was migrated to query builder some time ago so I've changed it up to use that.

Should we rename this task, @Sportzpikachu? Considering we only really have one choice for internationalization (per T348406).

Biggest blocker for this has been resolved (link). The Great Refactoring is upon us.

Probably related to the 17 hour replication lag for enwiki right now, similar to T362725. Root cause appears to be an issue with the replicas (T363077).

De-assigning until I can dedicate more time to this. Here's a summary of where I'm at though:

More information on how developers can react to the changes can now be found at mw:Trust and Safety Product/Temporary Accounts/For developers. I'll try to work on this, among other things, this week and next week.

Looks like this has been fixed. I can confirm that the CC BY-SA 4.0 text now shows up on the Android app. page-talk-page-subtitle in ruwiki PCS i18n data also reflects the latest from TranslateWiki. Marking this as resolved, unless something else comes up.

In T356704#9556128, @Tgr wrote:

If you want to debug what's happening, I think your best bet is checking out Quibble so you can run the test in the exact same environment it runs in on the CI servers, but with a debugger enabled.

Sorry for the relative silence! The year kicked off pretty busy for me. I'll be much more available now though.

This is an issue with RedWarn, as Ultraviolet doesn't have a right-click menu (as of now). We'll make sure this is fixed in reimplementation.

Can't seem to replicate this locally, or at least I know too little of the configuration to ensure that I'm replicating this properly. The page is undeleted with no issues. But the debug log it spat out corroborated what I wrote above.

I checked Flow but it was mostly localization and npm updates, so I wasn't ready to blame it just yet. In my head, this loop being interrupted by the teardown was pretty odd, and I focused on that instead.

Been investigating at https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PageTriage/+/997634 by putting a bunch of log statements in and I'm a bit stumped. Here's where I'm at:

You'll need the ORES extension installed and active, if it isn't already. The copyvio tag is, for some reason, attached to ORES being present in the wiki. Without it, PageTriage just skips searching for the copyvio tag entirely. Setup is here, to save you a few clicks.

Definitely related. Selecting the "copyvio" filter and any other filter on the new pages feed causes this issue to show up. The copyvio tag is JOINed separately from the rest of the tags, which in turn causes the reference to ptrpt_tag_id at ApiPageTriageList.php:577 to become ambiguous if both the copyvio tag and some other tag (newcomer, learner, etc.) have been requested.

Possibly related to T354894? The request URL matches the one on that task and it was opened just recently (though the logs here look like the underlying issue for that task).

Seems like it's happening when the "Copyvio"/"None" possible issue filter is paired with one of the "Were created by" filters (newcomer/learner/etc., except "Autopatrolled users" and "Show all"). This was reported for wmf.12 but it's still happening to me right now (seems like wmf.13 was deployed just minutes ago).

Caused by on-wiki changes, namely a flood of new version numbers on the Wikidata item for the page. At least it wasn't anything more serious.

We should also make sure to handle cross-origin requests (Access-Control-Allow-Origin), at least for Wikimedia sites. Otherwise, another external tool would be required to call these endpoints whenever they're needed from the browser side. In addition, we'll need to prevent cross-site request forgery (CSRF) through single-use tokens. That probably also needs an endpoint.

In T353076#9425326, @SD0001 wrote:

For mw.messages and mw.user.{options,tokens} which are indeed stable interfaces, we should be better off temporarily monkey-patching them so that each supports .has. In terms of JS cost, it should be a net positive as the three shims are together smaller than the mw.Map implementation.

Yeah, that seems like a sounder solution.

Backported, tested by @MPGuy2824, and messages are being posted now (check; link from @MPGuy2824). Thanks to everyone involved!

Added to Monday morning's backport window, but I don't have patroller/sysop on testwiki. @Novem_Linguae, @Soda: One of you might have to test the patch instead. Feel free to replace the requesting IRC nick or move the patch to a different window (n.b. I'll be unavailable starting 11:00 UTC as I travel for the holidays, so I won't be able to help test during the afternoon or late backport windows on Dec 18).

I thought mw.Map probably isn't covered by the frontend stable interface policy since it's a private class, but I realized that mw.messages, mw.user.options, and mw.user.tokens all use mw.Map. When the time comes that we shift those to using native JavaScript Maps, we will break a lot of gadgets which call .exists. We should tread carefully when executing this deprecation.

Yeah, revert seems easiest. In light of the above, it's probably better to switch from mw.Map to Map when the question of how .exists/.has will be handled is answered, or when we know that core can definitively support native JS maps. Discussing the changes to be made on core seems like it'll take time.

We should probably also add in tests to ensure that anything using mw.Map works with normal JS Maps. mw.Message apparently can't handle normal JS Maps, so that ended up breaking PageTriage (see T353571 for details).

That may be true, but if I'm not going to use an instanceof and will change mw.Message to call .has, it would break every other thing using an mw.Map since it doesn't have a .has function, and we can't search for all use cases doing this to be able to safely switch to using just .has (CodeSearch doesn't find uses in gadgets, userscripts, extensions not hosted on Gerrit, etc.). It's better to add that alias for now to avoid breaking things and for backwards compatibility, and then remove mw.Map as a whole later on, when we've announced its deprecation and we're ready to remove it (tracked in T353076).

Oh, there's actually two solutions to this. One is to revert the aforementioned commit and restore the use of a mw.Map, or change core to ensure that it works with normal JS maps. That itself has two solutions: change the behavior of mw.Message.exists depending on the map used using instanceof, or switch that function to use .has and then add a .has alias on mw.Map which just calls .exists. The latter seems best here, since it means other extensions/tools/etc. would be able to use native JS maps and not fall into the same issue.

@Novem_Linguae It seems to have been broken by this commit. .exists doesn't exist for native JS Maps, but only mw.Map maps. Should be a simple replacement; I'll have a patch filed in a sec.

We already have some of our repos at Ultraviolet on GitLab, so I can answer a few of @Novem_Linguae's questions based on my experiences working on it.

Thank you for reviewing (and getting them additional reviews) as well, @matmarex! :)

From what I've seen on the help desk (1 2 3 since my last comment here), VPT, and TEA (1 2), there's also a mentions of a Wikimedia\Rdbms\DBTransactionSizeError happening intermittently. The issue seems to appear on specific articles, with (as of now) no discernible pattern in what articles are impacted. It also just clears itself after some time, but there's been reports of this as recent as 10 minutes ago.

Also dropping here related request IDs from the help desk:

• c867a72e-ac5d-4b74-ad11-bd9084c0a12d
• 3228d684-e259-477d-a359-db71698e5abd
• bb5ad4fc-e7b2-411b-92a8-78201adada13

I've submitted https://gerrit.wikimedia.org/r/979440 to remove the dataType field in mw.Rest AJAX calls. This does, however, mean that any REST endpoint that returns an improper Content-Type header may cause JQuery to return a string for a JSON response. I'm working on https://gerrit.wikimedia.org/r/979441 to add Content-Type checking to REST API tests, so that this could be caught before it has any impact on the client. I'll take it out of WIP when I'm finished.

cc Parsoid, since this seems to be an issue specific to the newly-introduced endpoints in T350661.

Oh, looks like I haven't subscribed to any of those lists. 😅 Re: wikitech-l, Tech News is sent there every week, but it wouldn't hurt to also have a dedicated announcement for it so it's easier to find.

Think this might be worth a User-notice, given that it affects volunteer-run tools as well (can't definitively call this as I don't have analytics access). Tool maintainers need to update their package versions to properly filter out the canary events (to v2.1.0 for npm@wikimedia-streams and to whichever version closes T350756 for Pywikibot, when it gets closed). Volunteers like me also don't have access to the Slack announcement, so that probably won't be enough to get the word out to volunteer developers.

@Ottomata Also good here. Canary event filtering was released as part of v2.1.0 in wikimedia-streams, and around a month of time post-announcement should be enough for (maintained) dependent projects to update.

cc @Chlod for JavaScript wikimedia-streams client.

Hmm, perhaps allowing copying isn't the solution here, as it involves another button press. Two things I see that we could do here:

• Upon finding a new diff, store the saved edit summary, then redirect to the new diff. Upon pressing the rollback button again, pre-fill the text input box with the typed-out reason.
  • This only ever requires local storage (or perhaps IndexedDB), so not so expensive.
• We could also just steamroll revert the target user's edits, but this could cause some collateral damage.
  • This should only ever be considered if "rollback" was selected instead of "rollback-like" in the options.
  • This applies the revert immediately, unlike the first option which requires another page load.

Adding in Wikipedia-Android-App-Backlog here since the Android app is affected. Haven't tested on iOS (as I don't have an iOS device). Page Content Service only has two members and one watcher, so there may not be a lot of traction if this were the only tag on the task.

Will submit the patch in a bit, thanks for checking it out! 😀

I was the one screaming pre-emptively on le Discord, previous comment about this on T334238#9119834. I didn't even know that this was the right task to make the comment on. 🤦

Going to pop in here and stay ahead of breaking things for editors (since that seems to be the plan with T335513).