brianna.laugher wrote:

We even now have people building bots to perform this service:
http://tools.wikimedia.de/~bryan/flickr/upload

Bots shouldn't do this kind of functionality - MediaWiki should. Please let us know if there is a chance this will ever be enabled.

A number of improvements to Commons will need to be created and/or fixed and/or enabled sooner or later. This may or may not be one of them (it has not been reviewed at this time afaik).

brianna.laugher wrote:

(In reply to comment #2)
This may or may not be one of them (it has not been

reviewed at this time afaik).

If it's worth anything, it's been enabled at Wikia. http://lists.wikia.com/pipermail/wikia-l/attachments/20070427/f2b68e8d/attachment.html

I just looked through it, and it definitely needs some improvements, e.g. it uses $_GET and $_POST instead of $wgRequest. Also, in my tests, it didn't generate any image captions (so the image page didn't link to the original page on Flickr), but I haven't really looked into it (the code to do it is there). I also think that appending random digits is not ideal - the code should check if an image of the given name already exists and refuse to overwrite existing images. Another idea: The code could check a list of regexes to disallow names created by typical cameras (e.g. DSCN0298.jpg). Then the user could be forced to choose a more sensible name.

Just so you know: I'm currently auditing the code and found some more issues (security and others). Hopefully in the next week or so I will be able to finish it and put an updated version into SVN.

r31017 fixes all security issues that I found (and also cleans up the code a lot). So from that POV it should be safe to enable on MediaWiki servers. (But of course Brion or Tim will have to review the code too before that happens).
But there are some other aspects to consider:

• The current code doesn't do any caching (but the phpFlickr code has some provisions for it, so it could be added with relatively little pain). I don't know if this is a problem for wikimedia, but the code does one POST request to Flickr for each thumbnail it shows, so it could be problematic.
• Users could use this extension to make mediawiki servers download much data from Flickr without much traffic from their side. It wouldn't even get noticed in the logs if they chose a name that conflicted with an already existing image. Is a rate limit needed there?
• I also think that the interface could be improved, e.g. the name check could be done via JavaScript like the main upload form does. But this is not critical.

jeluf wrote:

Before the extension can be installed, it must be reviewed.

Note that this function will be handled by the add-media wizard that Michael Dale is working on, which handles additional sources as well.

Bryan.TongMinh wrote:

LATER. Not compatible with current MediaWiki 1.16.

I am closing this as a WONTFIX as the extension is no longer maintained.