I think we should consider updating the min-version setting on Wikipedia if/when this issue is fixed.

Interesting, possibly related, HG 3.4.4. Clearly a technical issue, proven by the edit summary: https://en.wikipedia.org/w/index.php?title=Jason_Kenney&diff=884940008&oldid=884939997

I think I have an example use case that I'd need right now: I'm creating a global userpage on meta.wikimedia.org and would like to add a globally working "Add new message to my talk page" link. This does not seem to work without having a local page that can be accessed using an internal wikilink to execute the action. Any magic words are parsed on Meta before being displayed on the other wikis, external links are unflexible, but wikilinks are being interpreted locally.

(I agree, we can remove this)

The timeout is nothing new, my preferences show 1000 entries by default, and that's too much for 60 seconds. Wondering if PHP7 accelerates this process enough to finish within 60 seconds, I opened the page, and received plaintext instead of the "usual" warning design. I guess this is relatively intentional and can be ignored.

Thinking about it again, I agree, and the point about technical skill is good. Thanks!

Sub-tasks created.

@Billinghurst , one comment above yours: "Allow blocked admins to block the user who blocked them (but not others). That removes first-mover advantage and the situation will mostly be at a standstill until stewards come and clean things up."

1. if this happens, the null revisions are not the main problem – the overall high edit count is. It would be wrong to blame the final straw for breaking the camel's back.
2. Ignore null revisions for non-admin overwriting redirect checks.
3. Force a null revision to be made, do not provide a checkbox.
4. Do not show a rollback link if all the affected edits are null revisions.
5. Thanking for a null revision should cause the same message as thanking for the log entry.

Most of that IRC log seems to contain arguments that are invalid when implementing this as a null edit rather than doing extra database queries whenever viewing the revison history. The first real point appears at 16:57:22. In my personal opinion, it should not matter how a ticket is written; the existence of a feature request implies that there is use for the feature, and the feature has no downsides, so it should be implemented. This is open since 2014, and people are now wondering (see Village Pump link above) why this is still not a thing.

@geraki Hi, thank you very much for the comment.

Regarding auto-removal, note that the current way for generating new backup
codes is disabling 2FA and enabling it again ^^

Oh, thank you very much. That's a nice solution I didn't think of. ☺️

In T150826#4775305, @Tgr wrote:

[...]

• Allow blocked admins to block the user who blocked them (but not others). That removes first-mover advantage on small wikis - in case of serious trouble the admins will lock each other out and things will mostly be at a standstill until stewards come and clean things up.

If you assume an adversary who is not subject to rate limits and uses automated tools, unblocking themselves whenever needed for further carnage will likely lead to the same result. The unblockself privilege only makes a difference against humans who act harmfully and are limited by their own action speed.

This is very kind, thank you very much! :)

I do agree that this is a rather unlikely attack vector. I also agree that someone doing this would likely, by human intervention, be prevented from doing it repeatedly. About disconnecting from IRC, which is connected by default, I personally would prefer keeping communication with others and disabling automatic interpretation of specific messages separately.

@Petrb please. 😉

@Petrb oh, thanks for the clarification. :) However, I am still worried about a possible security issue. Maybe this is another misunderstanding, though.

Per https://github.com/huggle/huggle3-qt-lx/commit/a8451a01d798c960fedad36e71863ef543236f87 ping @Petrb

Oh, interesting, this is @Magnus' bot? Ping :)

I believe that this page is placing an undue burden on the servers, violating the TOS. A friendly but effective solution would be a system administrator asking the user to fix this problem by contacting them via talk page or e-mail.

Could you clarify if this is a general technical suggestion for custom wikis, or if you are explicitly requesting a change in local rollback behavior for, e.g., the English Wikipedia?

Hi :) I will try. This is my opinion. This is not a neutral summary.

Thank you :)

Comment by non-developer: For logged-in users, permanently disabling this feature should be as easy as clicking "show NSFW image", "do not censor images for me again" in a row.