MediaWiki talk:Gadget-DelReqHandler.js

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Gadget

[edit]

Now available as a gadget : MediaWiki:Gadget-DelReqHandler.js. le Korrigan →bla 10:53, 5 December 2007 (UTC)[reply]

Eek! This is for admins only. Do non-admins get that in their "gadget" tab in their preferences, too? They shouldn't. Lupo 11:12, 5 December 2007 (UTC)[reply]
Yes, they do... but the tool doesn't work for non-admins, don't worry. le Korrigan →bla 11:35, 5 December 2007 (UTC)[reply]
I know it won't work for non-admins, after all I wrote it. A pity gadgets doesn't support display of utilities based on user privileges yet. Lupo 11:46, 5 December 2007 (UTC)[reply]
Oh, sorry, I didn't know you are the author. For this issue, see bugzilla:12211. le Korrigan →bla 12:28, 5 December 2007 (UTC)[reply]
Doesn't seem to be working, see Commons:Administrators'_noticeboard#Problems_with_gadgets. — Giggy 05:33, 29 December 2007 (UTC)[reply]


Updates required

[edit]

I am not quite sure how exactly this gadget functions, as I am not an admin. But from the looks of it, the following updates are required (per COM:DR):

  1. Change the header and footer templates to the ones mentioned at Commons:Deletion_requests#How_to_close_a_discussion
  2. The header template should be placed just below the header, not above. The current format doesn't work well (have a good look at this to see what I mean). Nearly all well established archives (at en.wiki) are done this way.

--Rehman 02:35, 2 January 2011 (UTC)[reply]

I have not received any report from an admin actually using it that something needed changing. I just used it myself a few days ago to close a DR, and it worked perfectly. The DR also got properly archived by the bot. I therefore see no need whatsoever to change this in any way. Lupo 23:39, 8 January 2011 (UTC)[reply]
Well I am an admin reporting it ;) The current DelReqHandler works (but not perfectly). Currently, when you click "del" via this gadget, it places:
{{Delh}}
== HEADER.ext ==
DISCUSSION

----
Deleted. ~~~~
{{Delf}}
Which is wrong. It should now be:
== HEADER.ext ==
{{DeletionHeader}}
DISCUSSION
{{DeletionFooter|DELETE/KEEP|OPTIONAL-COMMENT. ~~~~}}
I could update this myself, but I'm not really sure how... Rehman 00:35, 9 January 2011 (UTC)[reply]
When did that change? Has DRbot been updated accordingly so that archiving works? And what's wrong with the old way? Lupo 09:50, 9 January 2011 (UTC)[reply]
The changes were made about a month ago. Am not really sure about DRBot though, I will ask the operator to look into this now. The header template is just merely renamed, so just a matter of avoiding the redirect there. The new footer basically compresses the amount of text put in each deletion closure, and more importantly supports auto-translations (although none are included yet). Rehman 10:12, 9 January 2011 (UTC)[reply]
[edit]

The link in Preferences>Gadgets needs to be changed to the new location for these pages.      Jim . . . . Jameslwoodward (talk to me) 13:58, 16 February 2011 (UTC)[reply]

I presume you meant this link? Done. Lupo 14:01, 16 February 2011 (UTC)[reply]

Problem

[edit]

Yesterday, everything was fine. Today, DelReqHandler is not putting the "[del][keep]" buttons/links on some images for me. The "[d][del][k][keep][edit]" buttons still appear for each DR. For example, at Commons:Deletion_requests/2011/02/02, the buttons do not appear on

  • File:AntropologyMuseumAztecSoneOfTheSun.jpg
  • File:Фото561.jpg
  • File:日月旗.svg

while they do appear on

  • File:Moskau_PD_2010_054.JPG [del] [keep]
  • File:Moscow_city_1.jpg [del] [keep]
  • File:Gotthold_Weil2.jpg [del] [keep]
  • File:Groen_links_stemmers.png [del] [keep]

I cannot see any particular pattern to it.

I'm running Firefox 3.6.13 on XP Pro.      Jim . . . . Jameslwoodward (talk to me) 14:04, 16 February 2011 (UTC)[reply]

Fixed. There was still one spot in the script where the page title was derived from the title attribute of the link. That's bad practice, and I thought I had eliminated all these long ago. With MW1.17 now, some of the links do no longer have the page name in the title attribute. For these links, no del/keep links were added. I don't know why some headers still have titles and others don't. In any case, that's solved now; the script extracts the page title from the URI of the link. Don't forget to MediaWiki:Clearyourcache while on a DR page, for instance on Commons:Deletion requests/2011/02/02. Lupo 14:26, 16 February 2011 (UTC)[reply]
Looks good to me. Thank you very much for the fast work. The script is much faster...      Jim . . . . Jameslwoodward (talk to me) 16:38, 16 February 2011 (UTC)[reply]

Recent changes

[edit]

When I clicked on "delete" for an image, I got:

"Error: http://commons.wikimedia.org/w/index.php?title=MediaWiki:Gadget-DelReqHandler.js&action=raw&ctype=text/javascript&50254970 at line 101: event is not defined" in a box above the header "Commons:Deletion requests/2011/02/07". The image was not deleted.

I'm running Firefox 3.6.13 on Win XP Pro.      Jim . . . . Jameslwoodward (talk to me) 11:52, 21 February 2011 (UTC)[reply]

Also, when I clicked on "close deleted", I got:

"Error: http://commons.wikimedia.org/w/index.php?title=MediaWiki:Gadget-DelReqHandler.js&action=raw&ctype=text/javascript&50254970 at line 101: event is not defined"

With the old version, we had five buttons for closing the DR:

  • K -- keep without comment
  • Keep -- keep with comment
  • D -- delete without comment
  • Delete -- delete with comment
  • Edit -- comment without closing

The new version appears to have only three, although there may be something I don't understand because it isn't working. I would oppose the reduction in choice, as I use all five regularly, totaling something over five hundred times a month.      Jim . . . . Jameslwoodward (talk to me) 12:01, 21 February 2011 (UTC)[reply]

Fixed, you need to purge your cache. You still have all choices. Just leave the input box (which should be shown now) blank to delete w/o comment--DieBuche (talk) 12:12, 21 February 2011 (UTC)[reply]
I've got similar errors too, on performing various other activities. Probably something to do with the MediaWiki update? Rehman 12:04, 21 February 2011 (UTC)[reply]
What other activities?--DieBuche (talk) 12:12, 21 February 2011 (UTC)[reply]
OK now, in fact, "Great" A couple more keystrokes, but fewer page loads, therefore significantly faster. I like the "approximate rendering", as it saves page reloading to remember exactly where you are.
Could I be greedy and ask for buttons that do delete all or keep all in a Mass DR. Clearly we must be able to pick and chose some of the time, but much of the time, long Mass DRs are just painful....      Jim . . . . Jameslwoodward (talk to me) 14:10, 21 February 2011 (UTC)[reply]
I thought about that, but it could easily lead to errors. Imagine someone writing in the discussion "Image:xyz.jpg has the same problem, but was confirmed by OTRS a while ago" etc. Delete All would probably delete it as well--DieBuche (talk) 14:14, 21 February 2011 (UTC)[reply]
I also like the fact that the link status changes immediately, so you don't have to remember where you are in a long list. As for the potential for great harm deleting a long list, perhaps a second "Are you sure box" and/or a presentation of the candidates -- "About to delete All of the following, are you sure?"      Jim . . . . Jameslwoodward (talk to me) 14:17, 21 February 2011 (UTC)[reply]
Have a look at it now. You can just click the links at the same time & it will process them in parallel.--DieBuche (talk) 14:44, 22 February 2011 (UTC)[reply]
Sorry, but maybe I'm being dumb today -- I can't make it work. If I click on a [del] at the end of the image link, the summary box comes up and clicking on more links has no effect. I'm at Commons:Deletion_requests/2011/02/10#Courtesy_photos_from_navy.mil which is a perfect trial as it has a lot of deletes.      Jim . . . . Jameslwoodward (talk to me) 15:02, 22 February 2011 (UTC)[reply]
Have you tried purging your cache/restarting Firefox? It works for me in FF 3.6 and FF4--DieBuche (talk) 15:10, 22 February 2011 (UTC)[reply]


