Wikipedia talk:XFDcloser/Archive 3

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Modules (again)

{{Resolved}}

The script doesn't seem to handle non-admin delete closures of TfDs for pages in the Module: namespace at all. It'll close the discussion fine, but there's no action at all for the pages that are to be deleted - no G6 tag on the module, nor a G8 on the talk page. Could you check to see what's going on there? Pinging Winged Blades of Godric, whose NAC of this discussion for Module:U.S. States brought this to my attention. Thanks, ansh666 03:36, 17 June 2018 (UTC)

• Tagging doesn't work/isn't allowed on modules, probably it'd be best that the script added the tag to the doc Galobtter (pingó mió) 03:43, 17 June 2018 (UTC)

  So it doesn't let you save unless it's valid syntax? That's really dumb. Tagging the doc and talk page (in case one or the other doesn't exist) would be a good first step, but then what to do if neither exists? ansh666 03:50, 17 June 2018 (UTC)

  The script can create the doc I suppose. Also, adding the tag to the module, even if it were allowed to be saved, wouldn't add the page to the categories (or do anything else) Galobtter (pingó mió) 03:53, 17 June 2018 (UTC)

Hmm...Galobtter's idea does seem good enough:) In the meanwhile, the delete option may be de-activated for closing discussions about any module, as happens in the other name-space(s)...... ∯WBG^converse 08:06, 17 June 2018 (UTC)

• As a note, the TFD nomination must be made on the /doc in the first place, so it will always exist if the person doing the nominating is paying any sort of attention. Not sure how easy it would be to make sure the script updates the /doc instead of the module itself, but that is all that would be needed. Primefac (talk) 14:03, 17 June 2018 (UTC)
  • It shouldn't be too hard to code this, will take a look tomorrow, or in the next couple of days - Evad37 [talk] 15:45, 17 June 2018 (UTC)

  Ah, true, forgot about that part. Thanks everyone. ansh666 17:55, 17 June 2018 (UTC)

@Ansh666, Galobtter, Winged Blades of Godric, and Primefac:  Done, the script now knows to use the /doc page for modules. If the /doc page doesn't exist, the standard 'page does not exist' error will be reported. - Evad37 [talk] 05:11, 20 June 2018 (UTC)

Templates not updating?

{{resolved}}

I had this happen yesterday as well, but I didn't think anything of it, but again tonight I go to close a merge discussion and it just sits there and doesn't update the templates. Thanks for looking into this. Primefac (talk) 00:06, 30 June 2018 (UTC)

@Primefac:  Fixed - Evad37 [talk] 02:47, 5 July 2018 (UTC)

TFD relist errors

{{resolved}}

this one and a few preceding czar 21:27, 4 July 2018 (UTC)

Looks like it is specific to one user, DeltaQuad, since it is happening with their relists at both TFD (e.g. the above) and FFD (e.g. [1]), but not for other users (e.g. [2] at TFD, [3] at FFD). @DeltaQuad: Have you changed preferences or installed any new scripts or gadgets recently? - Evad37 [talk] 02:27, 5 July 2018 (UTC)

Actually, the problem seems to have come from having the old TFDcloser and FFDcloser scripts installed. I've replaced their code with a comment that they have been superseded by XFDcloser, so this issue should now be resolved. - Evad37 [talk] 03:25, 5 July 2018 (UTC)

@Evad37: I was having issues with one of them, so I used the other, not sure why I installed both. Which ones should I be removing? -- Amanda (aka DQ) 18:35, 5 July 2018 (UTC)

You can remove FFDcloser.js and keep XFDcloser.js (the newer one which handles all deletion discussions), but it's not necessary as Evad has deactivated the conflicting script. czar 23:53, 5 July 2018 (UTC)

Removing temp closer placed templates

{{User:ClueBot III/ArchiveNow}}

I notice that the script will automatically remove the {{closing}} template when an XfD is closed. Can this be extended to the alternative templates {{AfDh}} and {{AfDb}}? At the moment the script stops if these templates are in place with a message that the XfD is already closed. Note that this recent edit to {{AfDb}} may have changed the situation, I don't know. Thanks, SpinningSpark 14:19, 8 March 2018 (UTC)

Looking through your script, that functionality seems to already be in place so it got broke at some stage. The (now reverted) redirect of {{AfDb}} to {{AfD bottom}} was causing a bot to substitute the template. I'm guessing that that was what broke it. Hopefully it will now work, but I haven't used it since. SpinningSpark 14:28, 8 March 2018 (UTC)

Hangs when closing pages that had been already deleted

{{resolved}}

Moved from User talk:Evad37 § XFDCloser Hangs when closing pages that had been already deleted

 – Evad37 [talk] 09:51, 20 July 2018 (UTC)

The gadget hangs at the "updating page" stage if you have checked "update pages and talk pages" but the page has already been deleted --Tyw7  (🗣️ Talk • ✍️ Contributions) Please ping me if you had replied 09:15, 20 July 2018 (UTC)

@Tyw7: Ummm... why did you have "update pages and talk pages" checked if the page had already been deleted? Obviously the script should avoid hanging, and I'll look into fixing that, but you shouldn't be trying to remove a nomination template from a deleted page, nor be trying to add an old xfd template to a deleted talk page. - Evad37 [talk] 09:58, 20 July 2018 (UTC)

Yeah but it didn't hang with the deleted talk page, just the article. --Tyw7  (🗣️ Talk • ✍️ Contributions) Please ping me if you had replied 10:01, 20 July 2018 (UTC)

Also can you confirm which XfD discussion(s) specifically gave you problems? - Evad37 [talk] 09:59, 20 July 2018 (UTC)

I think in general ie any, where the main page is deleted. The most recent one is Wikipedia:Articles for deletion/Frat shag --Tyw7  (🗣️ Talk • ✍️ Contributions) Please ping me if you had replied 10:01, 20 July 2018 (UTC)

@Tyw7: If you make sure "No automated actions" is checked rather than "Update pages and talk pages", then the script won't even try to edit the page or talk page - Evad37 [talk] 10:14, 20 July 2018 (UTC)

I realize but it shouldn't hang. It ignored the talk page without hanging. --Tyw7  (🗣️ Talk • ✍️ Contributions) Please ping me if you had replied 10:16, 20 July 2018 (UTC)

@Tyw7:  Fixed - Evad37 [talk] 04:06, 30 July 2018 (UTC)

Very minor change to Module:RfD

{{resolved}}

I've made this edit to a comment that's autogenerated by Module:RfD. I don't think this will break the XfDCloser but I thought I should leave you a comment just in case. Deryck C. 13:24, 9 August 2018 (UTC)

Thanks for the notification, the script will actually need a minor edit. - Evad37 [talk] 13:30, 9 August 2018 (UTC)

 Done - Evad37 [talk] 13:51, 9 August 2018 (UTC)

Redirect closures and rcat shell

{{resolved}}

"Do not add rcats" should be the default because if the other box is ticked, it needlessly adds an empty {{rcat shell}} (an optional group template). Alternatively, the "rcats" option could be changed to not add rcat shell if no rcats are added. — Godsy ^(TALK_CONT) 03:23, 14 August 2018 (UTC)

@Godsy: {{rcat shell}} is designed to be used without parameters when one is unsure of which rcat to add – it adds the redirect to Category:Miscellaneous redirects, which is monitored by editors who will add an appropriate rcat - Evad37 [talk] 03:59, 14 August 2018 (UTC)

@Evad37: The template states: Important – Please Read! This template should not be applied by bot, nor should it be used without parameters unless you want to learn how to categorize redirects. This template is a learning tool to help editors who want to learn how to categorize redirects. Only those editors who intend to return to the redirect to learn which rcats to use should apply this template without parameters, or with an empty first parameter! I understand exactly how to categorize redirects, as do many experienced editors who close discussions, but do not always make the choice to. Even if I wanted to add an rcat, I would not do so with the closer tool because I do not use rcat shell (which has perennially been confirmed as optional). Especially at mfd, when speedy redirecting, rcats are generally undesirable. I really think "do not add rcats" would be the better default. Want me to drop a note at Wikipedia talk:WikiProject Redirect to solicit some opinions? — Godsy ^(TALK_CONT) 04:39, 14 August 2018 (UTC)

So they are basically two issues here:

1. The default setting of adding or not adding rcats
2. What to do when set to add rcats, but no rcats have been specified

With the first issue, perhaps this should be venue-dependant, since e.g. for AfD and RfD most should have rcats added, while for MfD it sounds like perhaps most shouldn't have rcats added.

