May 22 2022
I do not think FileImporter should prevent files by blocked users to be uploaded. But it could be a good idea to add a warning like "Hey the uploader is blocked. Are you sure you want to move the file?"
Sep 14 2021
Sep 13 2021
Sep 12 2021
Jul 16 2021
Thank you for your reply. I copied the name from Commons and pasted it to the file on ro.wiki. It works when I paste it into a wikilink but not when I paste it into the NowCommons template. So I do not think it is Windows or Edge that makes the error?
Jul 15 2021
Feb 22 2021
When I meet this problem I usually edit the local file page and add the template I want the file to have on Commons and edit the configuration to accept this template.
Commons have a bot that will try to fix dates. There is no guarantee that dates on a specific wiki always uses the same format. So I think it is better to leave the converting to the bot on Commons instead of making the code of FileImporter more complicated. I can of course not forbid the team to implement it but I would support if they decide not to do it (to close this as not done).
Feb 4 2021
I have not testet it but if it is only possible to move a page if there is also a file involved then this might work.
Dec 14 2020
I made the change above and I believe the issue have been solved.
Several of the files in https://ja.wikipedia.org/wiki/Category:FileImporter_error have the same problem.
Nov 23 2020
It is correct that it would be possible for an attacker to upload bad stuff to xx.wiki and then import it to Commons. But FileImporter only works for AutoConfirmed users? So an attacker would have to make many good edits on xx.wiki and Commons before it will work?
In that case I prefer that we add information during import (template or category) instead of blocking for all imports.
I made https://www.mediawiki.org/wiki/Extension:FileImporter/Data/wikitech.wikimedia but it will only work if the file has a formal license template like GFDL, Cc-by-sa-4.0 or MIT for example.
Nov 11 2020
I added some help on https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Move_files_to_Commons/Configuration_file_documentation and hope it is better.
I like FileImporter and I thinks it is a bad idea to block it on some wikis. If good users verify that files are good then those files should be possible to move to Commons.
I can't reproduce this error. Is it still a problem or can it be closed?
I think the best solution is to add text to [[:de:Vorlage:Bild-PD-alt-100]] or [[:de:Vorlage:NoCommons]] telling the user what to do. That way we do not have to make the code more complex and it is a wiki problem that needs to be fixed on wiki.
Yes all files should be possible to move. Once it is moved it is up to local wiki to decide if the file should be deleted or not. If another wiki wants to use the file I see no reason why we want to prevent them to do so.
Oct 17 2020
It seems that structured data breaks old revisions. Not just for random files but for ALL files. So soon we have 60 million files on Commons where the old revisions are broken.
Aug 5 2020
I wanted to copy some text from the old edit and add it to the current page.
NO! If I understand this correct the request is to make a multiedit where the file page and the structured data is changed with one edit!
Aug 2 2020
Filepages are now deleted on Commons and the files are now imported with succes. No problems! So it was just a temporary issue.
Jul 30 2020
I was importing many files very fast so that may have been the cause of the problem. I never had problems like that before so if logs show nothing special its okay to close this and spend the time om something else. The easy solution is to delete the broken pages on Commons and try the import again.
Jul 27 2020
The original request is about filenames in the edit summary. So the link will always be [[:c:File:<name on Commons>]]. The benefit of a clickable wikilink is that it is much faster to navigate to the new location. Personally I have never thought the long edit summary was a problem but I can see the benefit of a wikilink I can click on. (I just realized that this is an old ticket. I thought it was related to one about making edit summary shorter on source wiki)
Jul 24 2020
I just moved 50 files from ja.wiki, 10 from vi.wiki and 10 from lv.wiki and no problems! Thanks for fixing! I love you guys/girls! :-)
I don't see a big need for that. You can just import the file and use HotCat after the import. I would like the import to be as fast and easy as possible.
Jul 23 2020
This should perhaps be in another post so just ignore it if not useful here: I tried to import https://ja.wikipedia.org/wiki/ファイル:コバギボウシ_Hosta_albo-marginata.JPG before FileImporter crashed but the import failed because there is a broken/missing file in filehistory. So I had to upload it "manually". I did not bother to file a bug because there is hopefully not many broken files like this.
Jul 17 2020
Same with this file https://commons.wikimedia.org/wiki/File:Annamie_Paul_in_Toronto_Regent_Park.jpg
It is possible to [https://commons.wikimedia.org/w/index.php?title=File%3AEhime_pref_Hojo_highschool.jpg&type=revision&diff=433591068&oldid=433591067 change stuff] while importing and it still gets tagged as edited by FileImporter ;-)
May 29 2020
Perhaps there still is a problem per https://phabricator.wikimedia.org/T253952 ? An image not showing up.
Aug 11 2015
I think it would be nice if bot(s) did not crash when they find a non-excisting wiki or if there is a link to a wiki that is not yet supported fully.
Jan 25 2015
Jan 11 2015
Jan 9 2015
Jan 8 2015
Yes exactly as described Glaisher. Sorry it was not clear,