What are the goals for this module? Should we try to support all the upload methods or just the HTML5/HTML4? Should we integrate with upload module in core, filefield, imagefields, video fields, etc? Should we make this a widget for uploading multiple files to one node or for creating nodes with one file per node, or both?

Comments

all, yes, both would be awesome, meaning all upload methods, integrated with filefield and its derivates (supporting the widgets like imagefield etc.) and supporting both multiple files per node as well as one node per file.

The plan for us looks to be to use html5 where possible, flash for IE7, IE8, and FF 3.5 that don't handle it, and fall abck to html4

Would this be a widget for filefields? A standalone page (as in d6) that creates one node per file? Configurable per site?

Hi greggles. We've been starting to do some work with the D7 version of Plupload at Acquia (CVS HEAD, for anyone reading this, but I strongly recommend against anyone using that version until one of the project maintainers adds a 7.x release of the project, as what's in HEAD is still quite raw). I look forward to more collaboration with you on it. Anyway, here's my input to your questions, at least for D7:

Should we try to support all the upload methods or just the HTML5/HTML4?

I think we at least need to support html5, html4, and flash. Because IE7 and IE8 do not support the HTML5 "multiple" attribute for <input type="file" />, so the flash runtime is the only other major penetration technology that allows for selecting a lot of files quickly. Supporting the flash runtime does make it harder to integrate plupload_handle_uploads() with FAPI (which would allow for better security, including protection from CSRF), though in theory, we should be able to recompile the swf file to support sending a form_build_id / other tokens: perhaps we can do that in a generic (non-Drupal-specific) way that the Plupload library maintainers would be willing to include in the official plupload library. Note, this isn't just for IE7 and IE8, but also Firefox 3.5 and other older browsers, but old versions of non-IE browsers die quickly, so those are less of a concern.

Should we integrate with upload module in core, filefield, imagefields, video fields, etc?

Yeah, for D7, we should make plupload provide a field widget for filefields. It may be good to do this via one more level of indirection: for example, have a separate contrib project provide a filefield widget that uses an element of #type='file', #multiple=TRUE (or if that proves hard to integrate properly with the way hook_element_info() works, then #type='file_multiple'). And then have plupload be one of potentially several modules that can process/render such an element.

Should we make this a widget for uploading multiple files to one node or for creating nodes with one file per node, or both?

IMHO: no, at least not for D7. Multiple files to one node is already handled with filefield being in core. And I think generating a node per file belongs in some other module, since you run into all sorts of permutations, like what type of node are you creating, and what other fields need to be set on it. Also, in D7, you may want to generate entities that aren't nodes (e.g., http://drupal.org/project/media). You really get into use-case specific stuff here, that other modules are best equipped to handle, especially if we provide a #type='file', #multiple=TRUE or a #type='file_multiple' element for those modules to work with.

We'll soon be submitting patches for the D7 work we've done so far, though we haven't even begun yet on any of the above roadmap issues (and don't have immediate plans to do so), so there's still time to discuss those.

Would this be a widget for filefields? A standalone page (as in d6) that creates one node per file? Configurable per site?

So far, we have it as just an element of #type='plupload'. Settings, such as fallback order for runtimes is configurable per element. We don't yet have a settings page for setting site-wide defaults, though that's a logical todo. As far as what to do once the form is submitted, we're using it in the context of the media module, so we have the media module handle the generation of media entities when the form is submitted, though I think what I wrote above in terms of abstracting the element and providing a field widget is the logical next step.

Thanks very much for your thoughts, effulgentsia!

And I think generating a node per file belongs in some other module, since you run into all sorts of permutations, like what type of node are you creating, and what other fields need to be set on it.

Well, that's my exact usecase so I think it makes plenty of sense for the module to do these kinds of things and the settings of the D6 version make it fairly easy to use ;)

So, I guess I prefer if you could name the D7 work you are doing as "plupload_widget.module" or "plupload_media.module" or whatever makes sense (keeping it in the same project seems fine since they are different modalities on the same tool)

When the D6 version gets ported (or perhaps before, even) I'll rename it to "plupload_filepernode" or something like that to avoid confusion.

Does that proposal make sense?

