From reading the code, it looks like this has also affected comment notifications in the same way.

Thanks for the bug report. We should be using UTC timestamps throughout, like the rest of MediaWiki. It turns out that the DateTimeImmutable constructor may create either UTC or local timezone date-times, depending on the format of the input string, and we didn't pay enough attention to the format of the timestamp here.

Past usernames are indeed public, but there's a difference between that and displaying them prominently on the account information page. I think we shouldn't do the latter, and I'm not sure whether even the notice I proposed is a good idea.

In T424846#11946994, @matmarex wrote:

Logstash query for "centralauthtoken is invalid" (which happens often on the list=globalallusers request), to check later: https://logstash.wikimedia.org/goto/88bcb77c7c6e777f71ceff5e9ef2e803

Maybe I should have changed it to use formatversion=2 at the same time, it's much more intuitive.

You can copy-paste the discussion to another page, and everyone who subscribed to it will continue receiving notifications in the new location. (You should see the Subscribe/Unsubscribe button state reflect this when the discussion is moved/copied, and the list on https://en.wikipedia.org/wiki/Special:TopicSubscriptions should also show a link to the new page – or both pages, if the discussion exists in both places.)

Caused by a949c8305b45388b272747cc4287c3e5fb56a0a4 (https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1222751)

Logstash query for "centralauthtoken is invalid" (which happens often on the list=globalallusers request), to check later: https://logstash.wikimedia.org/goto/88bcb77c7c6e777f71ceff5e9ef2e803

I prepared a new version of mark-locked.js: https://en.wikipedia.org/wiki/Special:ComparePages?page1=User:GeneralNotability/mark-locked.js&page2=User:Matma_Rex/mark-locked.js

Copying my comment from the other related task:

This was on my mind after working on T196386 recently. I'd like to balance the transparency needs of account renamers or other people investigating renames of abusive users, with the privacy needs of the users who have been renamed.

Unfortunately will require a lot of manual review to distinguish the case where we pass an OutputPage to this function (which doesn't require passing a context) from the case where we pass a string (which does).

@Andriy.v I assume you've tested it? Thanks!

Thanks for the patch @1F616EMO!

(And it looks like there is an even older task, T52098, for the more complex cases I described above in T247241#5957890.)

Indeed it seems resolved by that work, at least for the simple cases described by @SUM1. Thanks for linking it!

Thanks, this is just what I had in mind!

I filed this as a security task just because T183212 was a security task, but I think it should be made public.

I filed T426917 for that follow-up work. I may not have the time to work on this, but I think it's fine to leave it unimplemented.

There is now a link to that documentation page in the configuration table (thanks to Zagy: https://www.mediawiki.org/w/index.php?title=Extension:OAuth&diff=prev&oldid=5198985). I think that's good enough.

FYI, my edit request at en.wp was accepted, and I also edited a similar gadget on mw.org (I'm an administrator there): https://www.mediawiki.org/wiki/MediaWiki:Gadget-edittop.js

We encountered this problem before, see: https://gerrit.wikimedia.org/g/mediawiki/extensions/DiscussionTools/+/6a7bfe2debd24e5d3fd52566eeb77f2d3aeb664a/includes/SpecialFindComment.php#105

(T389741) Comment IDs/names may use characters that are not valid in page titles, like '<'.
Omit the message with the wikilink to Special:GoToComment/… if the link would be invalid.
They can only be linked to using external links to Special:FindComment?idorname=…
or wikilinks to the target page with a fragment identifier, for example Talk:Foo#….
It's a pity we haven't realized this before deciding on this linking scheme. Oops.

It didn't seem too difficult. It helps that UrlUtils already had a way to supply a list of allowed protocols, so I only had to extend it a little.

(cross-referencing: T426614: add "CommonsFinder://" custom scheme to $wgUrlProtocols for native app OAuth2 support)

I did not get a reply, so I approved the patch myself, and I'll test it in production once it rolls out.

Indeed. Percent-encoded titles are accepted in wikitext [[...]] links (Parser.php / bce772029ecc), but not by any other APIs. This is weird; I don't think we should accept them in any new places.

We don't seem to have any API endpoints corresponding to Special:GlobalRenameQueue. We probably won't find the time for this, but if you wanted to propose a patch, we'd be happy to review it.

I can't reproduce. There must be something about your browser or your interactions with the sites that triggers this.

I don't have any devices I could reproduce this on.

I have not tested it very thoroughly, but it seems to work. Android's Talkback no longer points out the square brackets when navigating.

I agree that's weird, but it's not my fault, it was like this before. The change here only affected links generated by /* */.

IMO the root of the problem is that Title::getFragment() (and also related lower-level interfaces, like Parsoid's LinkTarget::getFragment()) does not distinguish between no fragment and empty fragment. As a result we can't distinguish a completely empty title (which should be invalid, unless maybe T374555 changes something here) from a title with an empty fragment (which represents a link to a section within a page).

The syntax with | proposed in this task's title seems difficult to reconcile with other wikilink syntax, so I merged this into another task that proposes a syntax for linking to pages of PDFs that seems more practical to implement.

Yes, but (as a global interface editor myself) I am not sure that this would be appreciated, and we must not make "any controversial edits". I am hoping that a few projects will adopt this, receive positive comments about the change (or at least no negative ones), and at that point it will be uncontroversial to apply on projects that don't have very active gadget maintainers.

No, we'll need them both :)

I added a backport for wmf.1, since that version is still live (see https://versions.toolforge.org/).

https://www.mediawiki.org/wiki/Special:Diff/8373208

May I ask you all to update (or request updates to) your local gadgets…

This is technically easy to prevent even without modern CSS features like contain; if you scroll all the way up in this task, we've had proposed patches for this back in 2012-2014.

Chasing this further, this advice is originally from @tstarling in T91820#8015440, where it was qualified with "probably".

Thanks for reporting. The warning is harmless; it will happen when the API query accesses legacy log entries, and we should suppress it, like here.

If a script uses the mw-ui-input CSS class without loading the mediawiki.ui.input module, then it won't be affected by its removal – it is either already broken, or already works perfectly. We stopped loading the mediawiki.ui.* modules on normal page views years ago.

As noted in T425988, there will probably be some deprecation warnings when you roll out the train, but I don't think this is a blocker. If it turns out to be a blocker, we can look into reverting some patches (or backporting some, if fixes become available).

The revert resolves the exception, now there is a a deprecation instead. I filed a separate task for it: T425988 (@MGChecker's patch can probably be repurposed for that one).

The revert resolves the exception, now there is a a deprecation instead. I filed a separate task for it: T425988 (@MGChecker's patch can probably be repurposed for that one).

@RoyZuo A more robust way would be to make the gadget download the image (or a thumbnail), then upload it to the search engine, instead of asking the search engine to fetch it from us, which may be blocked if they don't respect our user-agent policy.

The OPTIONS response includes this header explaining why: MediaWiki-CORS-Rejection: Unsupported header requested in preflight, generated here: https://gerrit.wikimedia.org/g/mediawiki/core/+/cfc4399d7155c88c33f00678a8dbc2971526d10b/includes/Api/ApiMain.php#1230

Updated global groups too: https://meta.wikimedia.org/wiki/Special:Log?type=gblrights&user=Bartosz+Dziewoński+(WMF)&wpdate=2026-05-11&subtype=groupprms&limit=3

Thanks @Dragoniez! list=globalusers can be used in gadgets now.