Edge Rewrite
// HTMLRewriter · presentation

This page was redesigned at the edge.

Cloudflare fetched the original article and streamed it through HTMLRewriter to apply an entirely new visual system without rebuilding the source page.

// request.cf · coarse context

A page that knows where it met you.

Only coarse request metadata is shown. This demo does not display or persist visitor IP addresses.

Country
US
Cloudflare location
CMH
Connection
HTTP/2
Language
Not provided

Ray ID: a2a0713e9af0284b

Jump to content

Wikipedia talk:Huggle/Feedback

Page contents not supported in other languages.
Add topic
From Wikipedia, the free encyclopedia


Requested move 16 June 2022

[edit]
The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: page moved. (closed by non-admin page mover) GeoffreyT2000 (talk) 04:18, 24 June 2022 (UTC)Reply


Wikipedia:Huggle/FeedbackWikipedia talk:Huggle/Feedback – A lot of templates do not work under the Wikipedia namespace, including {{requested move}} and {{Edit template-protected}} (See ). Wikipedia talk seems a more appropriate place. 0xDeadbeef 10:10, 16 June 2022 (UTC)Reply

  • Support since all of the talk pages of Huggle warnings redirect here, it's impossible to make an edit request without waiting forever. I made one 10 days ago and it hasn't been addressed. interstatefive  20:49, 16 June 2022 (UTC)Reply
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Nothing in queue

[edit]

Just upgraded to 3.4.13, but even before with 3.4.12, no edits seem to appear in the queue, even with the all edits option. I managed to revert an edit by entering the page in the page input field, but the queue seems dead, with any of the providers XmlRcs, IRC and Wiki. Is something broken, or I have missed something? - DVdm (talk) 15:45, 29 January 2025 (UTC)Reply

More information:

  1. Using Win 10 pro.
  2. The logfile says: "Wed Jan 29 23:21:02 2025: ERROR: The webserver of enwiki requires that SSL is to be enabled. Please turn SSL on and try again. If you can't enable SSL (option is grayed out) you may need to install OpenSSL libraries to your system."
  3. TLS 1.2 is active
  4. Turned the firewall off, no effect (!)
  5. Turned firewall on again, now the Wiki and IRC providers work. XmlRcs not.
  6. Have set the preferred provider to Wiki in the feed options, but after close and re-open, the provider is IRC. Config file huggle.yaml.js lists preferred-provider: 0, which I manually set to 1, now it stays Wiki.

DVdm (talk) 23:13, 29 January 2025 (UTC)Reply

I'm having the exact same issue. I came here hoping for a fix.--Mojo Hand (talk) 15:07, 2 February 2025 (UTC)Reply
The question is: which is the best provider? Wiki and IRC work fine, but is XmlRcs —if it works— better? - DVdm (talk) 15:41, 2 February 2025 (UTC)Reply
Weird that XmlRcs is the default provider.--Mojo Hand (talk) 16:18, 2 February 2025 (UTC)Reply
Having this exact same issue. --Patient Zerotalk 00:36, 6 February 2025 (UTC)Reply
It started working again for me when I changed provider on the system tab from XmlRcs to Wiki, but it seems slower to me.--Mojo Hand (talk) 00:41, 6 February 2025 (UTC)Reply
Done that as well Mojo Hand, and completely agree that it is now slower...! Patient Zerotalk 01:28, 6 February 2025 (UTC)Reply

I made improvements to XmlRcs server running on wmfcloud that should make it more resilient to similar outages. Petrb (talk) 17:15, 27 July 2025 (UTC)Reply

So I can learn more about the architecture, may I ask what kind of improvements you made? Is there a GitHub repo for this server somewhere? –Novem Linguae (talk) 13:52, 28 July 2025 (UTC)Reply
Yes, there is a github repo here - https://github.com/huggle/XMLRCS the architecture is described here - https://wikitech.wikimedia.org/wiki/XmlRcs the changes I made are major refactoring of es2r daemon (event stream to redis) which is now more resilient to crashes. On top of that there is a new service file for systemd which restarts the service on crash Petrb (talk) 19:50, 4 August 2025 (UTC)Reply