@DieBuche: I've experienced similar errors when simply adding/removing content from my watchlist, and even when simply loading random files... Rehman 15:42, 21 February 2011 (UTC)[reply]

Sorry to say, there is a little something wrong. It has hung twice while deleting an image. Right now, hung

     Jim . . . . Jameslwoodward (talk to me) 16:34, 21 February 2011 (UTC)[reply]

In general I like the new version, but I also saw it crash already two times. Jcb (talk) 23:11, 21 February 2011 (UTC)[reply]
It crashed on me once as well, haven't yet found the cause.--DieBuche (talk) 14:44, 22 February 2011 (UTC)[reply]

I would call this a serious bug in the new version. Jcb (talk) 23:47, 23 February 2011 (UTC)[reply]

Fixed. --DieBuche (talk) 10:08, 24 February 2011 (UTC)[reply]
[edit]

Sometimes DR subpages contain several deletion requests (see e.g. Commons:Deletion requests/File:AlYaquob2.jpg), some of which have already been closed. If this is the case, no "Close: ...." links are generated for the current request. Regards, -- ChrisiPK (Talk|Contribs) 23:00, 26 April 2011 (UTC)[reply]

That's there so that we have to close some DRs by hand, to remind us just how great an improvement DelReqHandler is. ;-)      Jim . . . . Jameslwoodward (talk to me) 20:56, 21 August 2011 (UTC)[reply]
Bump, that's still an issue that needs fixing, this is extremely unpleasant for DRs with large amount of images. Workaround requires to edit previous DR and move the closing DR template to the bottom while elimination all other DR openings (except the first) and closing inbetween. --Denniss (talk) 20:37, 20 May 2014 (UTC)[reply]
Despite my flip answer above, I agree that this would be nice. .     Jim . . . . (Jameslwoodward) (talk to me) 10:40, 21 May 2014 (UTC)[reply]

New Problem?

[edit]

At the moment, looking at a DR log page, I see

[edit] [Close: Kept] [Close: Deleted]

as usual to the right, but I do not see

[keep][delete]

on any of the individual files. This is true for several different logs -- Commons:Deletion_requests/2011/08/23 and Commons:Deletion_requests/2011/08/24 and all the others I have looked at.      Jim . . . . Jameslwoodward (talk to me) 13:10, 1 September 2011 (UTC)[reply]

