Wikipedia talk:XFDcloser

When this AfD was closed early, the deletion tags weren't removed from the article. The article history on the talk page was also not updated. – SD0001 (talk) 10:58, 4 October 2025 (UTC)

If this is the first time that's happened, it might be a client-side issue. Primefac (talk) 12:58, 4 October 2025 (UTC)

The redirect XFDcloser has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2025 October 17 § JWBS until a consensus is reached. Rusalkii (talk) 20:14, 17 October 2025 (UTC)

 You are invited to join the discussion at Template talk:Afd top. —Matrix _{ping me}^{when u reply} (t? - c) 20:51, 17 October 2025 (UTC)

When updating the RfD template after a discussion is relisted, day/month parameters don't get updated (examples ), so it continues linking to the old entry. 9ninety (talk) 12:43, 1 December 2025 (UTC)

@9ninety: This is not a bug, but actually is functioning as intended and needed. The timestamps need to remain to ensure that both the redirects are in the proper RfD month category, in addition to forwarding the reader to the initial nomination date first. (FYI, this has been discussed on this page before with the same answer: Wikipedia talk:XFDcloser/Archive 5#Date not updated when relisted at RFD.) Steel1943 (talk) 22:32, 9 January 2026 (UTC)

How is forwarding readers to the initial nomination date, forcing them to click multiple times to reach their destination, helpful? 9ninety (talk) 11:32, 11 January 2026 (UTC)

Month categories are irrelevant to this. CfD also has them but when you click the link in the nominated category page, you get to the right place immediately without having to follow the link trail left behind by the relisting. Why does XFDcloser behave sensibly in the case of CFD (example) but not RFD? Warudo (talk) 20:58, 28 January 2026 (UTC)

Pinging @Steel1943. 9ninety (talk) 11:54, 20 February 2026 (UTC)

I already explained the reason why things function as they do. If you have issues with it, take it over to WT:RFD as this is no longer a XFDC issue, considering you are now going into the weeds of why all the XFD forums are set up differently. Steel1943 (talk) 22:08, 20 February 2026 (UTC)

Gadget code has to be validated and will be minified by the server anyway, so all the minification in the MediaWiki namespace does is make it harder to locate which part of the code is responsible for what and it seems pointless and counterproductive. Nardog (talk) 15:05, 25 December 2025 (UTC)

I agree. Please feel free to join the discussion at https://github.com/wikimedia-gadgets/xfdcloser/issues/105. Patches welcome. –Novem Linguae (talk) 15:09, 25 December 2025 (UTC)

I am currently unable to close Wikipedia:Categories for discussion/Log/2025 December 15 § Category:Anthropophagy, which needs the "Multiple results" feature. I can select "Rename" for the first category, but when I try to type the name of the destination category (whether immediately when the border of the input box turns red, or after clicking it and turning it blue), text does not go into the input box. Instead, when I type "C", the pull-down changes to "Custom", which is obviously incorrect. If I select "Rename" for both categories, trying to type a destination starting with "C" changes both to "Custom". Trying to type in the "Rationale" input box after selecting "Rename" for both categories, leaving the destination input box borders red, has no effect. I am using firefox-146.0-3.fc43.x86_64 on Fedora Linux. -- Beland (talk) 03:08, 4 January 2026 (UTC)

Beland, I can reproduce this (also firefox). Pasting into the input field seems to still work. — Qwerfjkltalk 10:54, 4 January 2026 (UTC)

I'm using this workaround to close this specific discussion; for debugging purposes, I'm sure it can be reproduced with any multi-page nomination. -- Beland (talk) 04:48, 5 January 2026 (UTC)

See e.g. Special:diff/1331329095 and Special:diff/1331332383. I used a custom message both times. -- Beland (talk) 20:53, 5 January 2026 (UTC)

Question first, Beland, do you remember what you specifically laid out when you did this? I am assuming you used the Custom option with "redirect=yes" as the result, also unchecking the "result is a new sentence" box?

I ask because I think the = in the close is the reason; I made a test log entry with that rationale gave the same result, noting that removing the = gave the expected result. Primefac (talk) 11:37, 17 January 2026 (UTC)

I did select the Custom option and put "delete or add redirect=yes as specified by SilverLocust" as the custom outcome. I don't remember if I unchecked the "new sentence" box (I usually don't), but XFDcloser shouldn't put the wrong outcome whether it's checked or not. It seems properly handling the = is what's needed; I suspected that as well, because it's an unusual character to show up in this field. -- Beland (talk) 00:10, 18 January 2026 (UTC)