With the second issue, well, the Rcat shell documentation used to encourage using the manifold sort/miscellaneous category to help with sorting redirects to correct and appropriate categories. If that is no longer the case, and editors really don't care to maintain a backlog of redirects that quite possibly should have one or more rcats, I can simplify the interface and just have an empty rcat selection mean "do not add rcats". Which kind of makes the first issue redundant, since then by default no rcats are selected, except for AFDs where default is {{R to related topic}}.

As for soliciting further opinions, sure, you can add a note there or anywhere else you feel is appropriate - Evad37 [talk] 07:24, 14 August 2018 (UTC)

Pinging editors who've previously discussed rcats here (per this page's archives): @Tavix, Czar, Feminist, and Amorymeltzer: - Evad37 [talk] 07:31, 14 August 2018 (UTC)

I just sorted through all ~150 pages that were in Category:Miscellaneous redirects. ~130 remain, all placed through this script by one of ~20 discussion closers: Sarahj2107, Premeditated Chaos, Galobtter, Davey2010, Killiondude, TheSandDoctor, Salvidrim!, The Blade of the Northern Lights, Primefac, Anarchyte, BDD, Plastikspork, Deryck Chan, Winged Blades of Godric, The Duke of Nonsense, Tavix, Feminist, Amorymeltzer, and myself. I will also ping the rcat guru, Paine Ellsworth. — Godsy ^(TALK_CONT) 08:02, 14 August 2018 (UTC)

Godsy, how did you determine this? I don't use this script. --BDD (talk) 14:33, 14 August 2018 (UTC)

@BDD: I looked at all ~150 redirects and copied the name of discussion closers (once per individual) to a notepad. You were probably the last person to edit, or otherwise edited, one of the redirects and I mistook you for the closer (I know you oft close rfds, so I can see myself easily making that error). Sorry and warm regards, — Godsy ^(TALK_CONT) 21:14, 14 August 2018 (UTC)

• I agree that XFDCloser shouldn't add an empty rcat shell by default. Deryck C. 13:38, 14 August 2018 (UTC)
• I would agree with Godsy, and think that an empty {{rcat shell}} should never be automatically applied by XFDC (unless it is one of the RCATs that can be applied if that is specifically what someone wants). I get frustrated when I forget to uncheck that box and have to manually remove the {{rcat shell}} template. -- Tavix ^(talk) 13:41, 14 August 2018 (UTC)
• Totally fine with the no empty rcat shell by default being how the closetool works. Any addition of an empty rcat shell by me was probably an unnoticed mistake. I tried looking through Category:Miscellaneous redirects to see which were mine to go back and fix them but couldn't easily find them, if you have a list on-hand Godsy let me know and I'll fix them up. :) Ben · Salvidrim! ✉ 14:17, 14 August 2018 (UTC)
  • @Salvidrim!: I believe it was just one or two in your case. I would have to look through them all again to find which one(s). No worries though, if this change goes through, then I will likely remove the empty template from all of these. Best regards, — Godsy ^(TALK_CONT) 21:21, 14 August 2018 (UTC)
• This is me, genuinely confused. I recall this huge push (some of it came back against me) a few years ago when it seemed like every redirect must have some form of categorization. Doesn't the rcat shell basically say "hey, this needs categorization"? Are we no longer doing that? Primefac (talk) 14:21, 14 August 2018 (UTC)

We would want to eventually have every redirect categorised, not just the ones that happen to have been tagged with an empty rcat shell: if we allowed adding the rcat shell without parameters as some sort of intermediate step in the process, this will only encourage large-scale busyworok. – Uanfala (talk) 09:49, 15 August 2018 (UTC)

Maybe the purpose of Category:Miscellaneous redirects should be converted to a maintenance category like "redirects needing categorization" to make it clear that it should be patrolled and not left to stack up? Ben · Salvidrim! ✉ 14:31, 14 August 2018 (UTC)

• (edit conflict) I don't think anybody is saying that we are no longer pushing to categorize redirects; however, imagine yourself monitoring the Miscellaneous redirects category and all of a sudden one day there are 6,329 redirects in there. And yesterday there were only 76 redirects in there. We just don't have enough editors to monitor a quickly-filled category and to categorize all those redirects, do we?  Paine Ellsworth  ^put'r there  14:36, 14 August 2018 (UTC)

• (edit conflict) This appears to be about adding the {{Redirect category shell}} without parameters by way of a check-box automation? I've slightly altered the warning text to: Important – Please Read! This template should not be applied without parameters by bot nor by any automated or semi-automated process. It should not be used without parameters unless you want to learn how to categorize redirects. This template is a learning tool to help editors who want to learn how to categorize redirects. Only those editors who intend to return to the redirect to learn which rcats to use should apply this template without parameters, or with an empty first parameter! I'd love to see the Rcat shell added to redirects even without parameters, but only if the learning experience is worth returning to. The shell should never be added without params unless an editor really has no clue as to at least one rcat to use. Then, if one or more rcats are used and the editor still thinks more are needed, just leave the first parameter blank. Application of rcats is pretty straightforward as long as one is familiar with the main index. Thanks to all for your interest in redirect categorization!  Paine Ellsworth  ^put'r there  14:36, 14 August 2018 (UTC)

  I've respectfully reverted your edits, because this script is semi-automated and does provide a useful function if categories are actually added. Primefac (talk) 14:46, 14 August 2018 (UTC)

S'okay, because I should have stipulated "without parameters", and that has been done.  Paine Ellsworth  ^put'r there  14:53, 14 August 2018 (UTC)

• (edit conflict) Thanks for the ping, The template currently states "This template should not be applied by bot, nor by any auto- or semi-automated process. It should not be used without parameters" so basically this should not be apart of the close process, In regards to Primefacs comment if there was a discussion or consensus for this then a revisit and some clarification needs to be done (as to what template should be used if any should), I agree with the above anyway. –Davey2010^Talk 14:39, 14 August 2018 (UTC)

• To clarify, I think it's okay to apply the template as long as there is at least one rcat within the shell, that is, as long as the 1st parameter is not empty.  Paine Ellsworth  ^put'r there  15:10, 14 August 2018 (UTC)

 Done. The script will no longer place empty rcat shell when no rcats have been selected, and I've made a minor change to the interface as described above to reflect this. - Evad37 [talk] 07:27, 15 August 2018 (UTC)

• This was the original discussion. Fine by me to remove {{rcat shell}} when empty but the idea was that if this script doesn't, other editors will follow behind AfD closures to tag redirects as needing categorization, and at the very least we could save the step of applying that maintenance category. This said, mandatory redirect categorization often seems like categorization for its own sake, especially if tagged with the default {{R from related topic}}, so more raising awareness for those editors who follow behind AfD closures than advocating for this myself. czar 10:03, 15 August 2018 (UTC)

The disambiguate option at RfD

{{User:ClueBot III/ArchiveNow}}

 Semi-done

 – Initial problem resolved; the other issue does not have an easy fixed but should be mitigated by the updated instructions - Evad37 [talk] 02:44, 7 September 2018 (UTC)

I finally had the opportunity to test out the new "disambiguate" option at WP:RFD with a fully drafted disambiguation under the redirect. Even though {{Disambiguation}} already existed on the page, the script added the dab clean-up template. Additionally, the script did not remove Category:Temporary maintenance holdings. Could you check out Ocho and see if you could fix these bugs? Thanks, -- Tavix ^(talk) 17:12, 6 December 2017 (UTC)

 Fixed, trying it out with the same wikitext now gives this diff - Evad37 [talk] 02:38, 7 December 2017 (UTC)

• I just ran into a similar problem after closing DENR. There was a drafted dab but XFDC replaced the entire page with the dab clean-up template. I think the problem is because the IP drafted the dab within the RfD template instead of below it. I don't foresee this problem coming up a lot (and it's not a big deal either way), but I thought to report it to you in case there is an easy fix. Thanks, -- Tavix ^(talk) 22:00, 5 February 2018 (UTC)

• Of course it comes up the next day after I say I don't foresee it coming up a lot. Similar problem occurred at Game of Bones. -- Tavix ^(talk) 18:15, 6 February 2018 (UTC)

• Based on the RfD tempalte, I rather think this is likely to occur regularly. ~ Amory (u • t • c) 20:40, 6 February 2018 (UTC)

Most presumptious

{{User:ClueBot III/ArchiveNow}}

 No action

 – Per SoWhy and per WWGB's edit, this is the correct behaviour - Evad37 [talk] 02:57, 7 September 2018 (UTC)

This is a most presumptious tool you have here. At Deaths in 2018, we happily insert redlinks for most recent deaths included in the list, and we keep all redlinks for thirty days before removing them - after monthly archiving usually. The fact that what used to be a bluelink has become a redlink due to article deletion does not alter the consensus among our editors - but it does result in an intrusive bot edit into our page undoing a small fraction of our valid work. Regardless, we can keep reverting the bot work - I just thought I would point this out. Ref ^(chew)(do) 11:36, 19 August 2018 (UTC)

