I assume this is done, but I couldn't verify it.

Came to say this would have been handy many times already...

It seems tricky, but it can rewritten to something like this (maybe it can be generalized to a utility function?).

Then, the workaround is to either remove the link or change it to [[:User:$1|$1]] (note the colon). Mentions in edit summary are not sent for reverts. Notice though that the edits look like rollbacks, but they are actually not.

What kind of notification is it? "your edit has been reverted" or "mention in summary"?

DiscussionTools implement that using the discussiontools-signature-prefix message. I also found sig-text (core) and wikieditor-toolbar-help-content-signaturetimestamp-syntax (WikiEditor (2010)).

Though this can't be reproduced in markup here, the title attributes (tooltips) of the timestamps are also wrong: they're set to the name of the category, not the linked pages themselves.

You are right. The root problem is we let it insert a nonexisting user as an IP address. And it needs to be fixed.
It cannot be fixed using "interwiki pointing" you mention, though. Because "interwiki pointing" would not create the user, either.

Noticed right now. Apparently, RevisionStore::getRevisionSizes cannot load from archive.

After another similar report T372556: Article creation not recorded in RecentChanges database table, I tried to find all possibly missing recent changes entries to look for clues and how often it probably happens. I did it on Wikidata as it's the most heavily edited wiki.

I agree having a wrapper around DataSite.save_claim would be useful. I just disagree with the proposed solution. There is no point in adding this method to MediaInfo since DataSite.save_claim does not need the entity object at all.

We don't have ItemPage.changeClaim either. DataSite.save_claim is wrapped around by Claim.changeRank, and there is also Claim.changeClaimTarget which should already work for all entity types.

This feature has been removed.

Thanks! The bots are now indeed back.

the In the news section still starts with July 31. Not sure what's up with that.

This morning (CEST), I visited my favorite wiki's main page and was shown a cached version from yesterday (2024-07-31). So I took a snapshot of the debug comment:

<!-- 
NewPP limit report
Parsed by mw‐web.eqiad.main‐5ffbbd4f55‐hlpc7
Cached time: 20240731111040
Cache expiry: 3600
Reduced expiry: true
Complications: [no‐toc]
CPU time usage: 0.345 seconds
Real time usage: 0.468 seconds
Preprocessor visited node count: 4056/1000000
Post‐expand include size: 53226/2097152 bytes
Template argument size: 13576/2097152 bytes
Highest expansion depth: 15/100
Expensive parser function count: 16/500
Unstrip recursion depth: 0/20
Unstrip post‐expand size: 2104/5000000 bytes
Lua time usage: 0.060/10.000 seconds
Lua memory usage: 1460527/52428800 bytes
Number of Wikibase entities loaded: 0/400
-->
<!--
Transclusion expansion time report (%,ms,calls,template)
100.00%  276.223      1 -total
 80.62%  222.704      1 Šablona:Nejnovější_aktuality
 39.88%  110.165     11 Šablona:Aktualita_úmrtí
 38.10%  105.249     11 Šablona:Aktualita_úmrtí/výstup
 28.34%   78.286      8 Šablona:Aktualita
 25.48%   70.372     15 Šablona:Flagicon
 18.04%   49.819     22 Šablona:Delink
 10.09%   27.877      1 Šablona:Nejnovější_aktuality/Box_s_odkazy
  9.31%   25.713      1 Šablona:Vseznam
  8.73%   24.119     15 Šablona:Flagicon/core
-->

In T367638#10023959, @Wargo wrote:

In T367638#10022975, @matej_suchanek wrote:

If we cannot assume the user exists locally, what should be done?

Or some interwiki pointing. The action is done using account on external wiki, so that account should be linked anyway. To be handled by CentralAuth and their hooks?

It seems two problems meet here:

Could it be accounts created by email? I.e. log_action = 'byemail'. Or log_action = 'create2', too.
In these cases, the actor is the user who creates the account, not the account created.
Try query for log_namespace = 2 AND log_title = REPLACE(user_name, ' ', '_') instead.

In T303433#10017793, @kostajh wrote:

In T303433#9980959, @matej_suchanek wrote:

Yes, every change to a filter in fact resets its throttled status.

But let me make one thing more clear. Now, only "local filters" are actually throttled. A global filter is considered "local" only for metawiki. Not sure if this is a bug or feature, anyway this is how it works right now.

If I understand correctly, this means that if someone create a global filter on metawiki to show a CAPTCHA for all edits, and this filter is triggered on e.g. enwiki, then the creator of the filter will receive the "throttle notification" whenever this limit is reached on enwiki?

Yes, every change to a filter in fact resets its throttled status.

This has recently again become an attack vector for abuse, so I'm reviving this task.

T368203: Abuse filters with array index access cannot be saved anymore: "MediaWiki\Extension\AbuseFilter\Parser\Exception\UserVisibleException: notarray" should be fixed in wmf.13, yet you report wmf.12.

In T303433#9971774, @JJMC89 wrote:

Rate limiting those notifications (maybe max 1/filter/hour?) or being able to disable them would allow us to decline this task.

In T307828#7911251, @matej_suchanek wrote:

But CentralAuthForcedLocalCreationService::attemptAutoCreateLocalUserFromName cannot pass the authority further because neither CentralAuthUtilityService::autoCreateUser nor AuthManager::autoCreateUser support that.

In T368203#9916180, @suffusion_of_yellow wrote:

Brainstorming here, but if all we're interested in is the names of any variables that might be used, is it really necessary to evaluate the filter? Maybe just extract the names from AbuseFilterTokenizer's output instead?

Having reproduced locally, I found it is this exception. The type is null (no variable has a value). Maybe it should handle DNULL in the same way as DUNDEFINED?

T307827 mentions AF194, too. So I think it is the same problem.

Down to 1038: https://performance.wikimedia.org/xhgui/run/view?id=66730ec0d13d323f52dc193f. (Note that the count may be different for different users and may change over time as the original link is not permanent.)

In T367463#9894557, @Jdlrobson wrote:

Out of curiosity, why are all those images linked e.g. wrapped in A tags (in comparison to https://en.wikipedia.org/wiki/Template:Routemap) - is there an on-wiki reason?
(Please also see the NOTE at the top of the task for a temporary workaround)

In T367172#9887402, @Jeff_G wrote:

Why is experience level important when displaying watchlist?

Something like https://commons.wikimedia.org/wiki/Special:ApiSandbox#action=watch&format=json&unwatch=1&generator=watchlistraw&formatversion=2&gwrnamespace=6&gwrlimit=500 can remove them in batches (of 500).

It was probably copypasted nonsense from the beginning because cleanupUsersWithNoId.php would clean up only core tables...

In T367144#9883492, @Ladsgroup wrote:

Fixed commons. Let's see what's next.

I'm still super confused, but I think the corruptions might be related to RenameUser. AbuseFilter did not support RenameUser until 65708afcea842c696726883ab3c13f75cf5066bb, so old af(h)_user_text are still in the database. Maybe the maintenance script is complaining because of this? Also, if there was a database import, the renamed users wouldn't propagate from prod to beta, right?

@Ladsgroup would report similar errors on the first run: T336224#8838909.

It would be good to know something about the query plan and also about your watchlist. I noticed the URL includes namespace=6. What portion of your watchlist are files?

Steps to reproduce:

This task mixes two kinds of things.
-withoutinterwiki corresponds to https://en.wikipedia.org/wiki/Special:WithoutInterwiki. It is not a filter, it is a generator. Let's not touch that argument.
-ns(:not) and -titleregex(not) are filters. There is also -grep(not) and -onlyif(not). If anything, these should be unified.