Compatibility with temp accounts

[edit]

As I wrote in WP:VPT#Compatibility of gadgets, scripts, bots, and edit filters with temp accounts, I wanted to ask you to check if AntiVandal is compatible. Here's our documentation for developers; in particular, see the section How should I update my code?. Thank you! SGrabarczuk (WMF) (talk) 08:53, 1 September 2025 (UTC)Reply

Hello support for this feature is already integrated and will be available in next release. Petrb (talk) 18:34, 11 November 2025 (UTC)Reply
@Petrb Quick question for you--Is there a setting to disable the "Shared IP" notice that gets automatically added to warnings? Or is that something perhaps that can be removed in a future release due to the move to temp accounts? Like here Special:Diff/1321843589. Again, thank you for all your work on this project still. Nubzor [T][C] 00:16, 13 November 2025 (UTC)Reply
Yes, this is taken from the configuration that Huggle uses, it's just necessary to remove last 2 lines in the config file:
shared-ip-template-tag: '<!-- Template:Shared IP advice -->'
shared-ip-template: '{{subst:Shared IP advice}}'
I already requested template editor permissions so that I can fix this kind of stuff myself - https://en.wikipedia.org/w/index.php?title=Wikipedia:Requests_for_permissions/Template_editor&oldid=1321764358 Petrb (talk) 08:54, 13 November 2025 (UTC)Reply
Given that temp accounts are technically IP accounts and it's no longer possible to use true IP account I think that this entire template could be also just modified accordingly, but not showing it at all is probably also fine. Petrb (talk) 08:55, 13 November 2025 (UTC)Reply
@Petrb Thank you for already working to fix it. Looks like they did just grant you those permissions, so congrats also! :) Nubzor [T][C] 15:48, 15 November 2025 (UTC)Reply
Great, now I can finally edit the page I created again :) I will fix it right now. Petrb (talk) 23:03, 15 November 2025 (UTC)Reply

Misplaced warnings

[edit]

I am more confident than not I am using this talk page correctly to describe a problem I've recently noticed on user talk pages today.

On one of the user talk pages I've just warned someone about misbehavior of an article, I then noticed a misplaced Huggle message above an earlier edit ClueBotNG made. A few examples: User talk:209.137.220.113, User talk:137.52.208.53 and User talk:Dorathedestroyer. Seems like the tool places the warnings correctly if older warnings were made by other users however. Iggy (Swan) (Contribs) 15:56, 10 September 2025 (UTC)Reply