@Refsworldlee: I think you are confusing something. The first rule people see when editing the Deaths in 2018 list is Please add only those meeting Wikipedia notability guidelines. XFDCloser removes entries when a XFD discussion ends with a consensus to delete the page. So those redlinks are redlinks because there is consensus that these subjects are not sufficiently notable for inclusion and thus also, by the very page you refer to, not sufficiently notable to be included in that list. Regards SoWhy 12:21, 19 August 2018 (UTC)

Silent edit conflict?

{{User:ClueBot III/ArchiveNow}}

Hi. See [4] and User_talk:Pkbwcgs#Why_did_I_delete_all_the_other_nominations?. Looking at the edit history it appears that while I had the edit page open on Redirects_for_discussion, XFDcloser was used twice; and when I closed my edit, no edit conflict notice came up, but my edit overwrote the two edits by XFDcloser. I don't have a precise memory of how long I had the edit page open, but I am fairly sure that there was no Large yellow pond lily on the page, and that the last entry was 4-digit redirects. SilkTork (talk) 02:11, 6 September 2018 (UTC)

@SilkTork: So it looks like what happened was that you opened the edit page at some point, then two relists were made using XFDcloser [5][6], and then you made your edit resulting in this diff. As far as I can see, this isn't actually a problem with XFDcloser, but possibly a bug in the wiki software since it should have detected the edit conflict rather than saving your edit. - Evad37 [talk] 04:02, 6 September 2018 (UTC)

Where do you feel I should report it? Or was it possibly a one-off glitch? SilkTork (talk) 10:39, 6 September 2018 (UTC)

WP:VPT to start with. If nobody there comes up with an answer, then the bug can be reported in Phabricator. - Evad37 [talk] 11:47, 6 September 2018 (UTC)

XFDCloser doesn't detect edit conflicts?

{{resolved}}

See this edit. Apparently, XFDCloser did not detect the edit conflict that my previous edit created, and then closed the wrong section at WP:RFD. My assumption is that this happened since when the tool was used, the section intended to be closed was the (X)th section from the top, but after I added a new nomination at the same minute, the respective section became the (X + 1)th section from the top, but XFDCloser still closed the (X)th section. Steel1943 (talk) 18:57, 29 March 2018 (UTC)

Especially weird that it actually deleted the right pages, but closed the wrong discussion. The Blade of the Northern Lights (話して下さい) 21:11, 29 March 2018 (UTC)

@Steel1943 and The Blade of the Northern Lights:  Fixed. Steel1943 was right about the cause, the script was relying on section numbers not changing (which most of the time they don't, but occasionally they do). And the right pages get deleted because that is not reliant on the section number. Anyway, the script now checks the section heading before making the edit, and aborts if it doesn't appear to be the right section (probably due to a section being added or removed above). - Evad37 [talk] 02:33, 7 September 2018 (UTC)

Thanks. Appreciate the work on this. The Blade of the Northern Lights (話して下さい) 03:26, 7 September 2018 (UTC)

Percent sign mucking up script

{{resolved}}

See Wikipedia:Redirects for discussion/Log/2018 February 24; close links don't appear, and the show/hide tag starts up weird. Through some testing, it seems the offender is the AR-!% redirect, specifically the % in the name. ~ Amory (u • t • c) 19:50, 4 March 2018 (UTC)

Happened again at Wikipedia:Articles for deletion/Microstructurally Stable Copper and 10% Atomic Tantalum Nanocrystalline Alloy. ansh666 06:56, 2 August 2018 (UTC)

 Fixed - Evad37 [talk] 03:38, 22 December 2018 (UTC)

Discussions with non-Latin characters

{{resolved}}

I recently attempted to close Wikipedia:Redirects for discussion/Log/2018 September 20#尺八 (しゃくはち, and got the following: [API error: TypeError: null is not an object (evaluating 'section_heading .match(/[A-Za-z0-9]+/g) //split into words .every') – Could not edit page Wikipedia:Redirects for discussion/Log/2018 September 20; could not close discussion]. I don't remember having this problem with titles only containing non-Latin characters, is it the parenthesis throwing this off? The Blade of the Northern Lights (話して下さい) 12:52, 27 September 2018 (UTC)

It seems this is a bug I introduced with the last update. Also reported by TheSandDoctor in this diff. - Evad37 [talk] 03:24, 28 September 2018 (UTC)

@The Blade of the Northern Lights and TheSandDoctor:  Fixed - Evad37 [talk] 04:45, 28 September 2018 (UTC)

Good to hear! . I don't think I have ever thanked you Evad37, but thank you for creating XFDcloser. As a non-admin previously (and one now), it sure does help to simplify the closing of XfD discussions. Manually doing that one reminded me why I use this script in the first place . --TheSandDoctor ^Talk 04:48, 28 September 2018 (UTC)

Yes, definitely. Thank you! The Blade of the Northern Lights (話して下さい) 02:10, 29 September 2018 (UTC)

"Error retrieving page information (reload the page to try again) API error: undefined" again

{{resolved}}

Hi. XFDCloser is constantly giving "Error retrieving page information (reload the page to try again) API error: undefined" on the majority of the templates at WP:TfD. What is the problem? Pkbwcgs (talk) 15:10, 17 October 2018 (UTC)

The problem seems to be Wikipedia:Templates_for_discussion/Log/2018_October_16, more specifically 2018 Asian Games sepak takraw game templates. It seems like one of the API queries is failing, and causing everything after that point to also fail for some reason. Looking in to it further now... - Evad37 [talk] 09:53, 18 October 2018 (UTC)

@Pkbwcgs:  Fixed, mostly. Now only that one TfD errors out (because of the number of pages listed), but everything else is okay. - Evad37 [talk] 10:32, 18 October 2018 (UTC)

---

Well, I'm now getting:

long error

Uncaught TypeError: Cannot read property 'prototype' of undefined at Object.extraJs.makeRcatCapsuleMultiselect (index.php?title=User:Evad37/extra.js&action=raw&ctype=text/javascript:149) at Dialog.setup (index.php?title=User:Evad37/XFDcloser/v3.js&action=raw&ctype=text/javascript:2054) at Discussion.openDialog (index.php?title=User:Evad37/XFDcloser/v3.js&action=raw&ctype=text/javascript:650) at HTMLSpanElement.<anonymous> (index.php?title=User:Evad37/XFDcloser/v3.js&action=raw&ctype=text/javascript:758) at HTMLSpanElement.dispatch (load.php?debug=false&lang=en&modules=jquery&skin=vector&version=00rdyep:69) at HTMLSpanElement.elemData.handle (load.php?debug=false&lang=en&modules=jquery&skin=vector&version=00rdyep:65)

When clicking the close button on any Tfd or Afd and I assume all Xfd discussions. However, quickdelete works, but not relists, which gives the same error. Ping Evad37 Galobtter (pingó mió) 05:27, 19 October 2018 (UTC)

@Evad37: XFDCloser is very slow in closing discussions. It is taking forever. Pkbwcgs (talk) 08:17, 20 October 2018 (UTC)

This was the same as the issue below - Evad37 [talk] 16:02, 21 December 2018 (UTC)

An issue

{{resolved}}

Hi Evad, I've been using XFD closer for a quite long time now. However from yesterday, I am facing an weird issue (or may be an error). When I click on close, it says "Closing ...", for "relist" it goes on "Relisting ...". There is neither a popup in the former case nor any action in the latter case. Please help me in fixing this. Thanks in advance, KCVelaga (talk) 14:43, 19 October 2018 (UTC)

I'm seeing the same problem. I noticed it yesterday when I tried to relist Wikipedia:Articles for deletion/Chris Powell (politician), and getting it again right now when trying to close Wikipedia:Articles for deletion/Ethan Cooper. -- RoySmith (talk) 15:42, 19 October 2018 (UTC)

If I open the Developer Tools javascript console (Version 69.0.3497.100 (Official Build) (64-bit), MacOS), I see:

index.php?title=User:Evad37/extra.js&action=raw&ctype=text/javascript:149 Uncaught TypeError: Cannot read property 'prototype' of undefined
    at Object.extraJs.makeRcatCapsuleMultiselect (index.php?title=User:Evad37/extra.js&action=raw&ctype=text/javascript:149)
    at Dialog.setup (index.php?title=User:Evad37/XFDcloser/v3.js&action=raw&ctype=text/javascript:2054)
    at Discussion.openDialog (index.php?title=User:Evad37/XFDcloser/v3.js&action=raw&ctype=text/javascript:650)
    at HTMLSpanElement.<anonymous> (index.php?title=User:Evad37/XFDcloser/v3.js&action=raw&ctype=text/javascript:758)
    at HTMLSpanElement.dispatch (load.php?debug=false&lang=en&modules=jquery%2Coojs-ui-core&skin=vector&version=161h4dh:69)
    at HTMLSpanElement.elemData.handle (load.php?debug=false&lang=en&modules=jquery%2Coojs-ui-core&skin=vector&version=161h4dh:65)
extraJs.makeRcatCapsuleMultiselect @ index.php?title=User:Evad37/extra.js&action=raw&ctype=text/javascript:149
Dialog.setup @ index.php?title=User:Evad37/XFDcloser/v3.js&action=raw&ctype=text/javascript:2054
Discussion.openDialog @ index.php?title=User:Evad37/XFDcloser/v3.js&action=raw&ctype=text/javascript:650
(anonymous) @ index.php?title=User:Evad37/XFDcloser/v3.js&action=raw&ctype=text/javascript:758
dispatch @ load.php?debug=false&lang=en&modules=jquery%2Coojs-ui-core&skin=vector&version=161h4dh:69
elemData.handle @ load.php?debug=false&lang=en&modules=jquery%2Coojs-ui-core&skin=vector&version=161h4dh:65

-- RoySmith (talk) 15:48, 19 October 2018 (UTC)

Having this issue as well. The quick close option still works for keep and delete though. ---- Patar knight - ^chat/_{contributions} 16:16, 19 October 2018 (UTC)

Same, at RfD. I only noticed today, and indeed it worked for a bit: it started between these two edits of mine. If RoySmith noticed it yesterday, presumably my cache didn't clear until after I'd run it at least once today? ~ Amory (u • t • c) 16:24, 19 October 2018 (UTC)

Nay, the issue propped up a bit earlier, see my report. I thought the edit here yesterday might have borked things but the previous version also fails, must be a WP:THURSDAY API clobber Galobtter (pingó mió) 16:35, 19 October 2018 (UTC)

Same issue here. Sandstein 17:10, 19 October 2018 (UTC)

Relieved to find out it's not me who's bolixed my machine. As above, operated yesterday but no joy today. Nosebagbear (talk) 18:15, 19 October 2018 (UTC)

I think it is because "OO.ui.CapsuleMultiselectWidget" was removed in phab:T183299 while line 149 of User:Evad37/extra.js still uses it. Galobtter (pingó mió) 18:42, 19 October 2018 (UTC)

Ok, I've disabled the problematic function (rcat selector) at User:Galobtter/xfdcloser_test.js and it now appears to work. Ping @KCVelaga, RoySmith, Patar knight, Amorymeltzer, Sandstein, and Nosebagbear: as until Evad comes along to fix this properly I think that's the best we've got :(. Galobtter (pingó mió) 19:01, 19 October 2018 (UTC)

@Galobtter: - hmm, no joy in either closing or relisting on my behalf, I guess I'll need to wait until Evad is free. Not being helped by the watchlisting issue as while the notification came up, it didn't appear in my watchlist (hence why I pinged) Nosebagbear (talk) 19:18, 19 October 2018 (UTC)

Nosebagbear, I have to clarify, you have to replace "User:Evad37/XFDcloser.js" with "User:Galobtter/xfdcloser_test.js" (temporarily) in Special:MyPage/common.js as no edits to the actual script have been made yet. Galobtter (pingó mió) 19:25, 19 October 2018 (UTC)

Ah! Thanks for that. Nosebagbear (talk) 19:46, 19 October 2018 (UTC)

Yup, confirmed, User:Galobtter/xfdcloser_test.js appears to fix the problem. Thanks! -- RoySmith (talk) 19:56, 19 October 2018 (UTC)

Yep this works, thanks! I had to copy paste the the script name manually, instead of using the installation script. ---- Patar knight - ^chat/_{contributions} 21:02, 19 October 2018 (UTC)

Say what? There's an installation script? I've always just installed these things manually. Which might explain why I'm still running User:Mr.Z-man/closeAFD.js :-) -- RoySmith (talk) 21:47, 19 October 2018 (UTC)

User:Equazcion/ScriptInstaller. Makes installing scripts a breeze. :) ---- Patar knight - ^chat/_{contributions} 21:59, 19 October 2018 (UTC)

