Last modified: 2010-11-14 23:11:13 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T20563, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 18563 - Merge new-upload branch (tracking)
Merge new-upload branch (tracking)
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
Site requests (Other open bugs)
unspecified
All All
: Normal trivial with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
: tracking
Depends on: 18112 18200 18201 18243 18264
Blocks: tracking 14925
  Show dependency treegraph
 
Reported: 2009-04-23 12:12 UTC by Splarka
Modified: 2010-11-14 23:11 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
new-upload_and_script-server (789.00 KB, patch)
2009-07-09 23:57 UTC, Michael Dale
Details

Description Splarka 2009-04-23 12:12:21 UTC
I've set the following bugs blocker for this action (please remove if not blocking... dur):

  bug 18112  Retain URL as metadata on upload-by-url
This seems a critical bit of metadata for permanent recordkeeping.

  bug 18200  Upload-by-URL has a different file size limit from HTTP POST uploads, needs to be shown in UI
This seems somewhat important to friendly UI.

  bug 18201  Upload-by-URL should enforce $wgMaxUploadSize early when Content-Length header provided
Important?

  bug 18243  Upload via URL: More meaningful error messages when HTTP error encountered
Seems common to get HTTP errors... more datas!

  bug 18264  Cannot use "upload by URL" feature with javascript disabled
Actual feature loss, fixme please.


These are related but probably not blockers:
bug 18132  Support multiple file uploads with upload-by-URL
bug 18202  Upload-by-URL should run in background, report feedback interactively to user

Also, this one is related to bug 18200 and probably can be fixed at the same time:
bug 18411  The upload form only checks upload_max_filesize, not post_max_size
Comment 1 Michael Dale 2009-04-24 20:04:46 UTC
Changed the summary to track all the related new-upload branch updates that are part of the above mentioned fixes. More comments to follow shortly...

Other upload-api related bugs in new-upload branch
bug 16927 enables firefogg support (adding chunks to the api) this hits on bug 17255 although the protocol is firefogg specific and simpler than described. (although it does not block the possibility of using the simple firefogg protocol with other clients) 

There does not seem to be a general "upload api" bug. But the original idea of the new-upload branch was to support api. The api is currently documented as follows:  (will be a few updates once we support status checks on http uploads) 

* action=upload *
  Upload an File
Parameters:
  filename       - Target filename
  file           - File contents
  chunk          - 
  url            - Url to upload from
  comment        - Upload comment or initial page text
                   Default: 
  watch          - Watch the page
  ignorewarnings - Ignore any warnings
  enablechunks   - Boolean If we are in chunk mode; accepts many small file POSTs
  done           - When used with "chunks", Is sent to notify the api The last chunk is being uploaded.
  sessionkey     - Session key in case there were any warnings.
  chunksessionkey - Used to sync uploading of chunks


Comment 2 Roan Kattouw 2009-04-24 20:08:01 UTC
(In reply to comment #1)
>   chunk          - 
documentme?
Comment 3 Michael Dale 2009-04-25 00:59:24 UTC
right...done in r49850 ( chunk is the name of the chunk file present in the $_FILES array. )
Comment 4 Michael Dale 2009-04-28 22:43:29 UTC
update on all the bugs: 
bug 18112 ... tagged as not high priority (see comment on bug page) 
bug 18200 ... (fixed)
bug 18201 ... (fixed) also does pre-check via HEAD request against $wgMaxUploadSize byte size
bug 18243 .... The new-upload branch does pass along a lot more http errors. But could be tested more and perhaps needs localized message wrapping. 
bug 18411  fixed as part of 18201

bug 18264 ... (left open for now)
bug 18202  Upload-by-URL should run in background, report feedback interactively to user ... (development is under way for this one on the new-upload branch). Required a few fixes here and there for calling php locally nothing had to do that yet somehow...

Comment 5 Michael Dale 2009-04-29 15:24:01 UTC
bug 18264 resolved
Comment 6 Michael Dale 2009-06-12 01:26:38 UTC
ran a merge to head in r51762
things are working better on all around ... I would attach a "patch" but it will be pretty monstrous plus there are a lot of images involved. I think I will do a ~test~ commit to trunk soon...
Comment 7 Michael Dale 2009-07-09 23:57:56 UTC
Created attachment 6316 [details]
new-upload_and_script-server 

here is a massive patch that includes the script-loader and the new-upload branch along with the js2 libraries for everything from playback to sequence editing.

The js2 system is "off" by default. The script-loader is also "off" by default. The upload-api is enabled by normal upload configuration flags. 

I can try and create a upload-api only commit if thats helpful.
Comment 8 Michael Dale 2009-07-10 23:14:58 UTC
oky the patch is already out of date a few fixes in r53084 and r53083.  
Comment 9 Andrew Garrett 2009-07-29 16:39:03 UTC
Adding 'tracking' keyword.
Comment 10 Chad H. 2010-11-14 23:11:13 UTC
Most of the new upload code has been merged in by now (or exists as extensions).

Resolving.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links