User talk:De728631

Welcome to Meta![edit]

Hello, De728631. Welcome to the Wikimedia Meta-Wiki! This website is for coordinating and discussing all Wikimedia projects. You may find it useful to read our policy page. If you are interested in doing translations, visit Meta:Babylon. You can also leave a note on Meta:Babel or Wikimedia Forum if you need help with something (please read the instructions at the top of the page before posting there). Happy editing!

-- Meta-Wiki Welcome (talk) 16:43, 20 April 2015 (UTC)[reply]

Restore-a-lot[edit]

Is it just me, or does this script not work as intended? I just tried to undelete a few images with it, but after what was presented as a successful run of the script, the files were still deleted. It's a shame that Zhuyifei1999 is now gone. [1]

Zhuyifei1999 is indeed gone. That is a massive loss for Commons in a lot of ways. The main developer/forker of Restore-a-lot however was me, and I, or a ghost of who I once was, is still here. I'm not one to claim credit, I usually even release my own work under CC0. Zhuyifei1999 was responsible for optimizing the script and adding the script as a gadget, so "Restore-a-lot is now available as a gadget, thanks to Zhuyifei1999." means exactly that.

On what page were you when you tried to undelete stuff?
Which files did you try to undelete?
Do you know how to open the javascript console in your browser? (if not, look it up or tell me which browser you are using. generally just search your browser menus for "web developer" and find a "console" button or tab) Please open the javascript console first, try to undelete something and share the output of the console. The most common breaking errors are of the "foo is undefined" kind and generally not that hard to resolve. Alexis Jazz (ping me) 23:56, 29 March 2020 (UTC)[reply]

@Alexis Jazz: Oh, hi there. I knew that you were involved in this script, but actually I didn't know the extent of that. Good job, though. I like the idea of this tool.

Now, I was at commons:Commons:Undeletion requests/Current requests#Filed uploaded by Dekameron Kyivskyi and NOVA OPERA.
I selected all the files in that first list which worked just fine. Clicked "Undelete" and got a message for each file that it had been undeleted.
The links though were still red and no files had been restored.

Anyhow, I just tried it again with a single file and it did work. The Firefox web console output was this:

DNT is on, logging disabled load.php:528:1439
This page uses the non standard property “zoom”. Consider using calc() in the relevant property values, or using “transform” along with “transform-origin: 0 0”. load.php:5:790
This page is using the deprecated ResourceLoader module "jquery.tipsy". load.php:621:246
This page is using the deprecated ResourceLoader module "jquery.ui".
Please use OOUI instead. load.php:627:985
JQMIGRATE: jQuery.fn.delegate() is deprecated load.php:144:746
JQMIGRATE: jQuery.fn.unbind() is deprecated load.php:144:746
JQMIGRATE: jQuery.fn.bind() is deprecated load.php:144:746
JQMIGRATE: jQuery.fn.andSelf() is deprecated and removed, use jQuery.fn.addBack() load.php:144:746
JQMIGRATE: jQuery.isWindow() is deprecated load.php:144:746
JQMIGRATE: jQuery.fn.offset() requires a valid DOM element load.php:144:746

Now it also works with two files. Console:

JQMIGRATE: jQuery.fn.andSelf() is deprecated and removed, use jQuery.fn.addBack() load.php:144:746
JQMIGRATE: jQuery.fn.offset() requires an element connected to a document load.php:144:746
JQMIGRATE: jQuery.isWindow() is deprecated load.php:144:746
JQMIGRATE: jQuery.fn.offset() requires a valid DOM element load.php:144:746

De728631 (talk) 02:06, 30 March 2020 (UTC)[reply]

I just got an idea what might have happened at my first attempt to undelete the whole lot. When I manually undeleted those files afterwards, I noticed that one of the pages had been "reactivated" as the previous uploader had just put some text into the "File" page without an image. So technically that one page was not deleted at the time I was using the script. I suspect that one "live" page screwed up the undeletion algorithm for the other files.

Anyhow, thanks a lot for your support! De728631 (talk) 02:17, 30 March 2020 (UTC)[reply]

If there is a live revision of the file page (whether it contains a file or not), I would indeed expect undeletion to fail for that page. I actually didn't test that. A solution could be to make sure all file pages are deleted before restoring. However, the other files you had selected should still have been undeleted without problems. In Firefox, you can view the "network" tab. When undeleting, you will see some "api.php" entries there. If you select any of those and check what the response was you should find why undeletion failed. If you find "internal_api_error_DBQueryError" there you should check phab:T247207. Restore-a-lot hasn't been thoroughly tested on production Commons, only on the testing environment. Zhuyifei1999 doesn't appear to have tested it on production based on the deletion log and I didn't test it on production Commons because I'm no sysop.

Directly after undeletion (when the background of the selected files has turned grey), the links will still appear to be red. This is normal. Refresh the page so MediaWiki will re-render the page and the links should be blue.

A limitation that I think I forgot to document on the help page: both Restore-a-lot and Cat-a-lot ignore the file link. (href attribute) Using the link would result in complications due to url encoding which are best solved by.. not using the link. Cat-a-lot uses the "title" attribute which works perfectly well for blue links. For red links though, MediaWiki adds " (page does not exist)" to the title attribute, depending on user language. This could be stripped probably, but testing any such solution in every language supported by MediaWiki.. meh. So Restore-a-lot uses the link label which is almost always the page title. However, this does mean that if you have a link like [[:File:Example.jpg|what about this file]], Restore-a-lot would try to undelete what about this file instead of File:Example.jpg. This is never a problem on Special:DeletedContributions or any (U)DR that was generated with a tool/gadget.