It hasn't been updated in a couple of years, so it might not work anymore though. ---- Patar knight - ^chat/_{contributions} 22:01, 19 October 2018 (UTC)

Pile-on to confirm that Galobtter's fix works. Thanks :) ♠PMC♠ (talk) 21:19, 19 October 2018 (UTC)

@Galobtter: Thanks for your work, but your script still hangs at "Closing..." for me, even after clearing the browser cache. Sandstein 09:32, 20 October 2018 (UTC)

Sandstein, could you copy what error you get in the javascript console? Galobtter (pingó mió) 09:57, 20 October 2018 (UTC)

Galobtter, weirdly, I now get two interfaces side by side as here (https://imgur.com/a/QBz7v8M), even though only your script is loaded. The second one works, and the first yields the following console output on Chrome:

Uncaught TypeError: Cannot read property 'prototype' of undefined
   at Object.extraJs.makeRcatCapsuleMultiselect (index.php?title=User:Evad37/extra.js&action=raw&ctype=text/javascript:149)
   at Dialog.setup (index.php?title=User:Evad37/XFDcloser/v3.js&action=raw&ctype=text/javascript:2054)
   at Discussion.openDialog (index.php?title=User:Evad37/XFDcloser/v3.js&action=raw&ctype=text/javascript:650)
   at HTMLSpanElement.<anonymous> (index.php?title=User:Evad37/XFDcloser/v3.js&action=raw&ctype=text/javascript:758)
   at HTMLSpanElement.dispatch (load.php?debug=false&lang=en&modules=jquery&skin=vector&version=00rdyep:69)
   at HTMLSpanElement.elemData.handle (load.php?debug=false&lang=en&modules=jquery&skin=vector&version=00rdyep:65)
extraJs.makeRcatCapsuleMultiselect @ index.php?title=User:Evad37/extra.js&action=raw&ctype=text/javascript:149 
Dialog.setup @ index.php?title=User:Evad37/XFDcloser/v3.js&action=raw&ctype=text/javascript:2054
Discussion.openDialog @ index.php?title=User:Evad37/XFDcloser/v3.js&action=raw&ctype=text/javascript:650
(anonymous) @ index.php?title=User:Evad37/XFDcloser/v3.js&action=raw&ctype=text/javascript:758
dispatch @ load.php?debug=false&lang=en&modules=jquery&skin=vector&version=00rdyep:69
elemData.handle @ load.php?debug=false&lang=en&modules=jquery&skin=vector&version=00rdyep:65

So it seems the old script is still loaded, even though it's no longer present in User:Sandstein/common.js. Sandstein 11:58, 20 October 2018 (UTC)

Sandstein, you should remove "importScript('User:Mr.Z-man/closeAFD.js');" from your vector.js and monobook.js. closeAFD now merely loads XFDcloser. Galobtter (pingó mió) 12:02, 20 October 2018 (UTC)

Looks like a fair number of people are still loading from Mr.Z-man. — Preceding unsigned comment added by RoySmith (talk • contribs)

RoySmith quite a few more actually; see [7] - importscripts don't add links Galobtter (pingó mió) 15:53, 20 October 2018 (UTC)

• @Galobtter, want to just push the fix to the main script? It's inoperable without it. czar 19:17, 20 October 2018 (UTC)

  Can't. As a user script, it's only editable by the owner and script admins (the new class of admin that can edit pages like this). Primefac (talk) 22:42, 20 October 2018 (UTC)

oof. Guess that's what I get for not following that whole affair. Wonder how many editors are enjoying their increased security right now... 😩 czar 22:59, 20 October 2018 (UTC)

I've pinged Oshwah. Primefac (talk) 23:45, 20 October 2018 (UTC)

I'm here. What do I need to do? ~Oshwah~^{(talk) (contribs)} 23:48, 20 October 2018 (UTC)

I just implemented this fix. Let me know if there are still issues. ~Oshwah~^{(talk) (contribs)} 23:54, 20 October 2018 (UTC)

Thanks Oshwah! Galobtter (pingó mió) 04:06, 21 October 2018 (UTC)

You may go back to using User:Evad37/XFDcloser.js per fix being deployed to main script (not that it matters too much since User:Galobtter/xfdcloser test.js now calls User:Evad37/XFDcloser/v3.js, the current version of the script) Galobtter (pingó mió) 05:42, 21 October 2018 (UTC)

My only concern now is that it doesn't actually do anything other than close the discussion. I closed two TFDs yesterday (after the fix was implemented) and it didn't edit any of the related pages. Primefac (talk) 12:53, 21 October 2018 (UTC)

Primefac, huh, that shouldn't be happening. Any errors or anything in JS console? I just tested it now in one of Evad's sandbox TFD logs and it worked fine. So with redirecting. Galobtter (pingó mió) 13:02, 21 October 2018 (UTC)

Could be user-side (and/or a cache issue), but I even undid my edit just on the off chance I had closed the page too early. If it's working for you, chances are it is something on my end. Primefac (talk) 13:09, 21 October 2018 (UTC)

EDIT: Yeah, I think it was something on my end - last night there was something about a "simple version" in the close box, and I just checked on the test pages and it works fine. Primefac (talk) 13:11, 21 October 2018 (UTC)

Oh yeah, "basic version" basically doesn't do much. I believe it happened because the Tfd links weren't formatted properly (used ":" instead of "*" before each {{tfd links}} so Xfdcloser was unable to detect the pages being closed.) Galobtter (pingó mió) 13:20, 21 October 2018 (UTC)

 Fixed. The Rcat selector is back (now based on OO.ui.MultiselectWidget rather than OO.ui.CapsuleMultiselectWidget) - Evad37 [talk] 10:42, 21 December 2018 (UTC)

Non-admin closures

{{resolved}}

Since non-admins sometimes close AFD's (myself included), there needs to be a way to automatically mark a closure as a non-admin closure.—Mythdon (talk • contribs) 09:42, 28 October 2018 (UTC)

The script already does this. Primefac (talk) 17:05, 28 October 2018 (UTC)

Thanks. I haven't used the script yet, and it didn't mention anything like that on the documentation page.—Mythdon (talk • contribs) 17:27, 28 October 2018 (UTC)

 Added to the documentation - Evad37 [talk] 16:00, 21 December 2018 (UTC)

Something wrong with the script

{{User:ClueBot III/ArchiveNow}}

see Wikipedia:Articles_for_deletion/Log/2018_October_30#University Over the Abyss and below. It seems to have closed the entire log, not just the AfD entry. I have never seen it do this before. ^{[Username Needed]} 10:21, 2 November 2018 (UTC)

• I do not know if it actually used the script, but I presume so, since it looks identical to all other closed XfDs. ^{[Username Needed]} 10:25, 2 November 2018 (UTC)

  Fixed. Someone manually did the close and forgot to put {{Afd bottom}} Galobtter (pingó mió) 10:30, 2 November 2018 (UTC)

XFDC removing only the bottom portion of the RfD template

{{resolved}}

I've got a small bug for you: I closed Wikipedia:Redirects for discussion/Log/2018 February 18#Redirects to List of current UFC fighters as "no consensus", a large group of 40-something redirects. On a few of the redirects, XFDC only removed the bottom half of the RfD template, essentially breaking the redirect. Comparing diffs of Oscar Piechota (a broken one) to Lauren Mueller (not broken), the script seems to fail when there is a leading space before the RfD template. (Shout out to Ivanvector who has fixed one of them.) -- Tavix ^(talk) 21:52, 28 February 2018 (UTC)

Tavix might be right about what it's doing, but I thought I observed that it was simply reverting to a prior revision. On Oscar Piechota someone had edited the page after the rfd code was placed, removing half of it and breaking it. I undid that, and my undo was the last revision before Tavix closed. I thought that xfdcloser just reverted to the revision before mine. Ivanvector (^Talk/_Edits) 13:35, 1 March 2018 (UTC)

 Fixed - Evad37 [talk] 08:39, 23 December 2018 (UTC)

Bug? extraJs is not defined

{{User:ClueBot III/ArchiveNow}}

I'm using the "Show an alert when you encounter Javascript errors" gadget, and when I went to TfD today, I got an error popup for each section there:

https://en.wikipedia.org/w/index.php?title=User:Evad37/XFDcloser/v3.js&action=raw&ctype=text/javascript at line 881: ReferenceError: extraJs is not defined

The script then failed, leaving "[Close] [Relist] [Error retrieving page information (reload the page to try again) [API error: undefined]]" on the page. —DoRD (talk)​ 21:20, 2 August 2018 (UTC)

What's happened is that first, an error occurred while trying to retrieve page information from the API. And then when trying to format the error details (line 881), extraJs (which is loaded from a separate script) wasn't ready in time. Thus the error message became "undefined" instead of something meaningful. So even if there wasn't that javascript error, the main error (from the API) still would have occurred. In the next major version/rewrite of the script, I might just remove the dependence on extraJs. It turns out having modular/resuable code there makes things easier in some ways, but also makes things more complicated in other ways. - Evad37 [talk] 04:11, 3 August 2018 (UTC)

Unlinking backlinks progress?

{{resolved}}

Would it be possible to provide more detailed progress indication? When I'm closing AfDs with lots of backlinks, I often get to the stage where it says, Unlinking backlinks: and a rotating-three-box progress indicator, and then just sits there. I never know if it's actually making any progress (in which case I should just be patient), or if it's hung (in which case I should close the page). Awesome tool, though. Thanks for providing it. -- RoySmith (talk) 14:34, 7 August 2018 (UTC)

@RoySmith:  Done, there's now also an updating note of the number of pages processed. - Evad37 [talk] 09:43, 22 December 2018 (UTC)

Talk page notices

{{User:ClueBot III/ArchiveNow}}

I just noticed that the Old TFD notices are not being placed on "close as merge" template talks. Are they not included because the end result is generally a redirect, or is this a glitch? Primefac (talk) 16:43, 23 September 2018 (UTC) For example, these two sets of "merge" closes that didn't do anything to their respective talks.

@Primefac: I think the rationale for not tagging the talk pages for templates added to the holding cell (in general, not just merges) was that the {{Being deleted}} template already includes a link to the TfD discussion, and the pages are going to end up deleted or redirected sooner or later. But I suppose it wouldn't hurt to have the talk page tagged while the template is listed at the holding cell (except for "Ready for deletion", which are instead tagged for speedy deletion). - Evad37 [talk] 04:08, 24 September 2018 (UTC)

Fair enough, just couldn't remember. Primefac (talk) 10:16, 24 September 2018 (UTC)

API error bug, September 2018

{{User:ClueBot III/ArchiveNow}}

@Evad37: Attempting to close Wikipedia:Articles for deletion/Jabal Tu'us as "delete" yields the error message: "Closing discussion: Aborted.API error: aborted: possible edit conflict (found section heading `:Jabal Tu'us`) – Could not edit page Wikipedia:Articles for deletion/Jabal Tu'us; could not close discussion". Other AfDs produce the same error. Thanks, Sandstein 15:01, 28 September 2018 (UTC)

• • same for me, regards Atlantic306 (talk) 18:59, 28 September 2018 (UTC)
  • And me! --Malcolmxl5 (talk) 01:01, 29 September 2018 (UTC)
  • Same here. Salvio ^{Let's talk about it!} 01:15, 29 September 2018 (UTC)

@Sandstein, Atlantic306, Malcolmxl5, and Salvio giuliano:  Fixed, should work as expected now - Evad37 [talk] 01:36, 29 September 2018 (UTC)

It works now! Thanks Evad, this tool is extremely useful. Salvio ^{Let's talk about it!} 01:39, 29 September 2018 (UTC)

Thanks for fixing! It is a great tool indeed, helps a lot! --Tone 11:22, 29 September 2018 (UTC)

Sorry, but it does not look fixed to me on File:Elon Musk's submarine.jpg. Jo-Jo Eumerus (talk, contributions) 05:58, 8 October 2018 (UTC)

Wikipedia:Files for discussion/2018 September 30 in general seems to have this issue. Jo-Jo Eumerus (talk, contributions) 06:05, 8 October 2018 (UTC)

Its the ones where the section heading uses HTML-encoded punction, such as & instead of & which is making the script think it might not be the same section (so it aborts to avoid possibly editing the wrong section). - Evad37 [talk] 01:52, 9 October 2018 (UTC)

@Jo-Jo Eumerus:  Fixed - Evad37 [talk] 02:34, 9 October 2018 (UTC)

Seems like it works now. Thanks! Jo-Jo Eumerus (talk, contributions) 06:07, 9 October 2018 (UTC)

(←) Similar case for me when I wanted to procedural close Wikipedia:Articles for deletion/Jabal Ghumaylah earlier:
Closing discussion: Aborted. [API error: aborted: possible edit conflict (found section heading `Jabal Ghumaylah`) – Could not edit page Wikipedia:Articles for deletion/Jabal Ghumaylah; could not close discussion]
Thanks, Sam Sailor 19:45, 18 October 2018 (UTC)

 Possibly resolved? I couldn't reproduce in my sandbox just now... and there haven't been any further reports of such behaviour. - Evad37 [talk] 12:41, 24 December 2018 (UTC)

Problems with XFDCloser closing TfDs with lots of templates

{{resolved}}

I was closing this discussion with XFDCloser and it managed to close the discussion, list the templates at the holding cell and tag their talk pages for deletion but it didn't tag all the templates for deletion. There were fifteen templates for deletion and XFDCloser only tagged one and didn't tag the other fourteen. Is there a problem with XFDCloser in handling TfDs with lots of templates. Pkbwcgs (talk) 19:35, 14 October 2018 (UTC)

Looks like none of the templates (after the first) were tagged with the TFD notice. I thought that the script didn't care about that, but I might be wrong. Primefac (talk) 19:47, 14 October 2018 (UTC)

 Fixed now. The unexpected lack of a nomination templates was causing the error. - Evad37 [talk] 13:01, 24 December 2018 (UTC)

Not loading

{{resolved}}

Hi, this worked great but then it stopped so I deleted it and readded it later but now it wont load at all and am getting the following javascript error: index.php?title=User:Evad37/XFDcloser/v3.js&action=raw&ctype=text/javascript at line 1772: SyntaxError: Unexpected token ')' , please advise Atlantic306 (talk) 15:22, 10 November 2018 (UTC)

• It works on my android phone but not on my ipad which is running ios 9.35 safari and opera, thanks Atlantic306 (talk) 19:26, 12 November 2018 (UTC)

@Atlantic306: I think this was from a minor syntax error, from when the rcat selector stopped working and was commented out. I've since redone that section of code, so hopefully XFDcloser should now work on all your devices. - Evad37 [talk] 13:05, 24 December 2018 (UTC)

Thanks its working great now, it is an excellent tool that simplifies a convuleted process and saves a lot of time, thanks Atlantic306 (talk) 21:55, 25 December 2018 (UTC)

Request addition for RFD relists

{{Resolved}}

In regards to how this script relists WP:RFD discussions, specifically the discussion that are bulk nominations. Is it possible for the script to additionally perform the following task:

• Update "parameter 2"’s value in the invoked Module:RfD on each nominated redirect that appears under the section header of the section that is relisted? (“Parameter 2” is the parameter that states what the name of the section header is that the "this redirect's entry" link forward the reader on the appropriate page.) I'm asking because whenever a multi-redirect discussion gets relisted, edits like this one have to be made to ensure that the reader gets forwarded to the correct section on the page where the discussion was initially posted; otherwise, the reader/link clicker is forwarded to the intital daily subpage, but not to any section since no section header on that page.

(The other possible option is to change the month=, day= and year= parameters on each nominated redirect on a discussion, but doing so breaks certain categories that are dependent on those values having the date which the redirects were nominated, not which subpage they are currently listed.) Steel1943 (talk) 22:24, 19 December 2018 (UTC)

@Steel1943:  Done, discussions with two or more pages will now have parameter 2 added to the invoked Module:RfD - Evad37 [talk] 06:54, 28 December 2018 (UTC)

It works!!! That is awesome! (I seriously did not think it would be possible, but it has, and I’m quite content.) Steel1943 (talk) 18:49, 31 December 2018 (UTC)

User talk

{{Resolved}}

If the closer is deleting a primary user page, it should not automatically delete the corresponding user talk page. This only applies to the primary user page. User talk sub-pages are OK. Ie. if user:Foo is being deleted, user_talk:Foo should not be deleted. But if user:Foo/sandbox is being deleted, it is fine to auto delete user_talk:Foo/sandbox. I have just been told off for letting the closer delete User talk:Alisoofastaei. — RHaworth (talk · contribs) 22:37, 1 January 2019 (UTC)

@RHaworth:  Done, base user talk pages will now be skipped. - Evad37 [talk] 03:11, 2 January 2019 (UTC)

Many thanks and, gosh, what a swift response! — RHaworth (talk · contribs) 18:53, 3 January 2019 (UTC)

Unlinker shouldn't touch DYK noms

Resolved

 – for XFDcloser; section copied to User talk:Evad37/Xunlink.js

Review unlinked list item

Template:Did you know nominations/Ralph Tarrant#Ralph_Tarrant:

*... that 109-year-old '''Ralph Tarrant''' is currently the United Kingdom's oldest living man?

This was one of my prompts when closing an AfD discussion today. I think the unlinker could skip the whole Template:Did you know nominations space, as those ostensibly shouldn't be unlinked. (Would this apply to the WP:Xunlink tool as well?) czar 22:43, 5 December 2018 (UTC)

@Czar:  Done for XFDC. (Will need to update Xunlink later also) Evad37 [talk] 13:09, 30 December 2018 (UTC)

Unlinking hangs

{{Resolved}}

The AfD unlinker has been hanging for me today. Not sure if it's related to this error in the JS console:

load.php?debug=false&lang=en&modules=jquery&skin=monobook&version=00rdyep:51

jQuery.Deferred exception: confirmedPromise.then is not a function TypeError:

confirmedPromise.then is not a function

at https://en.wikipedia.org/w/index.php?title=User:Evad37/XFDcloser/v3.js&action=raw&ctype=text/javascript:5137:24

at mightThrow (https://en.wikipedia.org/w/load.php?debug=false&lang=en&modules=jquery&skin=monobook&version=00rdyep:48:856)

at process (https://en.wikipedia.org/w/load.php?debug=false&lang=en&modules=jquery&skin=monobook&version=00rdyep:49:516)

czar 02:39, 14 January 2019 (UTC)

@Czar:  Fixed. Thanks for posting the console error, that made it easy to find the problem. - Evad37 [talk] 03:48, 14 January 2019 (UTC)

Early closes

{{Resolved}}

Hi, please have a look at the discussion at Wikipedia talk:Articles for deletion#Early closes again. Would it be possible that XFDcloser displays a warning if you try to close an XFD before the 7 days have passed? Only a warning, because it should still be up to the closer to decide whether they want to close early (SNOW closes, for example). Thanks! --Randykitty (talk) 13:55, 8 January 2019 (UTC)

I'll second this request. For one thing, if an editor using this tool does not read a discussion closely enough to know "manually" (for want of a better term) that the discussion has been open for less than seven days, they may not have read it closely enough to properly assess consensus. A warning that "Hey, you missed this..." might give them pause. Hijiri 88 (聖やや) 14:27, 8 January 2019 (UTC)

I use Wikipedia:Articles for deletion/Old to see what needs closing. Up till now, I assumed that anything in the list "7 days old" was ripe for closing, but it turns out that is incorrect, as some AfDs may be in that list but up to 12 hours short of 7 days. Still, the time stamp next to the nom will say "7 days ago". I don't think that it is a sign of negligence when one assumes that these indications are correct. --Randykitty (talk) 14:40, 8 January 2019 (UTC)

Well, in fairness I'd say this is a good idea just to prevent "whoops" moments - I've had it happen in the past where I'm flipping through TFD days and accidentally close a discussion on the wrong day! A polite warning isn't necessary only for those who are closing things a few hours early, but also for the bleary-eyed who might not be paying as much attention as they should. Primefac (talk) 20:28, 8 January 2019 (UTC)

Ha, I once closed half of a log before I realized I was on the wrong one! Definitely a very good idea to have Xfdcloser detect such things. Galobtter (pingó mió) 11:33, 9 January 2019 (UTC)

FWIW User:Amorymeltzer/oldafd.js (fixed from splarka) will color AfDs that are past the 168 hour mark as long as you get in the habit of closing from the individual page, not the day's menu. ~ Amory (u • t • c) 22:18, 8 January 2019 (UTC)

Hi all, I'll look into coding this in the next few days. I think I'll also add custom classes the to headings of xfds that are both early and old, so that users can add in their common/skin CSS their own colours and styles, for either early or old xfds. - Evad37 [talk] 09:31, 9 January 2019 (UTC)

 Partly done @Randykitty, Hijiri88, Primefac, Galobtter, and Amorymeltzer: Headings now have the class xfdc-old, xfdc-notOld, or xfdc-unknownAge added, based on the time since listing/relisting. By default this styles them with a background-color of green, red, or yellow respectively. Styling can be adjusted using your common or skin css file. I've haven't a implemented a warning/confirmation dialog yet. - Evad37 [talk] 05:58, 12 January 2019 (UTC)

Thanks for that, but I think highlighting is a bit too much-ish - i.e for me somewhat of bright distraction when trying to close things; not sure if it should be styled by default, though the option is of course good. A warning/confirmation dialog would be nice though. Galobtter (pingó mió) 07:04, 12 January 2019 (UTC)

Maybe something a bit more subtle? Could just highlight the "close", "quickClose", and "relist" links rather than the whole header. Galobtter (pingó mió) 07:05, 12 January 2019 (UTC)

I love it! Thanks so much Evad37! --Randykitty (talk) 09:20, 12 January 2019 (UTC)

Slick! I can see the argument for just the close options, but regardless it's gorgeous. ~ Amory (u • t • c) 11:41, 12 January 2019 (UTC)

Alternative style

If anybody else finds the coloured backgrounds a bit much, copy the following into your common.css to use subtler, text-only warnings:

/* XFDcloser */
.xfdc-notOld, 
.xfdc-old,
.xfdc-unknownAge {
	background: inherit !important;
}

.xfdc-notOld .xfdc-status:after { content: "Less than 7 days old"; color: #b32424; }
.xfdc-old .xfdc-status:after { content: "More than 7 days old"; color: #14866d; }
.xfdc-unknownAge .xfdc-status:after { content: "Unable to detect discussion age"; color: #fc3; }

.xfdc-status:after {
	font-size: 92%;
	margin-left: 13px;
}

– Joe (talk) 14:24, 12 January 2019 (UTC)

Nice! Galobtter (pingó mió) 14:32, 12 January 2019 (UTC)

• Great idea (and kudos for implementing it so quickly), but I'll quibble with the implementation. How about instead of background colors, if it's not old, change the "Close" link to say "Speedy close". My CSS-fu is pretty weak, so not sure how hard it is to do that. -- RoySmith (talk) 17:21, 12 January 2019 (UTC)
  • @RoySmith: Try using

    .xfdc-notOld .xfdc-action:first-child a:before { content: "Speedy "; }
    

    - Evad37 [talk] 03:29, 19 January 2019 (UTC)
• Wanted to chime in and say I like the background colors as is. Nice work, Evad! czar 20:43, 12 January 2019 (UTC)

Caveats

I have a caveat for when the green heading displays incorrectly. User:Cyberbot I/AfD's requiring attention lists a bunch of AfDs going stale, usually with comments like

Automated comment: This AfD was not correctly transcluded to the log (step 3). I have transcluded it to Wikipedia:Articles for deletion/Log/2019 January 7.

The seven days counter should start from the time of that transclusion, not the original poster's date. Would it be possible to adjust for this? Or at the very least, the discussion shouldn't show a green heading if it hasn't been seven days from the time of transclusion.

I'll add that Relisted discussions can really be closed at any time as long as the consensus is clear and the original weeklong listing period is over. I would personally display those as orange headings, since they can proceed at the closer's discretion and shouldn't be viewed as a hard do-not-touch/red. czar 17:12, 13 January 2019 (UTC)

Updated

@Randykitty, Hijiri88, Primefac, Galobtter, Amorymeltzer, Joe Roe, RoySmith, and Czar: The latest update

• Shows a popup warnings for discussions that aren't old
• Detects "not transcluded correctly" comments, and uses that comment's date if found
• Detects relisted xfds, and adds the class xfdc-relisted to the heading. If it has been less than seven days since the last relist, they are styled with an orange background colour (by default)
• Styles the action-links instead of the whole heading by default, as most of you preferred something less intrusive. The following adjustments can be made in your user CSS page:

Turn off action-link background colours:

.xfdc-notOld .xfdc-action, 
.xfdc-old .xfdc-action,
.xfdc-unknownAge .xfdc-action,
.xfdc-relisted.xfdc-notOld .xfdc-action {
	background: inherit !important;
}

Restore background colours for the whole heading:

.xfdc-old { background-color:#c6ffc6 }
.xfdc-notOld { background-color:#ffc6c6 }
.xfdc-unknownAge { background-color:#ffffc6 }
.xfdc-notOld.xfdc-relisted { background-color:#ffe9c6 }

- Evad37 [talk] 03:16, 19 January 2019 (UTC)

• Cool, thanks! -- RoySmith (talk) 03:38, 19 January 2019 (UTC)

The subtler indicators are nice, thanks! Galobtter (pingó mió) 05:50, 19 January 2019 (UTC)

• Great, thanks!! --Randykitty (talk) 07:15, 19 January 2019 (UTC)

Underscores

{{Resolved}}

Doesn't replace underscores with spaces when closing some things, see e.g this deletion log, too my recollection this is a recent thing. Galobtter (pingó mió) 08:27, 11 January 2019 (UTC)

I don't think its anything new; the fragment (section heading) has always been encoded. I seem to recall that not too long ago, such links in edit summaries and on log pages had to have the spaces encoded as underscores, or else the page wouldn't be scrolled to the appropriate section when the link was clicked. But in any case, yes this is something that can be fixed. And actually, MFDs don't even need the fragment since they have their own subpages. - Evad37 [talk] 09:21, 11 January 2019 (UTC)

Must be that I've only been noticing this now since I've been doing the deleting myself since I've become an admin :) Galobtter (pingó mió) 09:42, 11 January 2019 (UTC)

In my experience, level 1 and 2 headings are the only ones that don't require underscores in URL target encoding. czar 20:45, 12 January 2019 (UTC)

The deletion log for Category:Hungarian supercentenarians shows that spaces are (now) okay in level 4 headings - Evad37 [talk] 02:56, 21 January 2019 (UTC)

@Galobtter and Czar:  Done, spaces will now be used instead of underscores - Evad37 [talk] 03:28, 21 January 2019 (UTC)

Thanks! Galobtter (pingó mió) 05:33, 21 January 2019 (UTC)

Detecting edit/close conflicts?

{{Resolved}}

I recently closed Wikipedia:Articles for deletion/Peter Gandy (author). I started on the close, got distracted by a urge to make a fresh pot of tea, and by the time I got back to it, User:Randykitty had relisted it without my realizing. So, I ended up closing it over his relist.

What would be cool is if XFDcloser could capture the timestamp of the AfD page when you start the process, and then check to make sure it hasn't changed before starting on the actual close. This wouldn't completely eliminate any possible race condition, but it would cut the vulnerable window down to a very short span of time. The cost would be an extra network access, but that's not a big deal. -- RoySmith (talk) 18:05, 20 January 2019 (UTC)

I think I can do it in way without an extra network access, since I can record the timestamp from when the script loads, and compare it to the revision timestamp at the time of editing (which is already being retrieved for a different type of edit conflict detection). That would narrow the window for this type of conflict to between the time the sever sends you the page and the time the script starts running. This type of check would only be feasible for AfDs and MfDs, since the other venues have multiple discussions on the same page and a newer edit in a different section would give a false positive. - Evad37 [talk] 01:30, 21 January 2019 (UTC)

@RoySmith:  Done - Evad37 [talk] 02:09, 21 January 2019 (UTC)

You are amazing. Thanks! -- RoySmith (talk) 02:53, 21 January 2019 (UTC)

Early closes

{{User:ClueBot III/ArchiveNow}}

Following up to User_talk:Evad37/XFDcloser.js/Archive_3#Early closes, I just discovered that, in addition to the red/green colorization, if you early close something, you also get a pop-up warning asking you to confirm your action. Nice touch, thanks again for doing this. -- RoySmith (talk) 16:42, 31 January 2019 (UTC)

@RoySmith: You're welcome! And yep, that was part of the update to the feature. - Evad37 [talk] 01:22, 1 February 2019 (UTC)

WP:CFD relists?

{{resolved}}

Well, after years of mulling on this, I have finally installed this script. I wanted to use it to work on WP:CFD nominations, but ...

Is this script capable of relisting WP:CFD nominations? Just wondering since I'm not seeing a "relist" option while on WP:CFD. (If this information helps, I'm using Safari.) Steel1943 (talk) 18:52, 30 January 2019 (UTC)

Evad37 The script would need to be updated to account for the change to nomination templates done in this diff. Galobtter (pingó mió) 21:01, 30 January 2019 (UTC)

@Steel1943 and Galobtter: The script is always set to basic mode for CFDs because at the time I wrote it, I was finding it difficult to detect nominated categories (especially when multiple pages where nominated), and there wasn't much support for (semi-)automation at WT:CFD. I can certainly take another look at it. - Evad37 [talk] 02:22, 31 January 2019 (UTC)

@Steel1943 and Galobtter:  Done, the script can now relist CFDs, including updating the date in the nomination templates. Closes are still limited to basic mode at this stage. - Evad37 [talk] 13:39, 14 February 2019 (UTC)

Old RfD date error

{{resolved}}

Not sure how I didn't notice this until now, but ...

...Looks like when XFDcloser is closing RfD discussions, when applying {{Old RfD}} to the talk page for non-"delete" results, the tool is posting the date of the log page in the date= parameter rather than the date the nomination actually occurred. These two dates will mismatch 99.9% of the time when a discussion is relisted. this diff shows what I corrected based on the previous edit that XFDcloser made on that page's edit history. Steel1943 (talk) 06:02, 14 February 2019 (UTC)

Maybe you can retrieve the date when the template was added to the redirect? (For AfD, you can use the creation of the page, but redirects don't have their own RfD subpages AFAIK) --DannyS712 (talk) 06:03, 14 February 2019 (UTC)

@Steel1943 and DannyS712: This was working before, but apparently I broke it when I implemented age-detection. Should be  Fixed now. - Evad37 [talk] 14:41, 14 February 2019 (UTC)

[Bug] CfD relist error

{{resolved}}

When relisting a CfD, the script doesn't respect the "new nominations" instructions. Edits: [8] [9] [10]. This then requires edits like [11] to clean it up. Thanks, --DannyS712 (talk) 07:23, 9 March 2019 (UTC)

@DannyS712:  Fixed, reslisted discussions will now be placed below the "NEW NOMINATIONS" heading - Evad37 [talk] 00:32, 13 March 2019 (UTC)

Relisting TFD ended up re-closing the discussion?

Resolved

 – Not a bug, just one of the many slight differences between the XfD venues - Evad37 [talk] 09:33, 18 March 2019 (UTC)

Please see this diff. As part of Wikipedia:Deletion review/Log/2019 March 9, I backed out a number of WP:TFD closes and relisted them. To my surprise, when I did the relist, XFDcloser re-closed the discussions. Unclear what's going on there. Could somebody please look at it and fix whatever went wrong? Thanks. -- RoySmith (talk) 15:13, 16 March 2019 (UTC)

RoySmith, discussion relisted at Wikipedia:Templates for discussion/Log/2019 March 16 Hhkohh (talk) 15:19, 16 March 2019 (UTC)

Ah, I understand. It closed it for the original date, and created a new entry under today's date for the relist. As a side note, it's silly (and inefficient) that the various XfD all manage their queues slightly differently. -- RoySmith (talk) 17:02, 16 March 2019 (UTC)

[Bug] Very unusual situation

@Evad37: At Wikipedia:Articles for deletion/Gabe McBee something unusual happened that is unlikely to be repeated much but I just thought I'd let you know. The problem doesn't arise in the actual close; but rather in the removal of the template on the page. Since the page was moved inside the discussion's timeframe, the script checked the redirect for the nomination template, but not the new target (Draft:Gabe McBee). I suspect an easy fix could be available using the code for the redirect/target message just before the close. Cheers, J947 ^(c), at 04:30, 4 March 2019 (UTC)

If the nominated page is a redirect, the script is supposed to ask the closer whether to apply actions to the redirect page or its target. Will have to investigate further. - Evad37 [talk] 13:22, 4 March 2019 (UTC)

Yes it did, I chose target. J947 ^(c), at 19:03, 4 March 2019 (UTC)

So then it's a bug that it tried to edit the redirect, instead of the target page. Thanks for clarifying. - Evad37 [talk] 05:25, 5 March 2019 (UTC)

• Just got something similar with Wikipedia:Articles for deletion/Raine chawla. I was prompted with "Raine chawla → Raine Chawla" and chose the target, but the only page deleted was the redirect. I had to delete the target manually. czar 21:16, 10 March 2019 (UTC)

@J947 and Czar: Found the bug, should be  Fixed now - Evad37 [talk] 09:21, 18 March 2019 (UTC)

Thanks! J947 ^(c), at 18:04, 18 March 2019 (UTC)

{{resolved}}

[Feature request] Speedy Delete XfD closes by non-admin

{{Resbox}}

Hi, Would you be able to allow the speedy close as delete function to be unlocked when the page is already deleted but the admin forgot to close?

I know it's not for here but I've also really toiled over your RfA, I wish you good luck and don't want you to think I believe you would abuse tools but just think you need a bit more at this time (especially given you made this (see my follow up Q)). I've now actually made a RfA criteria now if you want to look at it. RhinosF1^(chat)_{(status)(contribs)} 18:29, 13 February 2019 (UTC)

@RhinosF1: Since its not available, I just use the "custom" field and say deleted or already deleted. You could do that until Evad enables it. --DannyS712 (talk) 18:36, 13 February 2019 (UTC)

DannyS712, I was aware of the custom field and have used it. RhinosF1^(chat)_{(status)(contribs)} 18:38, 13 February 2019 (UTC)

I oppose this as-worded; if the page has already been deleted, it should not be closed implying that the closer was the one making that "delete" decision. The custom field should be used in these cases. Primefac (talk) 18:59, 13 February 2019 (UTC)

Primefac, I get where you're coming from. Would a 'already deleted by Example as reason be a better option. RhinosF1^(chat)_{(status)(contribs)} 19:51, 13 February 2019 (UTC)

I suppose, but I do wonder how often this happens and if it's worth the extra coding. If it's an easy switch, sure. Primefac (talk) 19:53, 13 February 2019 (UTC)

This seems like the perfect scenario for a custom close message! ~ Amory (u • t • c) 03:12, 14 February 2019 (UTC)

• I too doubt that this is worth the feature creep—how often does this happen?—but up to Evad czar 16:42, 16 February 2019 (UTC)
  • I've thought about this, and I'm in agreement with Primefac, Amory, and Czar: The custom close option is already provided for non-standard or infrequent situations such as this, and that the proper wording would be "already deleted by {Admin} as {deletion reason}" - Evad37 [talk] 23:32, 17 February 2019 (UTC)

[Compatibility] Breaks script-installer

Not an XFDCloser bug

 – Should be fixed on the script-installer side. - Evad37 [talk] 01:12, 20 March 2019 (UTC)

Because you have multiple links in the script infobox, Enterprisey's script-installer parses it incorrectly and generates invalid code in the common.js. Not sure which side this should be fixed on (hence the ping to Enterprisey). Gaelan 💬✏️ 00:06, 8 March 2019 (UTC)

Hmm. I'll probably have it make the install button work for only the first script linked. Enterprisey (talk!) 20:16, 8 March 2019 (UTC)

@Enterprisey: {{Infobox Wikipedia user script}} has a |mainsource= parameter for auto-installers – you should be using that if it is present. - Evad37 [talk] 00:23, 9 March 2019 (UTC)

Relisting

  New bug

Hi. I just relisted a number of AfDs, and on one of them (ClassifEye) the relisting failed to comment the page out from the old log, despite adding it to the new log. The other relistings went fine. See here for the contributions - I don't know how to make the times more precise, sorry. Thanks, --DannyS712 (talk) 00:13, 9 February 2019 (UTC)

@DannyS712: The script should note any errors it encounters in the status notes next to the section heading. Or there may be relevant info in the browser's Javascript console – see point #6 of WP:JSERROR. I can't see any obvious reason why it would have failed... perhaps you managed to edit-conflict with yourself? (though the script does try to prevent that from happening) - Evad37 [talk] 01:59, 9 February 2019 (UTC)

Just found out about this edit. Thanks, --DannyS712 (talk) 00:27, 13 February 2019 (UTC)

Probably related to the other issue you had with the ClassifEye relist - Evad37 [talk] 00:34, 13 February 2019 (UTC)

@DannyS712: Were you using the script on the daily log page, or on individual AFD subpages? - Evad37 [talk] 01:16, 13 February 2019 (UTC)

@Evad37: Individual subpages --DannyS712 (talk) 01:17, 13 February 2019 (UTC)

@DannyS712: Ah, that explains why the existing edit-conflict prevention measures didn't work. Until I work out how to fix this, can you (if using individual subpages) make sure that the first relist has finished before commencing a second relist? - Evad37 [talk] 01:21, 13 February 2019 (UTC)

@Evad37: Sure. Do they only work from the main page? --DannyS712 (talk) 01:23, 13 February 2019 (UTC)

Yeah, in terms of automatic edit-conflict prevention... when there are multiple discussions on the same page, there is only a single instance of the script running, and it can keep track of when a relisting starts and ends to make sure the processes happen in order:

• Read wikitext of page (for relist #1)
• Save edit for relist #1 (creating a new revision)
• Read wikitext of new revision (for relist #2)
• Save edit for relist #2

Without this tracking, this can happen out of order:

• Read wikitext of page (for relist #1)
• Read wikitext of page (for relist #2)
• Save edit for relist #1 (creating a new revision)
• Save edit for relist #2 (effectively undoing the previous edit, since it was based on the earlier revision)

- Evad37 [talk] 01:39, 13 February 2019 (UTC)