Iggy the Swan reached out to me on my user talk page about this issue and linked me to this discussion. I've also been noticing that Huggle warnings have occasionally been left at the top of some user talk pages instead of adding them to the end of previous warnings that are under the section header for the current month and year, and of those - Huggle is sometimes also not adding the correct warning level (such as a level 3 warning when the user already has a level 2 warning under the section header for the current month and year). It seems to me like something, somewhere, has changed and is occasionally causing Huggle to either not see that prior warnings have been left on a user's talk page at all, or is causing other issues that is resulting in these occasional issues with warning levels and the location in which they're left. ~Oshwah~(talk) (contribs) 17:08, 10 September 2025 (UTC)Reply
The wrong warning levels being given is a perennial issue, see phab:T110818. I don't think there's a ticket about the warnings being misplaced, though. Perryprog (talk) 20:39, 10 September 2025 (UTC)Reply
I've also had and seen this problem while using AntiVandal on rare occasions, so I don't think it's exclusive to an issue with Huggle. Nubzor [T][C] 15:02, 13 September 2025 (UTC)Reply
Unless AntiVandal and Huggle share some of the same code, they are likely independent bugs. Deciding what warning to give is probably an algorithm in each tool that reads the page's wikitext, then determines what level to give. And there's probably a bug in the algorithm. There could be different heading formats, different template formats, etc. so it might be hard to cover all of them. –Novem Linguae (talk) 21:41, 13 September 2025 (UTC)Reply
Yeah, I'm not particularly worried about it because it's so infrequent and seems like it'd be a nightmare to try and fix with all the variables. I had this example from earlier today where Huggle put a level 1 warning after a level 4. Maybe because it was from 6 days ago? But still September 2025. Then ClueBot put a level 2 after that. But I do check my reverts and caught it anyway. Not a big deal. :) Nubzor [T][C] 22:32, 13 September 2025 (UTC)Reply
Shouldn't be that hard to fix with diffs. Wikicode in wikicode out, with a failing test case, is an easy programming problem to solve. However this project isn't actively maintained, so 🤷‍♂️. The best we can do is probably comment in a phab ticket with that diff. –Novem Linguae (talk) 22:51, 13 September 2025 (UTC)Reply
Hello, please note that by default Huggle ignores all messages on talk pages that are older than 30 days. So if there is warning level 2 template that is 2 months old, Huggle would just issue level 1 template. This can be changed in wiki config, using key "template-age" (it's meant to be negative, default is -30), see https://en.wikipedia.org/wiki/Wikipedia:Huggle/Config.yaml for details. Petrb (talk) 20:23, 22 September 2025 (UTC)Reply
Ohhhh very good to know @Petrb. In checking the linked config, template-age is currently -3. Would that mean 3 days, not 30? Nubzor [T][C] 20:53, 22 September 2025 (UTC)Reply
Yes, that is correct, it seems it was set long time ago here - https://en.wikipedia.org/w/index.php?title=Wikipedia:Huggle/Config.yaml&diff=prev&oldid=918980316 I don't think that value is correct, 3 days is really short. Maybe up for a further discussion, but this is most definitely the root cause why Huggle seems to ignore most of warning templates. It doesn't see anything older than 3 days. Petrb (talk) 19:34, 23 September 2025 (UTC)Reply
That clears up my issue at least. Thanks for sharing :) Nubzor [T][C] 19:36, 23 September 2025 (UTC)Reply
cc ToBeFree. Looks like your diff https://en.wikipedia.org/w/index.php?title=Wikipedia:Huggle/Config.yaml&diff=prev&oldid=918980316 may have caused a couple of the sub-tickets at phab:T110818. Perhaps we should ponder if this 3 day limit can be raised a bit without re-introducing whatever AIV thing you were trying to fix. –Novem Linguae (talk) 03:26, 24 September 2025 (UTC)Reply
Hmmmmmmmmmmm.
Thanks for the ping. The setting worked before my change and then for almost 6 years ... and we probably don't want an AIV report to be made when someone using an IP address 29 days ago had received a final warning back then. This setting also doesn't necessarily technically have to cause the issues described by Iggy the Swan initially here. That's caused by how Huggle implements the setting. My comment back then, When deciding whether to warn or report, ignore templates older than "-x" days, describes my intention. What Huggle appears to do instead is When parsing the page, completely ignore the existence of templates older than "-x" days, which is overkill. That should be changed. Users can still manually report anyone, just the (semi)automated reports of users whose warning was too long ago was the issue 2019. ~ ToBeFree (talk) 11:27, 24 September 2025 (UTC)Reply
It's very hard to distinguish these 2 situations from the algorithm point of view - in fact it's pretty much the same. If you want to "ignore" the warnings when "warning or reporting" you pretty much want Huggle to completely ignore those old templates - those 2 situations you describe are the same. If you only wanted to consider the templates when reporting (not sending any subsequent warning) then the situation would be still only mildly different - let's say user has 3th level warning 2 months old. Huggle doesn't ignore all such templates as you expect - so it issues a 4th level warning. Then on next rollback is sees the user already received 4th level warning - so what should it do next? The logic say - report the user. But then you say: "ignore everything older than 3 days". The 4th level warning is not older than 3 days, but all previous warnings are. What should it do? I think Huggle behaves exactly as specified and required by the current configuration. I think the configuration should be fixed. There are multiple issues right now caused by misconfiguration on project config page. I already mentioned how to fix it elsewhere on this talk page. I can't fix it myself, because my extended global permissions already expired. Petrb (talk) 16:05, 27 September 2025 (UTC)Reply
If you want to write a patch on the talk page and tag it {{IAER}}, someone will be along to implement it. –Novem Linguae (talk) 00:32, 28 September 2025 (UTC)Reply
So as a compromise I raised the limit from 3 days to 15. I understand 30 is probably too much for English Wikipedia, but 15 should be fine. If there is a problem with that, we can adjust it. Petrb (talk) 23:09, 15 November 2025 (UTC)Reply

