API talk:Upload

Flag: Don't overwrite existing file
It would be nice if there was a flag that said: Don't overwrite any already existing file. This could help in preventing errors in bots, especially as Special:Upload mangles the filename a bit, so it's not entirely trivial to make sure a file of a given name does not already exist. --Tbleher 20:20, 14 February 2008 (UTC)
 * Good one. I'll keep this in mind. --Catrope 21:32, 17 February 2008 (UTC)

File Contents?
Could you be more specific on the file contents? Is it just a bunch of bytes, UUEncoded, HEX, or what?


 * Assuming you mean direct upload, the file content should be sent as part of the request in multipart/form-data format, so essentially yes, just a bunch of bytes. Gurch 05:03, 30 October 2009 (UTC)

I'm trying to do this with curl, but am having no luck with any kind of file content inclusion. Can you give an example? Here are some things I'm trying: curl -b cookies.txt -d "action=upload&filename=exported.xml&file=$(cat exported.xml)&format=xml&token=$UPLOADTOKEN" http://lookipedia.net/w/api.php

curl -b cookies.txt -d "action=upload&filename=exported.xml&file= text &format=xml&token=$UPLOADTOKEN" http://lookipedia.net/w/api.php

curl -b cookies.txt -d "action=upload&filename=exported.xml&file=TEST&format=xml&token=$UPLOADTOKEN" http://lookipedia.net/w/api.php

curl -b cookies.txt -d "action=upload&filename=exported.xml&file=@exported.xml&format=xml&token=$UPLOADTOKEN" http://lookipedia.net/w/api.php In all cases I get this error:  Pjrich 17:48, 10 October 2011 (UTC)

Upload by URL
I'm not having much more luck than you with uploading by URL. I did try retrieving httpstatus using the session key, and got the following result:

{u'upload': {u'content_length': u'5706', u'loaded': 5706, u'upload_session_key': u'12345'}}

But the file wasn't actually uploaded, and I don't see any way of determining what went wrong. --R&#39;n&#39;B 18:45, 29 October 2009 (UTC)


 * It was broken before, was fixed in r58337 -- Gurch 05:11, 30 October 2009 (UTC)

Unrecognized value for parameter action: upload
I'm trying to upload a file via wget. Login and fetching token is OK, but on upload...

wget --load-cookies cookies.txt -O upload.xml \ --post-data "action=upload&filename=atlasmw-export.xml&file=[content goes here]&token=$EDITTOKEN" \ $API

I get this:

&lt;error code=&quot;unknown_action&quot; info=&quot;Unrecognized value for parameter &amp;#039;action&amp;#039;: upload&quot; xml:space=&quot;preserve&quot;&gt;

Documentation says:

api.php ? action=upload & filename=Test.txt & file=file_contents_here & token=+\

What's wrong? Using MediaWiki 1.15.1. Jpatokal 03:32, 20 November 2009 (UTC)
 * It's a 1.16 feature. Max Semenik 05:45, 20 November 2009 (UTC)

overwrite: text parameter ignored
is there a good reason the text parameter is ignored when overwriting an existing file? imho it would make sense to overwrite the description, too. -- ∂ 23:55, 23 April 2010 (UTC)

Mediawiki Push Extension
Is anyone here familiar with the MW Push extension?

Trying to get it to work and not having much success.

The extension author has been less than helpful:

"In any case, I don't know what your issue is, so can't really help you any further."

I keep getting the same error:

Could not obtain an edit token on the target wiki

After reading and reading I suspect it might have something to do with the API Upload.

Any thoughts?

I had the same problem, it was something to do with my target media wiki installation, I re-installed a clean version (version 1.19.2) and it worked for me. This is a little vague sorry but perhaps that might help you if it isn't too much to do that, certainly something to try if you don't have any better options.

--Cgeroux (talk) 16:54, 15 October 2012 (UTC)

Reverting to an earlier revision?
I'm not sure if this is the right place, but: Does anyone know if it's possible to revert to an earlier revision? A workaround using archived image URLs comes to mind, but the particular wiki has URL uploads disabled. --84.186.216.128 00:07, 24 February 2012 (UTC)

Async uploads
After digging through the code to find that wgAllowAsyncCopyUploads is was the correct parameter to allow an async upload, I now get the following error back:
 * Asynchronous copy uploads are no longer possible as of r81612

Is there any plan to re-introduce this option? --Brian McNeil (talk) 12:13, 18 September 2012 (UTC)

REAL WORLD EXAMPLES ???
Is there any real world example out there (as for the login API) how to use the upload API correctly? This could help many peoples. --Steviex2 (talk) 22:08, 7 February 2013 (UTC)


 * Real-world examples include:
 * Extension:UploadWizard (JavaScript using XHR)
 * Apps/Commons (Java and Objective-C implementations)
 * Wiki Loves Monuments app from last year (JavaScript using PhoneGap FileTransfer API)
 * --brion (talk) 01:02, 8 February 2013 (UTC)

...And Mobile Frontend. They are all big projects which I checked. What I really mean is a simple, basic code snipped like for the Login-API. The extensions are way too big to simply adapt it for own projects. Uploading into MediaWiki is a core feature which should be documented as well as the Login-API for developers. Since more and more people are coding in PHP and JQuery, I would be happy to see simple examples to use the Upload-API with this languages.

This should be a small step for a professional MW-dev but a big step for the community :-). PS: I can't understand why the internet is full of missunderstandings and time consuming trial and errors about this topic, while the original developers should know this few lines of code in every provided language very well. I also would appreciate informations wether we are talking about a file stream or a representation on disk. For example could we use  and or  . What would be a complete CURL-Realisation? Is the same possible with JQuery? What about the "same origin policy" in this context? --Steviex2 (talk) 01:44, 8 February 2013 (UTC)


 * I'll see about whipping up some PHP and JS examples... In the meantime, the thing to know about cross-origin policy is that you probably won't be able to make a successful authenticated POST request to the API from JavaScript on another domain unless it's on the short whitelist of Wikimedia sites. That is, you could upload a file to Commons from a gadget on Wikipedia, but not from an arbitrary web site. but if you route through your server, your PHP code can certainly do it. -- brion (talk) 16:30, 8 February 2013 (UTC)

Aha this is a very important point for people having more then one Wiki-installs and want to exchange files accross different domains. To choose the wrong tech here, could easily result in hours- may be days of useless efforts :-).


 * Note that for your own wiki installs, you can customize $wgCrossSiteAJAXdomains to whitelist more sites. --brion (talk) 21:08, 8 February 2013 (UTC)

Okay this makes sense now. Yesterday I was wondering when I made a little external login page for my Wikis- thank you. For the Upload-API I would prefer the CURL-way like many others too. By the way in general what about this XML-chunks in the API-Documentation? How would they be used? Is it only an abstraction to reflect the different programming languages, or can we use them in PHP too?

...after many many hours of trial and errors...still can't get it working with PHP-CURL while successfully login get edit token etc..
 * Example results we can get with good PHP-knowledge but less propper documentation level :-)
 * One of the parameters filekey, file, url, statuskey is required
 * post request failed The requested URL returned error: 41422
 * request failed: URI too long (longer than 8190)
 * The parameters url, filekey, statuskey can not be used together
 * Invalid Content-Length
 * No upload module set

PS: Some remarkable behaviors:
 * The error "One of the parameters filekey, file, url, statuskey is required" is fired even we specify a file-parameter in the url may be because it is double checked against a user agent[...].
 * If we put file contents into the url this mostly exceeds the allowed length of an url.

--Steviex2 (talk) 22:37, 8 February 2013 (UTC)