User Details
- User Since
- Oct 15 2018, 6:19 PM (232 w, 4 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- Suffusion of Yellow [ Global Accounts ]
Feb 5 2023
This seems to depend on the IP I connect to:
Jan 16 2023
Thanks, that does it. Was it really always this way?
Dec 12 2022
Nov 1 2022
Jul 18 2022
Supporting brotli compression (T137979), at least for API, might also help here.
So, something like the iiextmetadatafilter parameter for prop=imageinfo? I agree this would be useful. A typical filter hit is around 100 KB, and some filters on enwiki get tens of thousands of hits in a year. It would be nice to find out which parts of the filter are actually matching anything, without downloading gigabytes of data.
May 16 2022
Something to remember: People using Vector on "narrow screens" are likely to be mobile users who dislike the (Minerva) mobile site. So a "solution" that makes Vector more like Minerva (e.g. collapsed sections) is exactly the wrong one. That would leave no escape, except logging in from every device, and every private tab, just to read a page.
Mar 29 2022
Original thread was here. I'm trying to find if something occurs inside a table with an "Album" heading:
Jan 29 2022
And another one: http://Draft:Getscreen.me. I got a CAPTCHA (from a non-AC account) even for a null edit on Wikipedia:Teahouse until I made this change.
Dec 8 2021
I tried again on testwiki, enwiktionary, and enwikinews, and got an alert every time. Thanks for fixing this! Now where do we talk about disabling LiquidThreads on all WMF wikis?
Nov 23 2021
Nov 20 2021
Nov 12 2021
It's installed but at Special:Version it's spelled "Liquid Threads" instead of "LiquidThreads". And I get no message bar. You can see the full list at https://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php. EIther wmgUseLiquidThreads or wmgLiquidThreadsFrozen force the extension to load.
Nov 11 2021
First, @bwang and @ovasileva (and anyone else I've missed) thank you for implementing this! As you might know it's long been a pet peeve of mine.
Nov 10 2021
Oct 8 2021
Oct 7 2021
Oct 2 2021
Thanks @Dbrant for getting to this!
Aug 20 2021
Jul 27 2021
Jul 4 2021
Jun 8 2021
(All this also applies to T276147. Only responding in one place.)
See T276149#7144054. (Should these tasks be merged...?) With 2.7.50362-beta-2021-06-04, the block message is there now, but it's not parsed. @Dbrant implied there might a newer version that does parse the message, but I can't find it.
@Dbrant: That link is a 404 but I tested on 2.7.50362beta-2021-06-04, which is the latest on https://releases.wikimedia.org/mobile/android/wikipedia/betas
May 28 2021
! In T276149#7122539, @Dbrant wrote:
May 27 2021
Tested in 2.7.50359-alpha-2021-05-27 on testwiki
Tested in 2.7.50359-alpha-2021-05-27 on enwiki
May 26 2021
May 18 2021
May 17 2021
So it seems that the only kind of block that gives me any details is a global block:
May 15 2021
I tried on a few random IPs, and most of the time I saw a (correctly parsed) block message. But once I saw a message claiming that my user account had been blocked. No, I didn't write down the IP; sorry.
The problem still exists for me, with 2.7.50358-r-2021-05-11.
May 12 2021
@Dbrant: Try making any edit to https://en.wikipedia.org/wiki/Wikipedia:Edit_filter/Message_tests. Filter 1147 will disallow all edits to that page, (currently) with the default disallow message.
Tested with 2.7.50357-alpha-2021-05-10.
May 8 2021
Could it be this?
if ( $user->isAnon() ) { $conds[] = 'actor_name<>' . $dbr->addQuotes( $user->getName() ); } else { $conds[] = 'actor_user<>' . $dbr->addQuotes( $user->getId() ); }
May 7 2021
But the API seems to work:
This also happens at Special:RecentChanges and Special:Special:RecentChangesLinked. https://en.wikipedia.org/w/index.php?title=Special:RecentChanges&hideliu=1&hidemyself=1&days=30 and https://en.wikipedia.org/w/index.php?title=Special:RecentChangesLinked&hideliu=1&hidemyself=1&days=30&target=Main_Page show me nothing at all, for example.
Apr 30 2021
Apr 13 2021
As the WMF-Legal project tag was added to this task, some general information to avoid wrong expectations:
Please note that public tasks in Wikimedia Phabricator are in general not a place where to expect feedback from the Legal Team of the Wikimedia Foundation due to the scope of the team and/or nature of legal topics. See the project tag description.
Please see https://meta.wikimedia.org/wiki/Legal for when and how to contact the Legal Team. Thanks!
Mar 26 2021
Mar 24 2021
Getting the same thing on enwiki, try https://en.wikipedia.org/api/rest_v1/page/mobile-html/Wikipedia:Administrators'_noticeboard%2FIncidents
Mar 2 2021
I just tried leaving a message on my IP's talk page. I was using app version 27.50341-r2021-02-02. I got no alert.
Also partial blocks give the same "Your user account has been blocked from editing on this wiki". There is no indication that it's a partial block, and the user can edit other pages. Not sure if that should be a separate task.
Mar 1 2021
Yes. What other app can be used to edit enwiki?
Feb 19 2021
@sbassett: I thought the idea was to have canTestTools(), in the future, also allow users some new right (abusefilter-test, etc.). If that's done, then users with that new right will also be able to view private filters, with an URL like the one above.
As a reminder, Special:AbuseFilter/test still allows you to view private filters with a URL like https://en.wikipedia.org/wiki/Special:AbuseFilter/test/2.
Feb 7 2021
That was quick! Probably should have said that the new "live" syntax checker is a really great improvement; thank you for implementing that!
Feb 3 2021
Jan 13 2021
The problem is gone for me on enwiki. And the Ace editor now warns me about invalid syntax. Thanks!
Jan 11 2021
Instead of a rate limit, what if unprivileged uses of /test were limited to at most N cores and M bytes of memory? Then the only "service" anyone could "deny" is /test itself, which doesn't seem like a worthwhile target. Something similar is done with regex and Special:Search, if I recall.
Sep 13 2020
Aug 26 2020
In any case, if I am correct, then we could just set a per-IP limit for the badoath action, which would then be counted across all wikis.
Jul 16 2020
I also get a captcha request if the string tel:// is already on the page. See https://en.wikipedia.org/w/index.php?title=User:Suffusion_of_Yellow/CaptchaBug&diff=968045535&oldid=968045267.
May 13 2020
Does this still need to be private?
May 2 2020
Apr 22 2020
@tstarling: I just set enwiki filter 68 to exclude bots.
Feb 13 2020
It looks like the only actions that are disabled by default are block, rangeblock, and degroup. The reason blockautopromote is available on enwiki is that no one's ever explicitly disabled it with $wgAbuseFilterActions['blockautopromote'] = false;, yes? The question is, do we need "community consenus" to get that line added, given that AFAIK no one has used that option in years on enwiki?
Jan 29 2020
Marking this as low priority for now. @suffusion_of_yellow - could you expand a bit on why you think that the red circle is not a good enough indicator? I agree that we are most definitely not a social media site, but regardless I think it's an effective way to notify.
Jan 12 2020
Dec 18 2019
@ovasileva: Why was this one marked low priority? I understand that people might disagree with me about T240976, and I'll respond to your question there later, but this one's a big deal. We literally have no way whatsoever to initiate a discussion with logged-out mobile users. Worse, we think we're talking to them.
Dec 17 2019
@Xaosflux: Thanks! I consider the IP issue a high priority problem, the logged-in issue less so. I had assumed that the goal had been to deliver the banner to all users, in one form or another (as on desktop), and a simple bug was preventing the display. Now that I know that part of this is intentional, I will split the task.
@Ammarpad: I only see the red circle when I'm logged in. I see no indication of any kind that there is a message, when logged out. Do you?