1 node per file

subscribe

please

Well this is pretty easy. Iam not sure how to do this with swfupload-module yet, as iam not aware how to use it as form element.

skilip told me that you can use the swfupload api to hook into the upload process. That measn, all you need to do is writing a submodule, which is created a node for each file uploaded. This is very easy to implement.

Subscribing. I'm a co-maintainer of Node Gallery, and we're working on a new version that works with ImageField. In Node Gallery, every image is a node itself, so this feature is of great interest to me. Currently, I've integrated with image_fupload, but frankly that module scares me. It's messy, buggy, and I'm not too sure of it's future. This module is so much cleaner.

@4: Well image_fupload is near to unuseable and the UI is really ... well "scary".

It very easy to integrate with SWFupload, just hook into the api. Iam sure skilip and i will help you integrating it.

Thanks for the reply. I see you and skilip are in #drupal - once I clear some tasks from my plate I'll likely ping you and see what we can come up with.

I agree with #7. I don't use Node Gallery and I have my own setup for galleries (which I am sure is similar to Node gallery). So I would like to be able to add a link somewhere on my Gallery node, which will take me to the SWFUpload screen. After selecting a bunch of images, those should be uploaded and a node created for each of them. A return path (tokens?) should also be provided so users can get back to the main gallery after uploading is finished.

What image_fupload is doing right is setting up of all this: it extends the configuration of the ImageField within a node type and lets you select either "multiple images per node" (what SWFUpload does currently) or "Single image per node". As some mentioned before image_fupload is not very usable at this point though.

If there is no chance of this being implemented any time soon, I would appreciate some guidance or code snippets as my Drupal skills extend mostly to configuring modules and writing small updates for my templates.

I really like the idea of this and see a future submodule for this. It's definitely not going to be part of swfupload module so I'm postponing this issue.