For the last few days I have noticed that TFDs closed as delete and listed as "Orphan" are showing up as "Ready to delete". Just one (of many) examples: this diff. I specifically filed that as "orphan" yet it was placed in "ready to delete". This is causing major issues at the holding cell. @Evad37 and Novem Linguae: is this something you can look into? Happy to provide more examples if it would help diagnose the issue... Zackmann (^{Talk to me}/_{What I been doing}) 04:17, 17 January 2026 (UTC)

Did this used to work but recently broke? If so, when did it start? –Novem Linguae (talk) 04:23, 17 January 2026 (UTC)

This was working perfectly for a LONG time. Best I can tell it started about a week ago? I've been noticing a lot of things listed in "Ready to delete" that have not been orphaned. Then when I closed things as "Orphan" I realized what was happening. Zackmann (^{Talk to me}/_{What I been doing}) 04:25, 17 January 2026 (UTC)

Do any of the December commits look like they could be the cause? I don't see any commits changing TFD, but if this suddenly started a week ago, it's worth checking. –Novem Linguae (talk) 04:42, 17 January 2026 (UTC)

Nothing jumps out at me, but I will be honest this is a bit beyond my level of expertise. I can assure you that it is definitely not working the way it was a few weeks ago. Sorry I can't give you an exact date...

@Gonnym, Plastikspork, Pppery, Jonesey95, Primefac, and HurricaneZeta: You all are frequent editors of the holding cell... Have you all been seeing the issue I describe above? Do you have any idea when it started? Zackmann (^{Talk to me}/_{What I been doing}) 04:50, 17 January 2026 (UTC)

Someone deleted a section called "Meta" between December 31 and today. Is the XFDCloser tool counting page sections and off by one? – Jonesey95 (talk) 06:35, 17 January 2026 (UTC)

Could the removal of the. eta heading be a problem?? (Pretty sure I did that....) Perhaps it is expecting X number of headings?? Zackmann (^{Talk to me}/_{What I been doing}) 06:38, 17 January 2026 (UTC)

Very short answer is yes, it goes by section number so if a section is deleted (or added) it messes things up. Primefac (talk) 11:15, 17 January 2026 (UTC)

This XFDcloser code in Venue.js does suggest that the holding cell section order is hard-coded: https://github.com/wikimedia-gadgets/xfdcloser/blob/f06a7a189f13966ba0c2ae2710a943d8e59f48bc/xfdcloser-src/Venue.js#L182-L193

Would recommend adding the meta heading back temporarily, or someone writing a patch for XFDcloser. Looks like an easy patch. I'll try to review it once it's written. –Novem Linguae (talk) 15:06, 17 January 2026 (UTC)

I've already readded the header (apologies for not making that more clear), though I object to making it temporary -- that section has been there since we reorganised the page a half-dozen years ago. Primefac (talk) 15:17, 17 January 2026 (UTC)

I saw the issue yesterday I think but didn't notice it before (but wasn't keeping too much attention recently). I also don't close discussions so wouldn't have seen it right away. Gonnym (talk) 11:15, 17 January 2026 (UTC)

Looks like it's fixed already but I noticed that here this went into the ready for deletion section when I closed it as orphan. HurricaneZeta^C 15:06, 17 January 2026 (UTC)

I mean, it got fixed four hours ago and your diff is from four days ago. Primefac (talk) 15:19, 17 January 2026 (UTC)

Playing catch up here... But looks like this is all on me for deleting the Meta heading! Facepalm That's on me!! Sorry folks!! Zackmann (^{Talk to me}/_{What I been doing}) 16:27, 17 January 2026 (UTC)