If you experience any more problems, let me know. Hopefully it was just a glitch and you won't have any problems anymore. Alexis Jazz (ping me) 03:22, 30 March 2020 (UTC)[reply]

@Alexis Jazz: Thanks for the detailed explanation. However, restoring from a file link did just work in my last test. I selected [[:File:M. Golovko and Y. Izdryck, trap-opera WOZZECK. Photo A. Mantach.jpg]] from the UDR page and you can see the result here. De728631 (talk) 03:34, 30 March 2020 (UTC)[reply]

That link doesn't have a separate label (most file links don't, no | in the link), so indeed that should (and does) work. If you run into problems when undeleting a larger number of files (I don't think you will, but if) the delay may need to be increased. This was a problem on the testing environment, but the testing environment has had performance issues for months that production Commons doesn't suffer from, so I wouldn't expect issues with that on production Commons. Happy restoring.

Alexis Jazz (ping me) 03:44, 30 March 2020 (UTC)[reply]

Something I just thought of: if a (U)DR uses piped links for whatever reason, you can unpipe them. Edit the DR/section and look for the magnifying glass in the top right corner of the edit window to open the "search and replace" window. Replace \[\[:File:([^\]]*)\|([^\]]*)\]\] with [[:File:$1]] ($2), tick "Treat search string as a regular expression", press "Replace all" and save the edit. You can undo/rollback after restoring if desired. I really should have documented this stuff on the help page.. Alexis Jazz (ping me) 19:54, 30 March 2020 (UTC)[reply]

Yes, this is a good idea. I will add that to the help page. De728631 (talk) 19:59, 30 March 2020 (UTC)[reply]

DelReqHandler[edit]

I'm still following the noticeboards.

I saw User:BevinKacon's request at c:Commons:Administrators' noticeboard#Mass category delete. VisualFileChange can't load categories.. DelReqHandler can't delete categories. Are there still bot operators around who have time for this? I don't know. Someone may end up with repetitive strain injury from fulfilling that request.. I think the doctors have more important matters on their mind than attending to that.

User:Alexis Jazz/DelReqHandler.js is a patched version of DelReqHandler. It's not very pretty, it's just tricked into thinking categories are files too. (also I lowered the threshold to enable mass processing, that's unrelated but seems more convenient) It seems to work. Just have an interface admin copy-paste the contents to c:MediaWiki:Gadget-DelReqHandler.js and create a deletion request with BevinKacon's list. — Alexis Jazz (ping me) 11:14, 1 April 2020 (UTC)[reply]

@4nn1l2: oh, I see you already did it. Took you from 10:27 until 10:50. You don't appear to have taken much of a break. Jeez.. 23 minutes? I think that's about how long it took me to modify DelReqHandler. — Alexis Jazz (ping me) 11:20, 1 April 2020 (UTC)[reply]

As I have already told you, my Internet connection is slow and it takes time for me to download and upload pages. Furthermore, there are interuptions. Don't boast about your speed. 4nn1l2 (talk) 11:27, 1 April 2020 (UTC)[reply]

@4nn1l2: I'm not boasting about my speed, nor am I saying you are slow. What I meant is that you appear to have clicked "delete" 84 times, which naturally takes more time than mass processing with a tool like DelReqHandler. And it probably took me a little more than 23 minutes to modify DelReqHandler, but that wasn't the point. Wouldn't you have rather been able to complete the deletion in a minute? — Alexis Jazz (ping me) 11:51, 1 April 2020 (UTC)[reply]

You are wrong to assume that I have just clicked "delete" 84 times. I have opened each category in a separate tab, made sure that was indeed empty, then checked its history page to make sure no vandalism of any kind was involved, then gone to the delete menu, selected "Empty category (C3)" from a drop-down menu, then pasted c:Special:Permalink/408520192#Mass category delete in the second field, and only then clicked "delete". According to my count, that is at least 672 "clicks". 4nn1l2 (talk) 12:06, 1 April 2020 (UTC)[reply]

@4nn1l2: please, let us not misunderstand each other.. I know that even to say clicking delete 84 times is oversimplifying things. It's even more work. I was just thinking about methods that would allow dealing with this more quickly. You could create a new template and do a search and replace on the list to check quickly that the categories are indeed empty:

Category:OTRS volunteers (0 items) — hist
Category:Users (81 items) — hist
Category:Storytelling‎ (4 items) — hist
Category:2007/hi (0 items) — hist

(top right magnifying glass, tick "Treat search string as a regular expression", replace all \[\[:Category:([^\]]*)\]\] with {{catlink|$1}})

Now you know if all are empty and you could delete all in a minute with modified DelReqHandler. You'd still have to do the history check though. (though in case of categories, the category history won't tell you if files have been incorrectly removed from the category which would also be useful to check.. but there's no solution for that)

I'm just trying to help make admin work more efficient. Maybe I shouldn't. — Alexis Jazz (ping me) 12:33, 1 April 2020 (UTC)[reply]

It would appear there is also a bug in DelReqHandler that would prevent you from using mass processing on files that include the ' character. (the qd link would appear to work though) I added a dirty fix for that. — Alexis Jazz (ping me) 12:04, 1 April 2020 (UTC)[reply]