Why is Huggle not using the standard uw templates?

[edit]

Why is Huggle not using the standard uw templates and instead using its own versions? For example, Huggle has Template:Huggle/warn-1 when the standard is Template:Uw-vandalism1. Gonnym (talk) 09:43, 20 November 2025 (UTC)Reply

@Gonnym: Huggle adds a direct link to the diff of the edit it reverted when warning the user, which Huggle's own templates (but not the standard templates) support. The second parameter of Huggle's templates are used to show a link to the edit, whereas the second parameter of the standard templates are used to leave a custom message. —k6ka 🍁 (Talk · Contributions) 12:34, 20 November 2025 (UTC)Reply
Can't that feature just be added to the main template? Seems a reasonable feature to add. Gonnym (talk) 13:23, 25 November 2025 (UTC)Reply

Note on revert

[edit]

@Sugar Tax I haven't reverted the revert, but just wanted to say that on https://test.wikipedia.org/wiki/Wikipedia:What_Test_Wiki_is_not, it specifically states one of the things not allowed is testing AWB, and that implies that Huggle is also not allowed as well. FantasticWikiUser (talk) 20:26, 10 December 2025 (UTC)Reply

Huggle and AWB are two completely different tools. I don't see anything there indicating Huggle is not allowed to be used for testing on testwiki. Sugar Tax (talk) 20:30, 10 December 2025 (UTC)Reply
Ah, that makes sense. I suppose that it certainly isn't easy to use Huggle on external wikis (outside the WMF) while it is easier to use AWB on external wikis. FantasticWikiUser (talk) 20:35, 10 December 2025 (UTC)Reply
Huggle is being developed on testwiki, so it absolutely can be used there. Petrb (talk) 18:57, 22 December 2025 (UTC)Reply

Cloud VPS VMs turned off because of lack of response to 2025 Cloud VPS Purge

[edit]

@Petrb, @Addshore: The Cloud VPS huggle project was not marked as in use at wikitech:News/2025 Cloud VPS Purge#huggle. As a result the virtual machine instances in the project were turned off earlier today. If huggle no longer uses XmlRcs this is probably not a big deal. Either of you should be able to use https://horizon.wikimedia.org to turn the instances back on if they are still expected to be in use. If you do that I would recommend also marking the project as in use on Wikitech so that a Cloud VPS root does not mistakenly wheel war with you over instance state. -- BDavis (WMF) (talk) 23:16, 4 February 2026 (UTC)Reply

Thanks for the note, @Petrb would be the one to know if these are needed :) ·addshore· talk to me! 09:14, 7 February 2026 (UTC)Reply

Discussion at Wikipedia:Village pump (idea lab) § Five strikes down to three

[edit]

 You are invited to join the discussion at Wikipedia:Village pump (idea lab) § Five strikes down to three. Discussion of vandalism warning levels, with some concerns raised about semi-automated warnings. ClaudineChionh (she/her · talk · email · global) 03:46, 6 February 2026 (UTC)Reply

Text size of interface

[edit]

I used to use huggle, but stopped some years ago, cant remember why.

Just fired up the latest version and due to old age and declining eyesight, I cannot read any text on the working interface as it is far too small. In cases like this I usually go to the View menu and increase the text size to a readable level, in Firefox it is set at 130 to 160%. There is no View menu in huggle, and I grow tired after 30 mins of searching help in order to increase the text size.