Probably related to the experimental switching on of protocol-relative URL support. I just made a change to account for that. Is it better now (after reloading your browser's cache)? Lupo 13:28, 1 September 2011 (UTC)[reply]
Yes, fixed, thank you.      Jim . . . . Jameslwoodward (talk to me) 13:31, 1 September 2011 (UTC)[reply]

Old scripts

[edit]

I've marked

as superseded by this gadget. If I'm wrong about this please clarify. Also, I have a suspicion MediaWiki:Duplicate.js may also be superseded, but I'm not sure. Thanks, Rd232 (talk) 00:40, 13 November 2011 (UTC)[reply]

DR proposed close

[edit]

Please add support for the {{DR proposed close}} template. Also, if you could switch the template's use of {{Delf}} with {{DeletionFooter}}, that would be great. The script already gets an optional comment to plug into that template, and it already knows the keep/delete result for the other parameter, so it is not a big change. At the same time, would it be possible to create a much larger textbox (5 lines high, and wider) when the script requests the optional summary? It seems very small at the moment. Rd232 (talk) 18:24, 1 December 2011 (UTC)[reply]

New Problem?

[edit]

I have noticed that when doing a close-as-deleted, perhaps half of the time over the last week that DRH does not completely delete the file -- that it, the DR is closed, but the file remains a blue link. If you go to the file page, it has been deleted, but the page remains partly visible. If you use the pulldown "purge" (below "delete"), then it will come up in the DR as a redlink. I'm using Firefox 10.0.1 on XP-pro.      Jim . . . . Jameslwoodward (talk to me) 12:32, 14 February 2012 (UTC)[reply]

Nothing we can change here. It is a server related issue and now on bugzilla:35047. Feel free to add a screenshot. -- RE rillke questions? 00:03, 8 March 2012 (UTC)[reply]

Error pages[id].revisions is undefined

[edit]

Trying to close Commons:Deletion requests/All files copyrighted in the US under the URAA I get Error: https://commons.wikimedia.org/w/index.php?title=MediaWiki:Gadget-DelReqHandler.js&action=raw&ctype=text/javascript&58757173 at line 199: pages[id].revisions is undefined. Rd232 (talk) 18:44, 19 February 2012 (UTC)[reply]

Same: when doing a "kept" at Commons:Deletion requests/Files uploaded by Blackburn2001: Error: https://commons.wikimedia.org/w/index.php?title=MediaWiki:Gadget-DelReqHandler.js&action=raw&ctype=text/javascript&58757173 at line 199: pages[id].revisions is undefined. Error persisted after reloading. --Saibo (Δ) 21:24, 13 March 2012 (UTC)[reply]
Same here, something broken again with the new MW-Software? --Denniss (talk) 15:07, 19 April 2012 (UTC)[reply]

Undelete in...

[edit]

I suspect this is a big request, but how about adding a check box and entry box for adding:

<noinclude>[[Category:Undelete in XXXX]]</noinclude>

in the closed DR, where, of course, XXXX is a year that comes from the entry box.

     Jim . . . . Jameslwoodward (talk to me) 11:36, 31 March 2012 (UTC)[reply]

Problem?

[edit]

I could not close Commons:Deletion requests/Files uploaded by DLSDPM as Kept with the gadget, I just got the box with "Working ...", which stayed for a very long time until I closed the browser tab. No edit was made. I tried this several times yesterday and today. Closing the DR as "Deleted" however worked instantly. Strange. --Rosenzweig τ 19:08, 11 July 2012 (UTC)[reply]

Use of tool leading to complacency

[edit]

At this point in time I am having issues with admins use of this tool without, it seems, checking on the effects of the file removal. It is too easy to solely look at the argument in the DR and to not look at the use of a file. I believe that part of the issue is that the discussion argument page does not show the usage of the files xwiki at sister sites, so admins just read the argument then hit delete, and the consequences flow outwards. Can we look to have the global usage data to be included on the page? Obviously this is not about necessarily changing the ultimate decision, but looking to have a mindful approach to the resolution of a removal. My issues relate to some DRs that should actually be treated as duplicate requests, and some removals where the files should be transferred to the relevant wikis as fair use or the file can be kept at that wiki under their licence requirements.  — billinghurst sDrewth

not adding kept desiccion

[edit]

Can somone help us here? Thx--Sanandros (talk) 10:51, 3 March 2013 (UTC)[reply]

Tool not working

[edit]

I do not work much with DRs, but when I wanted to close some today this tool does not seem to be working for me. I do not see any keep/delete/close links. I tried it with 2 different computers and on Firefox and chrome. Any ideas? --Jarekt (talk) 03:33, 19 June 2014 (UTC)[reply]

Derivate script für undeletion

[edit]

I've analysed the code detailed (and it can be a bit optimized) for a new similar script for undeletion. Just few comments:

  1. mw:API talk:Edit #The intoken parameter has been deprecated
  2. There are some unused functions and variables (nothing, title, reload)
  3. there is an jQuery loop (each for every headline) which functions in there should be outsourced.
# I mean this var task = this.currentTask = this.tasks.shift(); is not proper JavaScript. I'm wondering that this is working.
↔ User: Perhelion (Commons: = crap?)  11:35, 11 May 2015 (UTC)[reply]
Multiple assignment is fine in ECMA script. What is the issue with #4? -- Rillke(q?) 22:03, 11 May 2015 (UTC)[reply]
Okay, I was never aware of this (I learned other programming languages before js ^^) thanks. ↔ User: Perhelion (Commons: = crap?)  07:57, 12 May 2015 (UTC)[reply]
A suggestion was to merge this scripts. I think a proper solution is to use the functions as library. ↔ User: Perhelion (Commons: = crap?)  08:29, 21 May 2015 (UTC)[reply]

jQuery Selector Bug

[edit]

{{Edit request}} See report User_talk:FDMS4#Frage here Commons:Deletion_requests/Archive/2015/06/09#File:.22Inevitable_Reality.22.jpg on the i-icon. I guess there must be some other than .find-method. ↔ User: Perhelion (Commons: = crap?)  09:01, 25 June 2015 (UTC)[reply]

The (PD) icon was "missing" link=, now fixed. Maybe the gadget should also ignore class=noviewer files?    FDMS  4    09:09, 25 June 2015 (UTC)[reply]
Okay, the appearance has disappeared (because the requirements for the bug are simply removed), but the bug still exists. Anything outside from headlines should be ignored (except of the delh and delf). ↔ User: Perhelion (Commons: = crap?)  09:26, 25 June 2015 (UTC)[reply]
Oh* Is see now the script works nearly as intended: line 72: //We have an image link
I found now another bug, as the [keep] & [del] buttons should only appear on unclosed sections: line 67:
I suggest to travel only a single level down the DOM (the sections). The idea to exclude class=noviewer is good (would be .not('.noviewer')), but with replace of the .find method, we also not need this. Then we must replaced on line 66:
- var links = discussion.find('a');
- links = links.add(headLink).not('.new');
+ var links = discussion.children('a').not('.new');

also must be changed for bug 2: 

-			var headLink = $t.find('span.mw-headline a').eq(0);
-			var title = (headLink.length && !headLink.is('.new')) ? DelReqHandler.titleFromHref(headLink.attr('href')) : "";
+			var headLink = $t.find('span.mw-headline a').not('.new').eq(0);
+			var title = (headLink.length) ? DelReqHandler.titleFromHref(headLink.attr('href')) : "";

↔ User: Perhelion (Commons: = crap?)  00:58, 26 June 2015 (UTC)[reply]

The suggested change is breaking the tool. No del/keep links showing up at all. --Steinsplitter (talk) 12:07, 9 November 2015 (UTC)[reply]
@Steinsplitter OK, it seems I've not tested it correct. I've now another code, see below. Another issue, can it be that no del/keep links showing one after an closed topic?? ↔ User: Perhelion (Commons: = crap?)  01:41, 6 January 2016 (UTC)[reply]

user defined default reasons for keep and delete

[edit]

I would like to be able to configure default reasons for keeping and deleting a file which should appear in the input box for manual override if necessary. Is this possible? --Krd 19:06, 5 January 2016 (UTC)[reply]

Yes it is possible, good idea. What do you think for a default message? I mean one default and one for your user custom configuration!? ↔ User: Perhelion (Commons: = crap?)  22:07, 5 January 2016 (UTC)[reply]
Here is a version for testing. You can now configure/define the default reasons about this variables:
window.delReqReason = "as above";
window.keepReqReason = "no reason for deletion";

↔ User: Perhelion (Commons: = crap?)  01:38, 6 January 2016 (UTC)[reply]

I wouldn't set a system default, but my personal default could be "deleted per nomination" and "kept per discussion". This covers 99% of all deletion requests. --Krd 05:16, 6 January 2016 (UTC)[reply]
It works very well, right hand at mouse, left hand at enter key, no longer need for crtl-v. Great! Please deploy. --Krd 05:20, 6 January 2016 (UTC)[reply]
Tested & deploy. @Perhelion: Thanks :-). --Steinsplitter (talk) 08:41, 6 January 2016 (UTC)[reply]
Ok good. Maybe (with a next edit) we could mention this new possibility with this variables in the desc. header. Successful new Year. :-) ↔ User: Perhelion (Commons: = crap?)  14:31, 6 January 2016 (UTC)[reply]
@Perhelion: Ok. I added a notice here. Thanks again for providing the code! --Steinsplitter (talk) 16:23, 6 January 2016 (UTC)[reply]

To me, e.g. no reason for deletion Krd or as above Yann look weird and may confuse newbies. I suggest adding either a full stop after the reason or -- in front of the signature. --Leyo 00:14, 11 January 2016 (UTC)[reply]

