Closed (duplicate)
Project:
Image FUpload
Version:
6.x-3.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
31 Oct 2008 at 00:35 UTC
Updated:
17 Feb 2009 at 21:04 UTC
One of the best features of the imagefield module is the ability to have multiple images on one node. It would be even nicer if one can add images en masse with FUpload. Thanks for listening. :D
Comments
Comment #1
grandcat commentedThis was already planned but it is not as easy to realize as it sounds. Especially, if you want add or remove images from (to) a already existing node.
I would really like to hear some possible methods.
Comment #2
Flying Drupalist commentedHi, I'm really happy to hear that this is planned, and I don't quite understand why it's more difficult than separate nodes, but I would be happy using imagefield uploads for edits, and using FUpload exclusively for first time uploads, no problem. :)
Comment #3
scroogie commentedI can imagine that this is problematic, especially considering the difference in image handling between imagefield and image (file based vs. node based). May I ask what route you chose to go? Maybe it could be handled by some kind of referencing or image_attach, to keep the node-based image handling in the background?
Comment #4
grandcat commentedTo bring you up-to-date, my plans which are partially worked out:
At the moment, I concencrate on working out the UI of ImageField with FUpload support. By using CCK ImageField's administration form, you can choose whether 1 or 2-unlimited (or restricted value) images should be possible to upload via Image FUpload.
If you chose to be able to upload more than 1 images and edit any image node, the normal ImageField list (of images) will be shown, so it's possible to remove some images. Additionally, below this field, Image FUpload will be integrated to be able to upload some more images to that "node gallery" (--> file based). All right? ^^
On the other side, the image module only supports the node based solution and this won't change next time.
@ scroogie:
The imagefield thing (node based) can easily be done by using taxonomy or node_refernce (for grouping options), this should not be the problem. Or was it another question?
Comment #5
scroogie commentedWell, I meant something different. My idea was instead of using the imagefield mechanism (files table) to provide a CCK widget which creates the image node on the fly on submit (if this is even possible?). This would maintain the same images for both the image.module and imagefield.module, when used at the same time. I guess with your version you have got two completely seperate set of pictures, ones for imagefield.module, and the others for image.module, right?
Comment #6
Flying Drupalist commented@grandcat, sounds great. That'll leverage image's capabilities as intended and imagefield's capabilities as intended.
@scroogie, that sounds like a really interesting feature. But if implemented should definitely be optional, some of us don't want duplicate images.
Comment #7
scroogie commentedI think I might be explaining it badly, because apparently you misunderstood as well Miraploy. What do you mean with duplicate images?
It is the problem I see with grandcat's solution, that image and imagefield upload images are not interoperable.
Comment #8
grandcat commentedYes, that's right, but I don't think that's a good idea to sync image and imagefield modules because in most of the cases, only once is activated (or installed). If both, this would exceed the task of this project, another module which does it, would be better.
P.S.: IN D7, this should become possible more easily because of some image related hooks =)
Comment #9
scroogie commentedAnother solution would be to provide an own CCK field for imagebrowser, which doesn't use imagefield at all. Why would you need imagefield anyway? It would certainly be nice to be able to have a CCK field for images, even when image.module is used, especially being able to add already uploaded images to nodes.
Comment #10
basicmagic.net commentedsubscribe
Comment #11
grandcat commentedImageField is very popular and makes it more easy to interact with CCK core. It would also exceed the project to provide a full CCK implementation. Arguments against are welcome ;)
Comment #12
Flying Drupalist commentedJust do whatever is easier, as long as it works. :)
Comment #13
momper commentedsubscribe
Comment #14
grandcat commentedWe only need one issue for CCK implementation:
http://drupal.org/node/322473