+1 to what @efflugentsia is saying. The namespace "plupload" to me means integration with the project at http://plupload.com which would be making that control work in FAPI and fields. I don't get what would be in plupload_widget.module though...

Are you suggesting that plupload.module would define the element, handle the processing and validation, etc (as it does now in 7) and that field integration would go into a separate plupload_widget.module? I don't see why a user would want one and not the other since the field stuff is non-intrusive really and integrates directly with what core provides. But adding another checkbox to the module page isn't the end of the world either just not sure why.

The work we're doing is totally decoupled from media. Media module just uses $form['upload']['#type'] = 'plupload'; so plupload_media wouldn't be needed.

The D6 version seemed like a prototype to me specific to one use case involving images and "image nodes", if that's incorrect, please correct me. Seems to me something like that would be called plupload_gallery.module, or if it was generic, plupload_nodefactory.module. This module could simply define form with a #type = 'plupload' element, handle the submit function and node_save() in a batch.

In fact, we're going to be releasing media_gallery quite soon which is just that (except with media entities instead of nodes).

Maybe this is too abstract, I don't know if Alex has commit rights (I've been in the hospital and unable to commit our changes) but what we've been building is exactly what I described in IRC, a file upload element with validators using plupload.

Sorry for interfering. Just to note, it would be great if the module would just add to filefield as to stay compatible with fielefield_paths, filefield_sources, imagefield_crop, etc.

+1 to the create new node use case. It makes a lot of sense in D6. For example, I'm using the Views Gallery module in which case each gallery image is an image node that references the respective gallery node. Currently, one can work from within the gallery node view and add images one at a time with the add photo link. From a non-technical user's perspective, this make a lot of sense - add a photo, then see a photo added.

However, one-off photo adding to galleries of any significant size can be a huge time consumer. So ideally, this plupload integration module could work with this views gallery configuration so that instead of an add photo link which opens the create image form, you would have an add photos link which opens the plupload form. The node reference would be automatically added to each new node, so that each image immediately shows up in the proper gallery.

I would like just a form element type to do multi large file upload to the user's own directory (eg. files/upload/%UID): just file upload to the file system, nothing more. And upon completion, call a hook function so I can for example send out an email. swfupload 6.x-1.x-dev used to work like this: it was just an form element. So I was able to create a page with just the swfupload gizmo for user submit their files to our site. But then swfupload became a CCK widget broke my whole setup.

+1 for a filefield widget (perhaps only supporting unlimited-value filefields) for both 6.x and 7.x. Would LOVE to be able to slide this into current sites using filefield.

widget for
+1 uploading multiple files to one node
+1 creating nodes with one file per node

I'd love to see all of the above with this module. Especially uploading multiple images to one node.

+1 for plulpoad widget for multivalue filefield in D6/D7.

sub

subscribe

subscribing

Version:6.x-1.x-dev» 7.x-1.x-dev

The Drupal 7 widget is right here: http://drupal.org/sandbox/vingborg/1138512

Very cool, vingborg. Any plans to backport to D6 CCK?

No, not at the moment. Actually, I thought it was already out there somewhere?

Not that I know of, or a quick Google search pulls up.

Well, I believe there are several options on D6, such as one based on SWFUpload and other libraries. But I'm not ruling out that I'll do it later. No roadmap, though.

Subscribing.

+1

Subscribing
+1 for backport of the D7 widget to D6.

+1 creating nodes with one file per node

We should make a documentation page listing all modules that integrate with plupload -> since it seems that most of the comments on this thread are about actual uploading features, which plupload does not directly provide. Plupload only provides the api for bulk uploading, so these requests would mostly be for integrated modules.

+1 creating nodes with one file per node !!!

Does anyone know what is happening with integrating the Mupload module with Plupload, as mentioned here http://drupal.org/node/1139398#comment-4630812 and here http://drupal.org/node/1177630#comment-4614598 ?

I do not use either of them anymore. I have switched to multiupload_filefield_widget and multiupload_imagefield_widget.
The do not require extra libraries. Do not work on IE, though.

Status:Active» Postponed

I'll mark this issue as postponed, as there was no activity for a long time. If there is any need for re-opening you're more than welcome.