HELP

Walter not in the Epstein files Ego 16:32, 16 February 2026 (UTC)Reply

Hello, sorry for late reply, right now Huggle doesn't allow changing the UI size (it may respect OS settings to certain degree), but you can increase the size of font in diffs, which is most of the text Huggle is rendering. It's in preferences, don't remember where exactly, one of the tabs, probably Interface. Petrb (talk) 20:11, 24 June 2026 (UTC)Reply

Template-protected edit request on 24 April 2026

[edit]

Please undo this undiscussed change. The change (removing the Template:uw-vandalism1 tag) causes other antivandalism tools including Twinkle, AntiVandal, and Interceptor to ignore the warning. When using these tools in auto-level mode (the default in some cases), they now ignore this template and will leave an additional uw-vandalism1 warning. The hidden tag has been there for fifteen years. The template editor who made this change (pinging User:Mathglot) does not wish to self-revert but indicates if anyone else wishes they may go ahead and revert. tony 02:04, 24 April 2026 (UTC)Reply

Note that the two other templates in the same boat are {{Welcome-3rr}} and {{Welcome-unconstructive}}; presumably not germane here. For the backstory, please see WT:WARN#Impact of templates misidentified by their hidden tags (redux).That discussion explains why this template should not contain an incorrect template id, why I cannot in good conscience self-revert (because it would introduce errors in another tool; if no one here can do it, I will as last resort), and what the proper solution is in this case. I don't know what the point about longevity implies; if it has been fifteen years, then it has been wrong for fifteen years without being called out by anyone, but that doesn't affect where we are now. Phabricator is full of bugs going back fifteen years needing attention; there is no statute of limitations on them, afaik. If someone reverts, I hope it will be merely the opening salvo leading to the permanent solution already proposed when this was discussed in February that will allow all tools to work properly, and not merely forgotten. Every day following the revert will start to accumulate errors in the number of substed uw-v1 templates statistic which other tools rely upon. Cheers, Mathglot (talk) 02:39, 24 April 2026 (UTC)Reply
As I mentioned in the linked discussions, this is an excellent discussion to have, but that discussion needs to happen prior to an alteration. As it stands this breaks functionality every single time anyone using Huggle issues a level 1 warning. tony 03:16, 24 April 2026 (UTC)Reply
Why prior? This is not a simple case of unilateral change to a template without discussion, as more than one template is involved; otherwise I would agree with you and simply self-revert. The change I made stops the bug from corrupting data input by the other tool, and *causes errors to appear here instead* due to the bug that has been here for fifteen years. Which tool should be the one to manifest errors: the one that does not have a bug, or the one that does? The real solution, which may perhaps take a while, is to fix the underlying bug (here). If you want to buy some time by undoing my revert, I said I would not stand in the way, but it would make me vomit to knowingly put back a bug that causes problems in a working tool elsewhere, which is why I really would prefer someone else do it. But we agree that undoing it is solely a time-buying exercise on the way to a full solution (which we already know how to do) and not a we-just-revert-and-then-it-works-again-here-so-we-are-happy-case-closed situation, right? Mathglot (talk) 04:07, 24 April 2026 (UTC)Reply
For your consideration, here's a possible compromise: Diff. It's not super pretty, but it does seem to me to accomplish both goals of 1) not lying to folks about where this template came from, and 2) not breaking Twinkle. Tested on testwiki, this fixes the auto-level issue in Twinkle. –Novem Linguae (talk) 14:59, 24 April 2026 (UTC)Reply
This would be great for the time being. tony 15:54, 24 April 2026 (UTC)Reply
I think you're on the right track. The variant of wording could work, but this version won't solve the problem, as the string that says it is the other template and triggers the tally is still there. Can you change it to say <!-- This is a variant of template uw-vandalism1 --> instead? That will break the pattern match on the other side and be a complete solution. The problem with current rev is that if it still contains <!-- Template:uw-vandalism1 --> it will be tallied as that template (and also as the Huggle/warn-1 template, so it will be tallied twice). (There is also the minor matter that this won't alter what gets reported in Category:Templates with matching hidden id—or the proposed 'non-matching' category—but if a few templates are listed there that shouldn't be, I don't care as there are no real consequences from it afaict.) Mathglot (talk) 18:01, 24 April 2026 (UTC)Reply
Unfortunately that won't be a complete solution because tools rely on the Template: part. I'm not familiar with the pattern matching logic of the tallies you're describing but apparently they use the same logic that Twinkle and Interceptor and others use.
Twinkle:
const history_re = /<!--\s?Template:([uU]w-.*?)\s?-->.*?(\d{1,2}:\d{1,2}, \d{1,2} \w+ \d{4} \(UTC\))/g;
Interceptor:
const COMMENT_RE = /<\!-- Template:([uU]w-[a-z-]+)([1-4]?(?:im)?) -->/gi;
How about this, as a compromise?
<!-- Template:Huggle/warn-1 --><!-- Template:uw-hugglewarn1 -->
The above keeps the Template:Huggle/warn-1 and also includes a more standard (albeit currently fake) Template:uw-hugglewarn1 tag. This satisfies the antivandalism tools without bloating the uw-vandalism1 totals in the statistics you're worried about. Also, do you have a link to those tallies? I'd like to take a peek at their logic. tony 18:56, 24 April 2026 (UTC)Reply
<!-- This is a variant of template uw-vandalism1 -->. That would require learning and changing the detection algorithms in multiple tools.
I can confirm that <!-- Template:Huggle/warn-1 --><!-- Template:uw-hugglewarn1 --> works to trigger auto-leveling in Twinkle. I'm not sure exactly why yet -- maybe there's a RegEx that looks for [a-z]\d{1,4}$ or something. But this looks like a promising compromise. –Novem Linguae (talk) 19:24, 24 April 2026 (UTC)Reply
Will get back to you, but just eyeballing it looks very promising; thanks for all the investigation, testing, and suggestions. Mathglot (talk) 19:43, 24 April 2026 (UTC)Reply
Have updated {{Huggle/warn-1/sandbox}} (diff) in order to do some testing on my side. If that doesn't represent the proposed solution or if it is an invalid test for some reason (I'm not familiar with Huggle internals), please lmk. Thanks, Mathglot (talk) 05:48, 26 April 2026 (UTC)Reply
Do these numbers look plausible?
Sanity check: compare tallies for Uw-vandalism1 for 2016=107,799, and 2026=67,415. Mathglot (talk) 08:56, 26 April 2026 (UTC)Reply
Need to test on my side now, but I think this will work. Mathglot (talk) 06:30, 27 April 2026 (UTC)Reply
I'm good with your solution. One more pending issue (probably not an issue, but just in case); regarding this:

