Deployed!

Verified that all these logos look good. Will schedule for the UTC late backport window today.

Deployed!

Looks like it was a bad character escaping issue, and the fact that parentheses weren't part of the escaped characters list. I've replaced the mediocre escaping method with a better (and probably overkill one) at 91d736da. I would deploy this now, but it seems like Toolforge Build Service had other plans (T373243). Will deploy whenever able.

Noting here that I'm unable to use Build Service, probably due to the same issue. Related log line:

[step-clone] 2024-08-25T22:59:56.754700588Z {"level":"error","ts":1724626796.754072,"caller":"git/git.go:55","msg":"Error running git [fetch --recurse-submodules=yes --depth=1 origin --update-head-ok --force ]: exit status 128\nfatal: unable to access 'https://gitlab.wikimedia.org/toolforge-repos/techcontribs/': Could not resolve host: gitlab.wikimedia.org\n","stacktrace":"github.com/tektoncd/pipeline/pkg/git.run\n\tgithub.com/tektoncd/pipeline/pkg/git/git.go:55\ngithub.com/tektoncd/pipeline/pkg/git.Fetch\n\tgithub.com/tektoncd/pipeline/pkg/git/git.go:150\nmain.main\n\tgithub.com/tektoncd/pipeline/cmd/git-init/main.go:53\nruntime.main\n\truntime/proc.go:255"}

Looks like it was because of a missing check prior to showing the activity chart. This affects anyone with historical contributions, but no patches owned, uploaded, or reviewed in the past year. This should be fixed with 749a84e (+ changes from 4bf3d68, because I accidentally rebased them onto the wrong patch affecting the activity chart :facepalm:), which has been deployed.

Tried to deploy with Clare earlier, but there were issues with some of the files:

• Wikisource Georgian's wordmark has some untrimmed spaces on the side which is causing it to overflow into the search bar. The font of the Commons version also differs from the one on the logo; is this intentional? Might have to follow up with the uploader and/or reupload the mark as extracted from the logo.
• Wiktionary Karakalpak's logo was too far to the left. There appeared to be some untrimmed excess on the right side from even before the file was resized.

In the interest of safety and double-checking, I decided not to proceed with attempting to deploy the rest of the patches. However, taking a look at the image files for the rest of the wikis, those should be fine and good to go. I'll triple check again tomorrow (a few hours). Will refile kawikisource and kaawiktionary patches, and then upload new patchsets for the other wikis as needed.

It doesn't seem like Superpes has been active recently, so I'm reassigning this to myself to get the other logos done. This task seems to have been mostly inactive for almost two months and it'd be nice to finally get this done for the communities of those wikis.

PR for this filed at https://github.com/wikimedia/CopyPatrol/pull/185

Indeed it was me. I think we also discussed if it was possible to use MediaViewer with TheDJ? Not sure if there was anything specifically blocking, though.

@Superpes15 Still planning to work on this soon? I can work on the rest if you're not; no pressure though.

Testing this out, there's two issues which make it a bit harder than just adding position: sticky; top: XXXpx:

1. Images are overlapping the header; z-index issue.
2. Following links to section headers leads to the section header appearing under the now-sticky header. This could be fixed with an offset; Vector '22 already does this to avoid the section headers appearing below the sticky header. I can't find the code for this though, so I have no clue how it's currently already being done.

Done. Thank you, @TheresNoTime!

Splitting off mswikisource and dtpwiki into T372031, since this was something someone at the Wikimania Hackathon approached me with. Will get that done today.

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 T364144 finally gets worked on.

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.