Page MenuHomePhabricator

Create mw.Api.plugin.upload for uploading from MediaWiki frontend code
Closed, ResolvedPublic

Description

I wasn't able to find a bug for this.

Core has the server part of the upload API (including handling stashing, etc.). However, the clientside part is in UploadWizard.

This should be moved to core, at the correct abstraction level (promises, etc.), then UploadWizard should use that.


From T103397:

This should come with a proof-of-concept gadget that can be used to test the new API.


Version: 1.23.0
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54724
https://bugzilla.wikimedia.org/show_bug.cgi?id=60002

Details

Related Objects

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 2:59 AM
bzimport set Reference to bz62513.
bzimport added a subscriber: Unknown Object (MLST).

MobileFrontend also has an uploading client implementation; are you thinking of some sort of low-level JS API wrapping file uploads that could be used by both, or specifically the high-level UploadWizard UI?

(In reply to Brion Vibber from comment #1)

MobileFrontend also has an uploading client implementation; are you thinking
of some sort of low-level JS API wrapping file uploads that could be used by
both, or specifically the high-level UploadWizard UI?

The actual low-level, client, upload part. It should abstract away the transport, and support chunked uploads if the user has it enabled. It shouldn't include UI, but it should make such UIs possible (callbacks for completion, failure, progress).

Basically some version of ApiUpload* (see also the Transport and Handler ones, like https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FUploadWizard.git/HEAD/resources%2Fmw.FormDataTransport.js from https://git.wikimedia.org/tree/mediawiki%2Fextensions%2FUploadWizard.git/HEAD/resources .

It doesn't need to include all the UW stuff (e.g. Firefogg is probably not neeeded), just enough to get the job done with reasonable browser compatibility.

However, unlike UW, it should be in core and correctly abstracted (e.g. no transport.uploadObject.ui.setStatus in low-level code). UploadWizard, MobileFrontend, PronunciationRecording, and probably other stuff I'm not thinking of should all be able to use it.

I would suggest special:upload could optionally use it. As it stands we have very limitted support for big file upload out of the box, and upwiz does not meet many of the third party use cases.

See 597142b2e5a0c44b4efd369d1d339e3813aeefdf for a starting point; that doesn't appear to support chunked uploads.

Just to be clear, that has been merged.

Upload API would also be useful here:
Change-Id: I25a8a8832fab131e026fb062e7c4968193260b07

I'll start working on this now.

Change 220550 had a related patch set uploaded (by MarkTraceur):
Add frontend API for uploading via iframe

https://gerrit.wikimedia.org/r/220550

Change 220550 merged by jenkins-bot:
Add frontend API for uploading via iframe

https://gerrit.wikimedia.org/r/220550