...works to trigger auto-leveling in Twinkle. I'm not sure exactly why yet...

I hope the reason is not that it is fortuitously working for now, based on anomalous regex behavior identified here and tracked in T424820. Because if it is, it is possible that the bug fix may stop your solution from working. At first glance, the patterns seem sufficiently different that I don't think they are related, but I have to admit that much of the discussion at the ticket was over my head so I can't be sure. You might want to monitor T424820.
It looks like they have a fix for the identified regex bug as of 11 May. I'm not sure of next steps there, but I assume there is some process leading up to a general release. When that happens, could you have another look at your proposed resolution here, and if it is still working, then I think we are good to go. Alternatively, if you feel quite sure the two situations are unrelated, then we can just go for it. Mathglot (talk) 00:16, 15 May 2026 (UTC)Reply
@Mathglot, @Novem Linguae, the reason this works is because of the regex in Twinkle's code I pasted above. There's no ambiguity or mystery. I kinda forgot this is an ongoing issue but since this was never fixed, all anti vandalism tools have ignored this template since February, and will continue to ignore it until the change is reverted or Novem Linguae's proposed change is implemented. tony 15:37, 5 July 2026 (UTC)Reply
Not done for now: Request has gone stale. Feel free to reopen if new info arrises. Zackmann (Talk to me/What I been doing) 15:28, 5 July 2026 (UTC)Reply
Reopened. We have all the info we need, and agree with TonySt; we just need to implement it. Mathglot (talk) 17:10, 5 July 2026 (UTC)Reply
To editor Mathglot: we just need to implement what exactly? Is it the revert? is it the Novem Linguae fix? or is it something else? And is it in the sandbox for simple TEs like myself? P.I. Ellsworth, ed.  welcome!  19:08, 5 July 2026 (UTC)Reply
Sorry I was unclear. I was agreeing with the link in Tony's comment, or to be precise, restating that I support Novem Linguae's proposed change. I think there was agreement that this would work. It is more than a template change iiuc, or I could have implemented it, and even if it isn't, I'm involved and probably shouldn't. Thanks, Mathglot (talk) 19:17, 5 July 2026 (UTC)Reply
 Completed. P.I. Ellsworth, ed.  welcome!  19:32, 5 July 2026 (UTC)Reply