I agree, a signature should always start with --. --Krd 07:44, 11 January 2016 (UTC)[reply]
I agree too. But this is a bit more difficult, because some admins have custom signatures!? (I'm not but my sig as example).
A solution would be to stripe out any customization from the signature!?
I also would add a sentence point if not present. I could do write this code!? ↔ User: Perhelion (Commons: = crap?)  10:30, 11 January 2016 (UTC)[reply]
Adding a full stop should be a good idea in any case. --Krd 10:38, 11 January 2016 (UTC)[reply]
Ok the code for test is here. I've not tested yet really! (Krd) ↔ User: Perhelion (Commons: = crap?)  11:15, 11 January 2016 (UTC)[reply]
I am in favor of your suggestion to stripe out the customization from the signature. A similar approach may be used to resolve MediaWiki talk:Gadget-AjaxQuickDelete.js#Dashes in signature, too. --Leyo 12:02, 11 January 2016 (UTC)[reply]
@Krd, Leyo Please test, I've now also tweaked a couple of minor fixes (not existing templates, bit code simplification). This should not be needed anymore. This is also fixed (summary). ↔ User: Perhelion (Commons: = crap?)  16:56, 11 January 2016 (UTC)[reply]
Looks good for me. --Krd 17:02, 11 January 2016 (UTC)[reply]
Thanks, I've another thought. I see many admins have custom signatures, but I removed the customization stripe out, because I mean many don't would be like it. So I suggest only add the -- if the customized ('fancysig') sig begins with an Wiki-link. I guess that would be ok for most admin-users. To add only to admins with standard-sig would be a bit too strange IMHO. ↔ User: Perhelion (Commons: = crap?)  17:15, 11 January 2016 (UTC)[reply]
Are you sure those are "custom signatures"? It might just be interference with MediaWiki:Gadget-markAdmins.js. Other JS scripts do not work right with MediaWiki:Gadget-markAdmins.js activated. For example I use default signature but the script adds "(A)" behind my name --Jarekt (talk) 18:53, 11 January 2016 (UTC)[reply]
@Jarekt: No there is no conflict with it, because the signature get not changed or recolonized on the HTML level (only dashes get added to Wikitext).
Final version from me. (@Krd: I don't see you activate again my version? :-P) ↔ User: Perhelion (Commons: = crap?)  19:08, 11 January 2016 (UTC)[reply]
Sorry, I though I was late and the version was already live. At least I saw the "--". --Krd 04:14, 12 January 2016 (UTC)[reply]
@Krd Hm no, this was only temporarily. You have not again included my version, so anyway nobody is testing this version, so nobody made this version live (until this). ↔ User: Perhelion (Commons: = crap?)  00:08, 17 January 2016 (UTC)[reply]
Tested now, and it seems slightly broken. "TypeError: dE[3].unblock is not a function" --Krd 12:36, 17 January 2016 (UTC)[reply]
Personally, I would not mind having --[[User:{{subst:REVISIONUSER}}|]] ~~~~~ as a signature in DRs. DRs are more formal than talk pages in general. --Leyo 23:35, 11 January 2016 (UTC)[reply]
I personally can understand this, but this general issue must be solved elsewhere. So currently custom sigs are furthermore possible. ↔ User: Perhelion (Commons: = crap?)  12:33, 12 January 2016 (UTC)[reply]
┌─────────────────────┘

@Error: [un]block This error seems new by missing something (jQuery) from the ResourceLoader and is not related to the last changes here. ↔ User: Perhelion (Commons: = crap?)  13:39, 17 January 2016 (UTC)[reply]

I have to correct myself: The problem only occurs when using you page while having the gadget disabled. When the gadget in on the links appear double, and all of the work fine. --Krd 16:41, 17 January 2016 (UTC)[reply]

Enabling gadget for categories for discussion

[edit]

There is a huge backlog at Commons:Categories for discussion. I think this is partly due to the fact that DelReqHandler does not work for closing these discussions. Thus, I would suggest adding this feature to the gadget. --Leyo 00:05, 11 January 2016 (UTC)[reply]

I mean this could be better added to this MediaWiki:Gadget-UndelReq.js (I'm not sure to create a separate gadget). Because there is also no deletion required. If someone agree I could do this. ↔ User: Perhelion (Commons: = crap?)  19:13, 11 January 2016 (UTC)[reply]
If i remember correctly there exists such a script yet. But i am unablle to find it right now. --Steinsplitter (talk) 19:49, 11 January 2016 (UTC)[reply]
Seems to be User:King of Hearts/closecfd.js (untested!) --Steinsplitter (talk) 19:52, 11 January 2016 (UTC)[reply]
Oh good, I see this is the same author for User:King of Hearts/closeudel.js. I mean I do merge this in to the existing gadget. ↔ User: Perhelion (Commons: = crap?)  20:00, 11 January 2016 (UTC)[reply]
IMHO there is no good reason for not having the functionality of closing CFD in the Gadget-DelReqHandler, since the type of tasks is very similar (just files vs. categories).
User:King of Hearts/closecfd.js is quite short. King of Hearts may provide us with further information. --Leyo 23:30, 11 January 2016 (UTC)[reply]
You are maybe right. I've done a merged version with Gadget-UndelReq.js.[1] But I now see that there is more needed. Removing template from the category and putting one on the talk page!? (Maybe this is the time to merge Gadget-UndelReq.js in this also here). ↔ User: Perhelion (Commons: = crap?)  00:38, 12 January 2016 (UTC)[reply]
But at first I would only merge the CFD feature in here. But this is a more or lesser big operation. I need first a little bit wider agreement. ↔ User: Perhelion (Commons: = crap?)  12:40, 12 January 2016 (UTC)[reply]
This page has 29 watchers. Hence, there might be other comments if need be. --Leyo 17:17, 12 January 2016 (UTC)[reply]

Please pardon me for this voluminous reply but I closed about 350 cfd requests during the past weeks and months so I know what I'm talking of. A button would be helpful but I think it would merely reduce the backlog. Closing normal file DRs is quite simple: keep the file or delete it. Closing cfd requests is a more complex thing for there are many different scenarios, for example

  • Kept per consensus
  • Kept due to lack of consensus
  • Deleted per consensus
  • Kept per "out of process scope" (user treated it as a topic discussion page)
  • Deleted per "out of process scope" (user didn't know of {{Speedy}})
  • Moved cat leaving a redirect
  • Moved cat without a redirect (bad name)
  • Merged content of dupe cats (one direction or the other)
  • Recategorising of files of a cat
  • Removing cat in case of "overcategorization"
  • More than 1 cat: "This req regards also [list of cats which are either tagged cfd or even not]"
  • Cfd refused per nonsense or vanadalism
  • even more scanarios not listed here...

So these two keep and delete buttons are not helpful here. If someone wants to create a gadget to be used for speeding up closing cfds, please provide 1 button close only. What should happen then?

  1. Kick off useless trash headers like to be seen here.
  2. Add {{Cfdh}} on top ✓[OK]
  3. Add "----" at the end ✓[OK]
  4. Open a text input field and add entered text ✓[OK]
  5. Add signature ✓[OK]
  6. Add {{Cfdf}} ✓[OK]
  7. Now the more difficult part: Remove {{Category for discussion}} tags from category page(s) and
  8. add a clickable link to the summary line that points to the discussion page (important in case a cat was moved)

The problem is that cfd discussion pages can be referenced by more than 1 category page. So one has to look up what links to the disc page, filter ns:14 and then remove the matching cfd tag if there is one. But one has to pay attention removing the right one for sometimes there are categories with more than one cfd tag (here for example).

Also greatly appreciated were a bot that could perform archiving of closed cfd requests. However, the archive "directory structure" differs from archiving DRs. --Achim (talk) 10:15, 16 January 2016 (UTC)[reply]

Hey Achim, thanks for feedback for detailed description. I become also aware of this feature requirements, some are already performed (see given link, I've set checkmarks to your list). The other seems also no problem to perform. ↔ User: Perhelion (Commons: = crap?)  00:18, 17 January 2016 (UTC)[reply]
You're welcome, thanks for your work! --Achim (talk) 11:20, 17 January 2016 (UTC)[reply]

image usage count

[edit]

I know this could be complicated, but it would help a lot if nearby the keep/del links of the individual images in the DR there was shown the current (realtime) file usage count. (For images nominated as out of scope/not in use to verify the not-in-use, and for images of heavy use as heads-up.) If one could manage this, drinks are on me next time we meet. Thank you! --Krd 09:43, 20 January 2016 (UTC)[reply]

Such a feature is contained in VisualFileChange and may be taken from there. --Leyo 10:57, 20 January 2016 (UTC)[reply]
+1 That is a feature which I also requested to Rillke as separate gadget (but he declared this is not the real count only estimated: Help:Gadget-GlobalUsageUI). ↔ User: Perhelion (Commons: = crap?) 13:18, 20 January 2016 (UTC)[reply]
Not only do you want the usage count, you want to know how you usually decide against files uploaded by said user, how others decide how old the user account uploaded the file is, how frequently you decide the same as the one how initiated the deletion request and what the keep vs. delete ratio is and whether someone other then the initiator or after more than a couple of days (2 or so) manipulated the deletion request, removing files nominated or added files. You also want a preview of the files being nominated and want to have a button to quickly display the file description page source code, history and the rendered version, uploader, upload date, upload history and upload size. All this should be arranged in a way that is helpful for the current situation, like in different views. Then you want to have an atomic operation: As soon as you close the deletion request, the files are deleted or marked as kept. In order to achieve such an operation, you want to mark the files for deletion or keeping beforehand, with a smart guess by the software (e.g. those struck through not being deleted). Finally you want the software to make a clever suggestion on the deletion or keeping rationale so you most likely only have to press the commit button. -- Rillke(q?) 14:19, 20 January 2016 (UTC)[reply]
No, I want the one piece of information that helps me to save >50% of work time for >50% of the deletion requests, i.e. all "private image, not used, out of scope" deletion requests from trusted users. Please do not overload information as in VisualFileChange, where I don't understand most of the features. --Krd 14:49, 20 January 2016 (UTC)[reply]
@Krd and Leyo: You can enable this feature now with window.delReqGlobalUsage = 1;, without any speedloss, s. #New faster version. ↔ User: Perhelion 15:38, 8 December 2016 (UTC)[reply]

Issue with closing second nomination

[edit]

Did this also happen with an earlier version of the gadget? --Leyo 14:09, 25 January 2016 (UTC)[reply]

It seems to happen for a few weeks. I have extended my archive bot to handle most of such cases, but I think it's still worth to fix it, if possible. --Krd 16:38, 25 January 2016 (UTC)[reply]
I'm looking for this. ↔ User: Perhelion (Commons: = crap?) 19:00, 25 January 2016 (UTC)[reply]
Thanks. BTW: insource:/\{\{delh\}\}.{0,3}\{\{delh\}\}/ currently yields ~120 hits. --Leyo 22:23, 25 January 2016 (UTC)[reply]
Fixed (btw. new feature). This issue is new because the "old" version couldn't close second nominations?? So this is a new feature now (which I implemented before only half, I only wondered why there are no "close" links). ↔ User: Perhelion (Commons: = crap?) 23:11, 25 January 2016 (UTC)[reply]
Yes, it is a new feature :) --Steinsplitter (talk) 20:03, 27 January 2016 (UTC)[reply]
✓ Done Good, and thanks for inserting. (Technical info: inserted text after the last delf is not supported, simply due performance reasons, and also in view of it is not allowed and supported by the ArchivBot) ↔ User: Perhelion 20:26, 27 January 2016 (UTC)[reply]

TypeError: pages[id].revisions is undefined

[edit]

DelReqHandler could not handle closing Commons:Deletion_requests/Files_of_User:Jérémy_labourel, failing with:

On Firefox 46.0.1 on Windows. Storkk (talk) 09:54, 17 May 2016 (UTC)[reply]

{{Edit request}}

I can confirm this. Strange, I looking for this. ↔ User: Perhelion 14:21, 17 May 2016 (UTC)[reply]
There was an extra empty API request, but this is strange, because this is absolutely not a rare case (maybe something had changed on the API). I exclude this case, here is a fixed version. ↔ User: Perhelion 15:18, 17 May 2016 (UTC)[reply]


✓ Done Awesome! Thank you! ~riley (talk) 17:51, 21 May 2016 (UTC)[reply]

Keep/del not showing

[edit]

Any idea why the keep/del links show for the first few sets on Commons:Deletion requests/Files in Category:Files uploaded by Josve05a (delete) but not the last two? (The penultimate one didn't show the links even when they were blue—later manually deleted.) czar 11:49, 17 May 2016 (UTC)[reply]

Same happened for me at Commons:Deletion_requests/Files_uploaded_by_Jafd88 (see History for my workaround)... DelReqHandler doesn't seem to be able to handle more than a couple subsections. Storkk (talk) 12:12, 17 May 2016 (UTC)[reply]
Yes, there are simply only 4 times automatic deletion of the same topic supported. The concerned number is the 4] on line end 43:
	var linkRegex = /Commons:Deletion_requests\/.*?&section=(T-)?[1-4]$/;
Anyway this feature is from me and new (some months), before you had always to solve double request per hand!? ↔ User: Perhelion 13:20, 17 May 2016 (UTC)[reply]
No idea how this used to happen: both Czar and I are newer admins than this piece of code... anyway, would there any performance, stability or memory-usage risks involved in changing the 4 to a higher number, say 25 or even 100? Storkk (talk) 13:29, 17 May 2016 (UTC)[reply]
Yes, this is a new feature which was added by Perihelion (Thanks!) --Steinsplitter (talk) 13:48, 17 May 2016 (UTC)[reply]
I mean there should be no problem, the concerned code can be changed to (unlimited):
	var linkRegex = /Commons:Deletion_requests\/.*?&section=(T-)?\d+$/;

↔ User: Perhelion 13:50, 17 May 2016 (UTC)[reply]

@Perhelion: Changed it to 9 (precaution?). It would be hard to add a automatic error reporting, similar to this (function autoreport)? Sometimes errors happen because wikimedia file storage issues. --Steinsplitter (talk) 13:53, 17 May 2016 (UTC)[reply]
@Steinsplitter: Okay yes, I mean any over 9 should be very rare and maybe need some more attention as this automatic script. ↔ User: Perhelion 13:56, 17 May 2016 (UTC)[reply]

New faster version

[edit]

If have a bit rewritten the code for much better performance (as I seen the big loop waste of resources). Beta script-code here. There is a huge DOM loop, (don't use jQuery in a huge loop, NEVER modify the DOM into a loop [2] with too many function in it, I've moved them down. So it should be more than 400% faster now (despite added 2 new features to each file-link. There is still slightly more latitude for speedup.)

Two new feature links are added (on request):

  • An usage badge for every file link (lib from Rillke)
  • A fast/quick delete link [qd], same as the [del] function, except for the prompt query

Ready for testing, feedback welcome. ↔ User: Perhelion 23:37, 28 May 2016 (UTC)[reply]

The script is now 20 times faster as before (tested ~29850 : ~1470 ms) . I mean for pages with 30sek time load (over 2000 links on only one normal day) or more this is a big issue (there is a bit more potential, as there is not all jQuery replaced in the load loop). ↔ User: Perhelion 03:58, 30 May 2016 (UTC)[reply]
It is unbelievable how slow jQuery is in a loop. On a bit more work this day, I removed all jQuery in the loop and now the script runs the whole page (of one half month with 10000 links in ~360 ~220 ms (now without GlobalUsage-badge, for this example page, the server alone needs up to 17-20 s to generate, and break then, as we can see on the end of the page),e.g. old version runs a page with 4000 links in 30.000ms)! °o° ↔ User: Perhelion 16:15, 30 May 2016 (UTC)[reply]
New version has been merged. Thanks a lot, thanks! :) --Steinsplitter (talk) 16:19, 30 May 2016 (UTC)[reply]

I wonder if the bug with Commons:WikiProject Chemistry/Deletion requests (appears to be empty) is caused by this update. --Leyo 22:11, 30 May 2016 (UTC)[reply]

Hello Leyo, you must be mistaken, it was impossible ever active on this page (only for the subpages). Or I'm not sure what you mean with bug. But If you wish we can activate it on it!? Regards ↔ User: Perhelion 23:08, 30 May 2016 (UTC)[reply]
PS: Oh* I see what you mean, I looking for this. How you start the script on this page? ↔ User: Perhelion 23:28, 30 May 2016 (UTC)[reply]
Fixed @Leyo: Here is the fixed version. ↔ User: Perhelion 00:35, 31 May 2016 (UTC)[reply]
Thanks a lot. I'll leave it to Steinsplitter or any other admin with high JS skills. --Leyo 20:27, 31 May 2016 (UTC)[reply]
@Perhelion: The new version has sometimes no [del] links and i get an error "TypeError: this[task] is not a function". --Steinsplitter (talk) 08:57, 1 June 2016 (UTC)[reply]
Fixed Yes that was intentionally, but you touched me one better. Thanks for review and insert. ↔ User: Perhelion 15:29, 1 June 2016 (UTC)[reply]
I've again a bit speedup the script. ↔ User: Perhelion 15:41, 8 December 2016 (UTC)[reply]
Very nice, thank you! --Krd 15:50, 8 December 2016 (UTC)[reply]

This tool for non-admins

[edit]

Hello, can this tool be used for non-admins like me? This is to make closing DRs as keep easier. If not, then can someone create a non-admin version of this? Closing DRs manually is tedious. Thanks, ★ Poké95 00:28, 26 October 2016 (UTC)[reply]

Hello Pokéfan, normally not. In which cases this is commonly to be used often? We could add simply an option for a privileged non-admin group for usage (without speedloss). What mean other thereto?
@Pokéfan95: For example you are in the group "License review" which could be an acceptable user-rigth for this functionality. Maybe rollbacker are too!? ↔ User: Perhelion 15:55, 8 December 2016 (UTC)[reply]
PS: I have this [now done] (for group rollbacker). If it should also be visible as gadget for others at this group, the main gadgets settings have to be extend. ↔ User: Perhelion 00:32, 9 December 2016 (UTC)[reply]
I think this should be used only by license reviewers. Not all rollbackers have experience in closing DRs (although that's rare actually), and I would just like someone who's more experienced in closing copyright-related DRs, which are license reviewers. Thanks, ★ Poké95 12:27, 9 December 2016 (UTC)[reply]
I'm a little uncomfortable with this, because I'd guess I disagree with about a quarter of the non-admin closures that I see, to various degrees. I don't think we should make it so much easier to close, unless non-admin closures are highlighted somewhere for review. Non-admin closures are also not a huge time-saver, so I don't really see the upside. Storkk (talk) 12:32, 9 December 2016 (UTC)[reply]
I agree with Storkk. --Steinsplitter (talk) 12:38, 9 December 2016 (UTC)[reply]
Okay... then we let it as it is, thanks for (belated) feedback. PS @Steinsplitter the latest version, in my namespace, should be anyway a bit faster. ↔ User: Perhelion 14:02, 9 December 2016 (UTC)[reply]
Okay done :-) --Steinsplitter (talk) 14:08, 9 December 2016 (UTC)[reply]
Thanks, the next similar scripts I'm on it to update (in near future) are the UndelReq and the (requested and forgotten) new ReqCFD (#Enabling gadget for categories for discussion, but there are some scripts more I'm on it). Have a nice Advent. ↔ User: Perhelion 23:06, 9 December 2016 (UTC)[reply]

closed DRs marked as minor edits

[edit]

I was just informed on my user talk page that my deletion requests are marked as minor edits when using this gadget. I have marked the option to mark my edits as minor by default in my preferences, could this be related? Also, is this fixable? Sebari – aka Srittau (talk) 21:27, 14 December 2016 (UTC)[reply]

 Support Hello Srittau, indeed, here is the fix. ↔ User: Perhelion 00:25, 15 December 2016 (UTC)[reply]
✓ Done Great, thank you! I have added the fix (minus the console.log). Sebari – aka Srittau (talk) 09:18, 15 December 2016 (UTC)[reply]
@Srittau: Eine kleine Sache noch: könntest du bitte noch die Übersetzung zu MediaWiki:Gadget-DelReqHandler aktualisieren? (der Teil mit FF ist überflüssig) MfG ↔ User: Perhelion 15:47, 15 December 2016 (UTC)[reply]
✓ Done Ich habe es auf {{Gadget-desc}} umgestellt, aktualisiert und gekürzt. Sebari – aka Srittau (talk) 00:20, 16 December 2016 (UTC)[reply]

Bug on date

[edit]

Hi,

See Special:Diff/227923761.

Should be 2016-12-22.

Thanks. --Thibaut120094 (talk) 07:44, 29 December 2016 (UTC)[reply]

Hello Thibaut, there is indeed a bug since the existence of this script. Here is a beta version with a fix, that means I've not done any test with it. ↔ User: Perhelion 02:18, 30 December 2016 (UTC)[reply]

{{Edit request}}

@Thibaut Sorry there was a mistake, I fixed it now with test or better local here with additional feature, see once below… -- User: Perhelion 09:32, 12 February 2017 (UTC)[reply]

-- User: Perhelion 01:47, 12 February 2017 (UTC)[reply]

@Thibaut120094 and Perhelion: Replaced with current version of User:Perhelion/Gadget-DelReqHandler.js. Sebari – aka Srittau (talk) 21:10, 5 March 2017 (UTC)[reply]
✓ Done Thank you! -- User: Perhelion 21:58, 5 March 2017 (UTC)[reply]

Request

[edit]

This is a wonderful tool -- I can dimly remember the days before we had it and I don't think we could keep up with today's volume without it. Needless to say, I use it a lot.

A request: In the case where the DR is a single image, thus:

File:Example.jpg [keep] [del] [qd] [Close: Kept] [Close: Deleted] [edit]

When you click on [qd], [keep] [del] [qd] disappear and [Close: Kept] [Close: Deleted] [edit] shift to the left. I have a tendency to click on [Close: Kept] just as the shift is happening so that I actually click on [Close: Deleted] and must then Cancel and try again. Occasionally -- once a month or so -- I don't catch the mistake and someone else lets me know.

Could either [keep] [del] [qd] remain in place. perhaps grayed out, until the DR is closed or their place be filled with spaces so that [Close: Kept][Close: Deleted] [edit] stay in the same place?

Thanks, .     Jim . . . . (Jameslwoodward) (talk to me) 12:03, 10 February 2017 (UTC)[reply]

I can only second this request. Sebari – aka Srittau (talk) 12:44, 10 February 2017 (UTC)[reply]
Ok, looking at it briefly, I can see three easy solutions: Moving the links next to the right border, moving the links below the headline, or moving the links in front of the headline. I prefer the first solution, which you can test out by adding the following to Special:MyPage/common.css:
.reqHandlerLinks2 { position: absolute; right: 0; }
All other solutions are more complex. Sebari – aka Srittau (talk) 15:16, 11 February 2017 (UTC)[reply]
I'll look for a complex solution. PS: ✓ Done Here is the feature for testing. Greetings -- User: Perhelion 22:52, 11 February 2017 (UTC)[reply]
PS: Or local here. -- User: Perhelion 09:32, 12 February 2017 (UTC)[reply]

Message left in the talk page of the redirect

[edit]

{{Edit request}} Hi, while closing Commons:Deletion requests/File:GWOTSM.jpg we had an issue. The file in the DR, GWOTSM.jpg, has been moved to Global War on Terrorism Service Medal during the DR. Nevertheless, when kept, the {{Kept}} template has been inserted in File_talk:GWOTSM.jpg and not in the talk page corresponding to the new name (Global_War_on_Terrorism_Service_Medal,_obverse.jpg). There is something to check? --Ruthven (msg) 12:18, 28 March 2017 (UTC)[reply]

Hello Ruthven, here is the fix (and with update to the new csrftoken and remove of the deprecated jquery.tipsy). -- User: Perhelion 22:14, 3 April 2017 (UTC)[reply]
✓ Done Awesome! Thank you! jdx Re: 10:36, 7 May 2017 (UTC)[reply]

Automatic addition of kept files to watchlist

[edit]

Whenever I 'keep' a file using this gadget, it automatically adds the file to my watchlist. That's rather annoying - I then have to manually go through and remove it from my watchlist. Is there a way to disable this, either with user js or in the tool itself? @Steinsplitter, Perhelion, Srittau, and Jdx: Pinging you since this is a low-traffic page and you seem to understand the inner workings of this tool. Thanks, Pi.1415926535 (talk) 00:26, 8 January 2018 (UTC)[reply]

Hello Pi, I would suggest to use the same window.AjaxDeleteWatchFile from AQD for this "option" (which could implemented immediately). -- User: Perhelion 19:24, 8 January 2018 (UTC)[reply]
Thank you, your change seems to have worked! Pi.1415926535 (talk) 00:40, 10 January 2018 (UTC)[reply]

Error

[edit]

Hi Perhelion!

After this edit, I get TypeError: undefined is not an object (evaluating 'this.pageIDs.pop') when I click [close: Deleted] in Commons:Deletion requests/Files uploaded by Laptopservicein. Any idea why / can you fix it? — regards, Revi 01:09, 26 January 2018 (UTC)[reply]

Same here. Jcb (talk) 01:20, 26 January 2018 (UTC)[reply]
Undid it, to make one of the heaviest-used admin tool work again. After you debug the problem, feel free to undo it with proper fix! Thanks. (Other admins: If you still experience failure, it's local browser cache. I experienced same problem, worked around by using incognito mode.) — regards, Revi 01:41, 26 January 2018 (UTC)[reply]
@-revi and Jcb: Sorry, I was a bit impatient and tired and probably a little overconfident. I should really be more careful. I added a feature for mass del/keep per section. I mean this should be useful, as there are sometimes more than hundred files (or over 1000)!? I've now (again) a version for test here: User:Perhelion/Gadget-DelReqHandler.js (it was more elaborate than expected, so maybe I was a little annoyed). -- User: Perhelion 09:56, 26 January 2018 (UTC)[reply]
That new feature is (imo) awesome, except our first attempt was... broken. But thank you for your improvements. — regards, Revi 02:57, 27 January 2018 (UTC)[reply]

Doesn't this new feature bear the risk that files linked as a reference/example in the discussion are getting deleted, too? Such deletion have already happened even without that feature. --Leyo 16:05, 26 January 2018 (UTC)[reply]

@Leyo: If the file is normally linked and has the small DelReqHandler buttons, indeed. So this feature should only be used with a prominent warning prompt and/or with opt-in!? Any example? E.g. stroked files can simply excluded. On the other hand we could only apply a "Keep all" button. -- User: Perhelion 18:15, 26 January 2018 (UTC)[reply]
A keep all button would not change that closing admin has to look what they are doing, we don't want 'this file was kept in a DR' notifications at the talk page of those files either. I think in general the proposed feature would be helpful. To reduce risk for error, maybe you could enable it only if there are e.g. over 5 files in the DR. I think that would exclude most of the DRs in which uninvolved files are mentioned. (E.g. DRs like file X is a low quality duplicate of file Y). Jcb (talk) 21:26, 26 January 2018 (UTC)[reply]
Or... +25 file links and process files only with * filelink? — regards, Revi 02:57, 27 January 2018 (UTC)[reply]
That is an idea. Additional we could prepend on the first ("Del all") click a checkbox on every file link (checked)!? @-revi, Jcb, and Leyo: -- User: Perhelion 18:03, 27 January 2018 (UTC)[reply]
I like both suggestions. --Leyo 23:45, 3 February 2018 (UTC)[reply]
@Leyo, -revi, Jcb, and Krd: I implemented all this conditions now, I would be glad if someone could test the new beta version (Mass proceeding). PS: You need first click the "MASS process" link, which creates checkboxes on each relevant link and unlocks the real mass proceeding links. -- User: Perhelion 09:46, 10 March 2018 (UTC)[reply]
@Leyo, -revi, Jcb, and Krd: (or every other admin) I still fixed few glitches, probable test could be Special:Diff/309656774/310030800 -- User: Perhelion 11:12, 7 July 2018 (UTC)[reply]
✓ Done is now live. -- User: Perhelion 09:51, 14 July 2018 (UTC)[reply]

Mass process

[edit]

Hello, I've obtained an error in more than one occasion doing the mass process discussed above. The error message is, when keeping all: 

https://commons.wikimedia.org/wiki/Commons:Deletion_requests/Files_found_with_2017031210011731 at line 469: TypeError: undefined is not an object (evaluating 'page.revisions[0]')

or also 

DelReqHandler
TypeError: undefined is not an object (evaluating 'dE[3].unblock')

Maybe it's because there are too many files to process? Thanks --Ruthven (msg) 16:38, 1 October 2018 (UTC)[reply]

PS:I then managed the files one by one. --Ruthven (msg) 07:17, 3 October 2018 (UTC)[reply]
✓ Done Sorry I've not seen your comment before. This should now be fixed. Thanks for report (as I did handle only very few mass requests). -- User: Perhelion 11:40, 3 October 2018 (UTC)[reply]

@Perhelion: Thank you. However, I've again an issue with the Mass process, with a deletion this time. I've left the files there, so you can debug it: Commons:Deletion requests/Sadbomb images by user:Lollipop. Thanks --Ruthven (msg) 18:00, 3 October 2018 (UTC)[reply]

Hey Ruthven, thanks again for feedback. Unfortunately that bunch of filenames is not supported yet, only a list, because it was a requirement for the feature implementation. Because it is to insecure to tag all files links automatically (to delete). Maybe there are more opinions to widen the scope of this mass-handling? PS: Maybe a feature to convert this bunch to a list!? -- User: Perhelion 12:30, 4 October 2018 (UTC)[reply]
@Perhelion: Conversion to a list (even if that wasn't in this tool) would be a useful feature even for non-Admins like me.   — Jeff G. ツ please ping or talk to me 12:52, 4 October 2018 (UTC)[reply]
Fine, good for me. It's true that sometimes files are mentioned in a DR just to make an example. I can convert this into a list just doing a search 'n replace. Thanks again --Ruthven (msg) 13:00, 4 October 2018 (UTC)[reply]

Error 2

[edit]

I am getting this error when using this with Gallery Details: 

Error:
https://commons.wikimedia.org/w/index.php?title=MediaWiki:ImageLinks.js&action=raw&ctype=text/javascript at line 188: Uncaught TypeError: DelReqHandler.get_cookie is not a function

-- 1989 (talk) 09:05, 4 February 2019 (UTC)[reply]

Also, I had trouble closing this DR. I received a URl error. I had to close it manually, -- 1989 (talk) 21:24, 6 February 2019 (UTC)[reply]

@1989: That's one messed up filename.   — Jeff G. ツ please ping or talk to me 03:21, 7 February 2019 (UTC)[reply]

Special:Diff/338367415 should fix it. --Zhuyifei1999 (talk) 20:15, 9 February 2019 (UTC)[reply]

It now takes me to the deletion page, in which it's not supposed to do. I think it’s supposed to do what the qd button does when closing DRs. When pressed, it immediately deletes the page with the rationale to go with it. -- 1989 (talk) 20:55, 9 February 2019 (UTC)[reply]
✓ Done fixed thanks for report. -- User: Perhelion 18:51, 11 August 2019 (UTC)[reply]

Wrong deletion reason

[edit]

I deleted File:2008 Fallout 3 bobble head figurine.jpg (per Commons:Deletion requests/File:2008 Fallout 3 bobble head figurine.jpg) and File:Denby parish.svg (per Commons:Deletion requests/File:Denby parish.svg); in both cases, DelReqHandler generated "per Commons:Deletion requests/File:Флаг ДНР.jpg" as reason for the deletion log entry (see deletion log for these files), which is an unrelated deletion request, not processed by me and currently still open. Gestumblindi (talk) 02:00, 18 March 2019 (UTC)[reply]

That seems a very strange cache issue. Any additional examples or information are welcome. -- User: Perhelion 18:55, 11 August 2019 (UTC)[reply]

Mistaken DR closings

[edit]

@Rillke and Perhelion: There are some DRs that admins are willing to close, however this script actually closes the whole thing. Examples: Commons:Deletion_requests/Files_uploaded_by_Nora670 (P199 closes the discussion where it’s all red, the blue is what they didn’t mean to answer) and Commons:Deletion requests/Files uploaded by Manakpreet Singh (my closure that affected the whole thing). This situation causes DRs to be mistakenly archived leaving them unanswered. Can this be fixed? 1989 (talk) 02:34, 11 August 2019 (UTC)[reply]

✓ Done fixed, thanks for report. -- User: Perhelion 17:19, 11 August 2019 (UTC)[reply]

QD inconsistently working

[edit]

About a quarter of the time, when I load the DR summary page for a specific day, QD functions as normal delete and opens the deletion reasoning window. Anyone else experiencing this? ~riley (talk) 08:38, 9 December 2019 (UTC)[reply]

Mass Process

[edit]

@Rillke and Perhelion: When I use this button, it always skips filenames with symbols or non-English characters. Can this be fixed? 1989 (talk) 17:16, 29 December 2019 (UTC)[reply]

I am also experiencing this issue at times, but I have also noticed it with other filenames too. ~riley (talk) 03:51, 16 February 2020 (UTC)[reply]

Commons:Deletion requests/Files in Category:Japan Expo 2016

[edit]

When there are too many sections to a category batch DR, the script doesn’t load for newer sections. 1989 (talk) 14:21, 15 February 2020 (UTC)[reply]

Ampersand

[edit]

It seems as if the gadget has a problem with file names containing an ampersand like File:Limak_Atlantis_Resort_&_Hotel_(Antalya)-2020-02-16_-12_(cropped).jpg. All the best --Reinhard Kraasch (talk) — Preceding undated comment was added at 17:03, 18 April 2020‎ (UTC)[reply]

kept and talk page created for mass process

[edit]

Hello. I noticed that for mass processing "kept" the gadget doesn't create talk pages for me. Is it my local issue or something happened here? For example, it created message on a talk page for a standalone closure - File talk:Leon trotsky.jpg. But skipped it for mass processed portion - File:PICCjf0174 23.JPG, File:PICCjf0174 24.JPG, etc. rubin16 (talk) 12:25, 14 June 2021 (UTC)[reply]

DelReqHandler adding wrong date to "kept" template if previous DR with same name exists

[edit]

If there are several deletion requests using the same page name - for example, Commons:Deletion requests/Files uploaded by GFHund contains requests from 2013 and from 2021 -, DelReqHandler apparently adds the date of the first instead of the current DR to the {{Kept}} template if files are kept in a later DR; for example, this happened here, where "30 April 2013" was added as the date of nomination when it should be 15 June 2021. Gestumblindi (talk) 14:25, 22 January 2022 (UTC)[reply]

request for the pop up screen

[edit]

When using DelReqHander on deletion requests on Commons, a pop-up screen appears to add the motivation for deletion or keeping the files. This pop-up screen disappears if I surf to another tab in my browser (Chrome). It would be nice if the pop-up would remain available. Then I can look up and include links to policy pages, ping users etc to the motivation. I noted that when I am using the "nominate for deletion" tool, the pop up screen stays available when surfing to another tab. It would be very helpfull if DelReqHandler would show the same behaviour. Hopefully a javascript expert can change the program. Thanks, Ellywa (talk) 13:48, 28 March 2022 (UTC)[reply]

@Ellywa: I think that's just Chrome. I don't have this problem in Firefox. —holly {chat} 22:03, 14 November 2023 (UTC)[reply]
Can be... I still hope it will be solved, after more then a year... I will not istall firefox, because it does not work on all website, my husband has it, including those problems. Thanks anyway for your comments, holly. Ellywa (talk) 22:49, 14 November 2023 (UTC)[reply]

Error messages

[edit]

Using Brave I am getting error messages and the page isn't showing my edits when I refresh. Last error was "DelReqHandler API request returned code 503 errorError code is". Is this a bug? Gbawden (talk) 10:40, 26 April 2022 (UTC)[reply]

HTTP code 503 is defined in the standard as Service Unavailable:
The server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay.
I think in this case the server got confused by the request.
Usually what matters is the first error message, not the last, as the first is about the original problem leading to the error condition. You gave more info in Commons:Help desk#Articles for deletion page not refreshing. Those messages might help somebody recognise the error or debug it.
–LPfi (talk) 06:43, 27 April 2022 (UTC)[reply]

Add support for FOP categories

[edit]

When the deletion request contains one of the Category:FOP-related deletion requests categories (i.e. \[\[Category:[^]]+? FOP cases/pending‎\]\], it should change 'pending' to 'deleted' or 'kept' depending on the option chosen. Platonides (talk) 00:56, 11 September 2022 (UTC)[reply]

Perhelion, I think you are the one maintaining this script? Platonides (talk) 00:59, 11 September 2022 (UTC)[reply]
@Platonides: Sadly, Perhelion has not edited since 18 November 2019.   — Jeff G. ツ please ping or talk to me 12:59, 11 September 2022 (UTC)[reply]
Ouch, you're right Jeff G.. I had seen his user page said he was on vacations and assumed they were for Summer 2022. I hope he's all right. It seems I should nag someone else. It's a bit annoying no longer being able to do this things myself. Platonides (talk) 21:06, 11 September 2022 (UTC)[reply]
@Platonides: You should ask to be an Interface Admin at COM:BN.   — Jeff G. ツ please ping or talk to me 21:09, 11 September 2022 (UTC)[reply]

Automatically add undelete categories

[edit]

Feature request: If the 'Close: Delete' reason contains /Undelete in 2[0-9}{3}/, automatically add <noinclude>[[Category:Undelete in XXXX]]</noinclude> to the Deletion request page (unless the category was already there) Platonides (talk) 01:26, 11 September 2022 (UTC)[reply]

Mass processing of keeps doesn't add talk page notice

[edit]

As the section title says, when you use do a mass processing of KEEPs, the talk page doesn't get {{Kept}} on it. Could we get that featured added? Thanks. —holly {chat} 17:02, 13 November 2023 (UTC)[reply]

Retrieved from "https://commons.wikimedia.org/w/index.php?title=MediaWiki_talk:Gadget-DelReqHandler.js&oldid=821855780"