I think that you`re perfectly right with this skilip. This is easily possible using a submodule + hook_swfupload. Maybe we need to add some other hooks / events, but basically it will work out.

I have time to work on this and am actively pursuing it.

Code coming soon!

Thanks!

I actually created a module for this already that we are using for one project that I am working on. Although it is based on the old swfupload module (not hte cck one). I don't have access to Drupal to upload the module so I'll try and go through that process to get it uploaded online.

Alright I cleaned up my module and have provided it as a tar ball for people's use. Greggles hopefully you can use some / all of the code. I apologise in advance for not releasing this as a patch.

I should also note that this is based on the previous version of SWFUpload (non-CCK version) as we have yet to upgrade our modules due to a limited budget. I've outlined some of the details for this project (requirements) below

Specifics:
* Extracts each file that is currently being uploaded and places them into the appropriate CCK field (if they are available) - oooh ahh
* Each file is placed into a content type (in our case a book page) - configurable in admin section of SWFUpload
* The main node that is used to upload the file is actually considered the parent (with no files) and all uploaded files are associated to book child - this could easily be changed or added as a configuration option)

Greggles: Feel free to contact me through this ticket or email to get more information or help on how everything works. I hope that a bunch of the code helps get things working :)

I was just wandering when you work on this feature, how do you plan to treat the additional fields in the newly created nodes. There is a good example in this tutorial:
http://www.lullabot.com/articles/photo-galleries-views-attach
... each Image node type has a Nodereference to the parent Gallery and a Nodereference URL widget. Thus when a user clicks on the "Add Image" link, that parent Gallery is automatically populated in the new Image.
I did test that by adding Image FUpload that supports multiple nodes. As I wrote before, Image FUpload is not very usable but this particaular feature works very well - if you add multiple Image nodes to a Gallery, they all get the correct Nodereference pre-populated from the URL.

So I am just wandering will this be the case with SWF Upload?

That's a real problem, though here is my plan on how it can be achieved in the short run and long run:

I think step 1 is to just make it upload the image to the imagefield. This allows and admin to create a VBO view to add in taxonomy or other fields.

Then step 2 is to present a form or use arguments from the URL to prefill data. However I think that will be more complex and should be done in subsequent feature requests.

Yes, my request was exactly your step 2. Step 1 might make sense for sites that are managed by a single editor/webmaster but in my case I want to build user-managed galleries.

Well to be honest imagefupload is :
- very bad written
- has a very bad usability
- is a pain to integrate

imagefupload was the reason why i wrote http://github.com/EugenMayer/drupalwiki_multiupload and later merged with this great project.

My goal with my comment was to say that we should postpone that discussion. It's a question for *after* we get this working.

On this issue, I can't get the code from #14 to work after reviewing it for a while. It really requires a parent node and a child node which is interesting, but not my exact scenario. I'm not sure whether to try to work with it or start over.

My goal is to create a single page at a url like /bulk-upload and on that page it presents swfupload and then all of the uploaded files are placed into new nodes.

greggles: could we go for a generalized approach? What iam about is, i need the exact same thing for wysiwyg_imageupload, because people ask for it.

i want to have it optionally, and that will result in a very similar thing here.
1. Introduce a relation table ( nid, id, type ) : id -> child, type: image, file, chicken, egg
2. add some administration items to the CCK field / administration field ( this will be seperated for both integrations i guees). you will chose which node type you want to use. This node will need eg. a
filefield / imagefield
- Save the decision in a variable "noderealtion_suffix=nodetype" while suffix is something field related. E.g. the cck field, or whatever the form has in its "parent_entity" value in the form later
3. Create a simple API method with a signature of create_noderalation(id, type, parententity)
- .Create a node, attache the uploaded file, save it

---

Thats it. Iam not sure what is hard here at all, for me its pretty plain, but i see we can share 90% of implementations here:
1. 100% the same
2. 100% the same : Maybe create a general form on a general callback. Let both modules (swfupload / wysiwyg_imageupload ) include that form using a method.
3. 100% the same : Both modules will implement there own hook in the submodule for this dep, catching upload even and calling this API
4. 100% the same :

This module can be then use more often, to make node raltions optional. This is useful to speed up implementations like wysiwyg_imageupload if you dont need that relation (skip the whole nodeapi)

Well, I'm no longer working on this.

I found http://drupal.org/project/plupload and was able to get it working much faster. I also appreciate the fact that it works with HTML5 (and to some extent HTML4) in addition to Flash, silverlight, gears, and BrowserPlus (only HTML5 is supported by the current module).

Flying Drupalist, that depends on user contributions. I don't feel that's an important feature so I don't plan to work on it. My preference is that each file gets its own node so I built it that way.

The idea of plupload is pretty good, the fallback part is lovely.

What i would like is to actually use a similar implementation like i did with drupal_multipupload, where the swfupload / anyotherelement is only a formelement, taking configuration. anything else is a submodule implementing a specific workflow like imagfield, filefield, 1node1file etc. This way actually it does not matter, what widget actually uploads those files - the backend can be shared.

We have a pretty good interface here - "files". In more comman cases, its files + meta. And that can be the perfect place for backend / frontend. So seeing the uplaod-widget es a frontend has several advantages:
- easy fallback to anything you like ( also non-javavascript html )
- easy replacement of the upload element ( swfuplaod, plupload, webdav whatever )
- easy extendable backends - not carring about the frontend. This really saves a lot of time

Looking at plupload, its again a one way solution. No formelement, rather no api. Again mixing up the frontend and backend. So eventhough i like the widget more, i will stick with this project. Maybe we have some more time with Philip and can build that interface so we later can replace frontends e.g. for accessability usecases, html5 or whatever

Hi EugenMayer, as I said on the project page, the current version of the module is overly simplistic and made just to fit exactly my needs on this particular project. I wrote it in 1.5 hours! So, it's definitely not a complete solution.

One thing that impresses me about SWFUpload is the hooks for altering presentation and file destinations. On the other hand, I found that trying to extend SWFUpload was very hard because it made assumptions about how files were handled that made it difficult for me to do something differently.

For a generic uploader I think we need

• Core module that has helper functions for adding the widget to a page (css, js, widget html) with plenty of hooks to override the html but don't attempt to handle the actual display nor uploads
• Submodules that provide specific integration points for the frontend (is it on a standalone page? part of a form?) and for the backend (is data stored in core upload module, imagefields, etc.)

So far I think all of these modules are not yet ideal on this separation.

(and my apologies for this off-thread comment, even if it is a reply)

greggles its always easy to write such an widget to just cope with the needs "you just have on your own". In that manner, your interface you build for you will look easy and undestandable to you, not complicated.

With a more spreaded usecase it will get harder though.

Anyhow all i want to say is that we might rather stick heads together and write a proper base-implementation. Drupal API gives us a lot already, also using the Form-API will give us a lot. All we need are wrapper-callbacks for submits / ajax which export APIs / hooks for others to implement anything they like on the "just uploaded" files ( rather a file, one by one ). Those wrappers are our interface which need to be called by the "uplaod frontend" which needs :

- "i have a file here, take it and do whatever you want"

And then we have a second element for the filelist. We dont need that for every widget, this is so much doubled work.. This fronend handles
- "give me a list of the current files"
- "here i have a update on a files meta array()"
- "delete that file please"

So we seperate in 3 areas:
1. Backend for fileuploads (with hooks and API ) and File-List/ Meta management. Providing callbacks
2. Fronend interface for anykind of widget using Backend 1 for fileupload management
2. Frontend interface for anykind of widget using Backend 1 for file-list management

Actually the way my code works is the following:

* If creating a node of specific content type then all nodes that are uploaded are placed as children of that node (like a book concept)
* If creating a node of the child content type (from above) all nodes are placed into separate nodes.

Generally, the code in there should work properly in propagating the data that is being uploaded into separate nodes.

Issues to be careful of that I discovered during implementation:

* When you create a node pragmatically you can actually "ignore" the required fields of that content type (which is kinda bad in my opinion). Since users who later edit that node will end up having to properly add data to those sections. Perhaps there is a way to actually display the specific content type you want to bulk upload into to set all the "default" values for that - as I have done in my submodule.

Hey ShaneOnABike, would we have to downgrade to use your module?

Your module also depends on:

Scribdfield
jQuery plugins
Upload
?

That's a lot of dependencies.

subscribe

You could remove the scribd and any other dependencies you don't want. Our customer had requested that we turn File CCK's into a live preview so that's the reason for that dependency.

I´m looking for a solution that use this kind of behavior:

- Multiple images Upload
- One node created per image
- Once all images are uploaded, a form appear with all the metadata fields (other cck fields of the content type like content taxonomy) per image for us to input respecting 'requiered' and other options of the cck fields.
- When edit one image only the relative portion of the form corresponding to the image (the meta fields) appear for us to update.

Plz share your thoughts about the posibility of this.

Hey y'all!

I've implemented 1 node per file on swfupload that should work for most situations I've seen in this thread. It's a simple but effective module -- plug in the variable names as noted in the comments, and follow the other instructions in the comments, and you're good to go. The goal was to get this working with the current 2.x (CCK line) of swfupload (unlike Shane's which only works with the older non-CCK version). I started with Shane's module (hence the same name) but completely rewrote it. Thanks Shane for the jumpstart.

Instead of via books, child image nodes are referenced to their parent nodes via a nodereference field. So that needs to be set up first, as commented. The only dependency is nodereference (swfupload itself is not required, as I suspect this module might find use in other cases).

The way it works is when you create a parent node and upload multiple images, individual image nodes (child nodes) are created for each image, referencing the same image file as in the parent. The parent still maintains its relationship to the images via the imagefield but you can also view the image nodes separately -- the image node type must contain at least a node reference to parent node and an image field. They are not intended to be edited by the gui, only viewed.

Let me know how it works for you.

In my case, I needed this to use a nodereference of a view. I created a view that displays all the image nodes with a filter based on the parent node (the aforementioned nodereference field). Then I have a third node type using that view as a nodereference field. It also has its own nodereference to the parent node. So when a node of the third type is added, users are presented with checkboxes to select images filtered down to those attached to the parent node.

Cheers,
Shiraz

Sorry -- here that module is again with the info file included.

Sorry -- one more time with the dependency properly defined.

Also, there's a minor mistake in my instructions. BTW, I couldn't use variable names for the field names is because i couldn't figure out how to use them in the $object->$array[0][xxx] context. If someone could figure that out, and also if someone can figure out how to declare the variables globally, then we could stick all the variables at the top nice and simple. If we get serious we can use the variables table. Just not gonna do more on this until people start commenting.

Did i get it right, that this module does not utilize swupload at all?

Shiraz Dindar, do I get it right that using your patch an image is uploaded and stored only once but is referenced twice: once by the multi-value ImageField in the main node and once in each individual image node?

If that's that case, what happens to referential integrity if an image node is deleted?

sub

It's been a while sice anyone commented oh this thread. I am still looking for a usable replacement fo the Image FUpload functionality.

I need to create one node to each image, and reference to a gallery node...

subscribing...

Yep you would unfortunately :/

@ShaneOnABike: Impossible?

I am closing this issue, since Drupal 4.x, 5.x, and 6.x aren't supported anymore.