It looks like Template:Huggle/warn-1 was updated. Great. Do we also need to update Template:Huggle/warn-2, Template:Huggle/warn-3, and Template:Huggle/warn-4? Any others I'm forgetting? –Novem Linguae (talk) 20:02, 5 July 2026 (UTC)Reply
Thanks for asking. I had a look at those three, and they also have hidden non-matching ids in the code analogous to what Huggle/warn-1 used to have, which perturb the stats of templates {{uw-vandalism2}}, {{uw-vandalism3}}, and {{uw-vandalism4}}. So yes, we should update those as well. Mathglot (talk) 07:28, 6 July 2026 (UTC)Reply
 Completed. P.I. Ellsworth, ed.  welcome!  15:10, 7 July 2026 (UTC)Reply

Global dark-mode UI?

[edit]

I was using an OLED screen and mostly avoids rendering pure-whites; I see that under Preferences diffs can be rendered w/ dark-mode, but wonders if I can make the UI do so too. I searched the archive, and the most relevant thread seems to be this 海盐沙冰 / aka irisChronomia / Talk 18:32, 12 July 2026 (UTC)Reply

Huggle 3.4.14 fails to block temporary accounts on eswiki

[edit]

Hi! I have been working the past 24 hours translating and updating Huggle configuration for es.wikipedia; but it seems I have arrived to a dead-end. Huggle 3.4.14 fails when trying to block temporary accounts.

Steps to reproduce
  1. Open a diff by a temporary account on eswiki, e.g. ~2026-...
  2. Open the block dialog from Huggle.
  3. Select a block duration.
  4. Click “Block user”.

Huggle shows this error: “Unable to block user. No se puede bloquear al usuario, No se puede bloquear al usuario, Error transferring https://es.wikipedia.org/w/api.php?action=query&rawcontinue=1&format=xml - server replied: Bad Request”

On Wikipedia talk:Huggle/Feedback#Compatibility with temp accounts, Petrb stated on 11 November 2025 that support for temporary accounts was already integrated and would be available in the next release. Huggle 3.4.14 was released shortly after.

Huggle appears to classify temporary accounts as anonymous/IP-like users, because the “Block anonymous users only” checkbox is selected by default.

I also verified that the project configuration no longer uses the old shared IP advice settings mentioned in that discussion: shared-ip-template-tag and shared-ip-template.

Does anyone has a suggestion? Pura vida! Jake Park (talk) 23:24, 5 August 2026 (UTC)Reply

cc @PetrbNovem Linguae (talk) 23:50, 5 August 2026 (UTC)Reply
Quick update. I just tried to block this user and got the same error, so I doesn't seems to be a temporary-accounts only-related error. Jake Park (talk) 01:11, 6 August 2026 (UTC)Reply
User Danielyepezgarces just made this commit that solved the problem! Jake Park (talk) 06:36, 6 August 2026 (UTC)Reply