Thu, May 16
The link is known to have worked at 2019-05-01T18:45:33.
Wed, May 15
Mon, May 13
Before the patch, I wasn't aware that this is a Wikimedia-only extension providing the text. I genuinely believed this to be a global error that the enwiki community was insisting on keeping. Neither is the case.
@Risker, I am very disappointed by this bureaucratic objection to a typo fix that is backed by a local policy and can easily be overridden by creating the page with any content that the enwiki community decides on in an RFC.
Sun, May 12
Sun, May 5
Thu, May 2
Wed, May 1
Sat, Apr 27
Feel free to close any of both tasks, perhaps as a duplicate, if they are considered to be essentially attempting to solve the same problem using two different solutions
Fri, Apr 26
Thank you very much, this relieves me! :)
Tue, Apr 23
"Optimizing" a website for search engines appears to be the wrong approach website building to me. If a search engine's algorithm fails to correctly balance the relevance of a website to its users, then the problem is in the algorithm, not the website.
Mon, Apr 22
Apr 11 2019
Wonderful and seems to be done
Still testing? Breaking issues?
Mar 26 2019
Mar 7 2019
Mar 2 2019
Feb 25 2019
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
Feb 23 2019
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.
Feb 11 2019
Feb 9 2019
Jan 31 2019
Jan 25 2019
(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.
Jan 15 2019
Jan 14 2019
Thinking about it again, I agree, and the point about technical skill is good. Thanks!
Jan 5 2019
Dec 28 2018
Dec 9 2018
@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."
Dec 3 2018
Dec 2 2018
- 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.
- Ignore null revisions for non-admin overwriting redirect checks.
- Force a null revision to be made, do not provide a checkbox.
- Do not show a rollback link if all the affected edits are null revisions.
- Thanking for a null revision should cause the same message as thanking for the log entry.
Dec 1 2018
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.
Nov 28 2018
Regarding auto-removal, note that the current way for generating new backup
codes is disabling 2FA and enabling it again ^^
Nov 27 2018
Oh, thank you very much. That's a nice solution I didn't think of. ☺️
Nov 26 2018
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.
Nov 25 2018
Nov 22 2018
This is very kind, thank you very much! :)
Nov 21 2018
Nov 19 2018
Nov 17 2018
Nov 6 2018
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.
Nov 4 2018
@Petrb please. 😉
@Petrb oh, thanks for the clarification. :) However, I am still worried about a possible security issue. Maybe this is another misunderstanding, though.
Nov 3 2018
Nov 1 2018
Oct 23 2018
Oct 22 2018
Oct 21 2018
Oct 1 2018
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.