So this definitely appears fixed. Sorry again as this was all caused by my removal of the Meta heading! No clue why I did that.... Lesson learned! User:Novem Linguae really appreciate your quick response to my query here! Zackmann (^{Talk to me}/_{What I been doing}) 17:06, 17 January 2026 (UTC)

Sure no worries. Fixed. –Novem Linguae (talk) 21:22, 17 January 2026 (UTC)

Hey, It looks like XFDCloser removes newly-minted redlinks but keeps the text intact when a page is deleted. That makes sense in most articles.

It doesn't make sense on outline pages, though.

See here for one example:

Actual behaviour: see above

Suggested behaviour: because an outline page is always a collection of (mostly) internal links, IF a link in an Outline page appears in a list (bullet pointed or numbered) AND it doesn't have any sub-items in that list AND it has to be removed by XFDCloser THEN XFDCloser should remove the whole line instead of just the hyperlink.

The reasoning behind this is that it looks weird for just the text to be there, as if an article should exist (it probably shouldn't because it was just deleted), or it has to be replaced by an external link (potentially messy).

What do you think? 🔥Komonzia (message) 01:36, 1 February 2026 (UTC)

I feel like that would be horribly messy to code. I will note that XFDC already gives the option to remove list items when closing a discussion, so I think it's more the case that closers should be more considerate of what should be removed and what should be delinked (instead of what I would guess is simply an all-or-nothing approach). Primefac (talk) 15:16, 1 February 2026 (UTC)

Okay, that sounds reasonable, thank you :) 🔥Komonzia (message) 16:06, 1 February 2026 (UTC)

I'm gonna raise this 4 year old request again: Wikipedia_talk:XFDcloser/Archive_5#Feature_request:_Delete_TFDd_template_subpages. I would use this feature essentially every time after manually doing a quick check. Much faster than using twinkle on them all separately. I don't know how other TfD closers do it but I reckon I'm not the only one. Trialpears (talk) 18:01, 5 February 2026 (UTC)

I don't hit them all separately, I use d-batch after getting the list of subpages (though that does require manually typing in the rationale).

But yes, a nice little poke for this showing that it's wanted by more than just a couple of admins is good! Primefac (talk) 10:22, 6 February 2026 (UTC)

Agreed. I added a comment to the GitHub ticket and I added the "frequently requested" tag thanks to this post. Someday if myself or someone does a burst of work on this, and we filter by the "frequently requested" tag, that'll put this near the top of the list. –Novem Linguae (talk) 08:00, 7 February 2026 (UTC)

Instead of text appearing, the dropdown menu options change/cycle as raised and confirmed here. Iseult ^Δx talk to me 16:56, 21 March 2026 (UTC)

Iseult, could you be a little more specific about what you're doing and what's happening instead? Maybe I'm just misunderstanding, but I don't see why you would be typing in the dropdown menu rather than selecting one of the options (such as "custom"). Extraordinary Writ (talk) 17:06, 21 March 2026 (UTC)

Extraordinary Writ, I'm trying to close a batched CfD as custom rename. The consensus I read was for the categories to be renamed to something not in the original nom, so I selected "multiple options" in the bottom left of XFDCloser and tried to close the renames individually to their new target, which I tried to type in the non-dropdown. But even if I'm not supposed to type in the open field, the rationale field under multiple options also doesn't take input. Iseult ^Δx talk to me 17:19, 21 March 2026 (UTC)

Iseult, this is how it looks for me—is it different for you, or am I just confused? Extraordinary Writ (talk) 17:34, 21 March 2026 (UTC)

Extraordinary Writ, that's what I see asides from the non-dropdowns being able to take input. This persists for me even without browser extensions; I'm using Safari on desktop. Iseult ^Δx talk to me 17:47, 21 March 2026 (UTC)

Okay, it works for me on Chrome but not on Firefox. It looks like it's been previously reported here and here. (Firefox did still let me paste into the box, for what it's worth.) Extraordinary Writ (talk) 17:56, 21 March 2026 (UTC)

Thanks, EWrit. Pppery, workaround identified. Iseult ^Δx talk to me 18:16, 21 March 2026 (UTC)