[drupal-devel] Make image module an extension of upload module
I love the new image modue. Is there any reason why it is adventageous to have images be nodes, and if so why don't we extend this to all of the files that we upload? A proposal: from my casual and not exhaustive reading of the image module code, it seems like the coupling to the node table is only very superficial. It would therefore be possible to extend the image module to respond to any images which come in as attachments via the upload module and process them in the same way that the image files attached to image nodes are processed. The two major changes which would need to be done to enable this are: 1) accept the file_api patch[1] which is in the queue and has a relatively strong amount of support 2) rewrite the image module queries which select on node.type='image' to files.filemime in (image/gif, image/png, image/jpeg). The advantages of doing this would be a more logical workflow, the end of images coming into the system but not being recognized as such, one fewer content types that users need to deal with and better support of mass uploading. The last point merits a little more attention as that is actually my impetus for bringing this up. I'm working on ways to upload multiple files from one screen, either via multiple upload forms or by uploading a .zip file which gets unpacked. While this should be relatively straightforward for attachments, for images it is hairier as the concept of an image node only accomodates 1 image. Welcoming thoughts and comments! Any advantages or disadvantages that I haven't thought of? Any technical problems that I haven't forseen? cheers, Robert [1] http://drupal.org/node/18934
On 4/18/05, Robert Douglass <rob@robshouse.net> wrote:
I love the new image modue. Is there any reason why it is adventageous to have images be nodes, and if so why don't we extend this to all of the files that we upload?
I'm not against what you are proposing, but I don't think images should NOT be nodes. - ratings - descriptions - comments - manipulated with taxonomy / tagging - etc. etc. etc. That's just off the top of my head. Being a node brings a lot of advantages. -- Boris Mann http://www.bmannconsulting.com
On 18-Apr-05, at 10:29 AM, Robert Douglass wrote:
I love the new image modue. Is there any reason why it is adventageous to have images be nodes, and if so why don't we extend this to all of the files that we upload?
yes - in fact the maintaining of "images as nodes" (but separating it from the image manipulation stuff) was very deliberate... as Boris has already mentioned - there is lots of stuff you get "for free" by having images as nodes - and it is really intended for "image as primary content"- type scenarios - i.e. photo / screenshot galleries, "photo blog", etc...
A proposal: from my casual and not exhaustive reading of the image module code, it seems like the coupling to the node table is only very superficial. It would therefore be possible to extend the image module to respond to any images which come in as attachments via the upload module and process them in the same way that the image files attached to image nodes are processed. The two major changes which would need to be done to enable this are:
1) accept the file_api patch[1] which is in the queue and has a relatively strong amount of support
i'm amongst the supporters of this.
2) rewrite the image module queries which select on node.type='image' to files.filemime in (image/gif, image/png, image/jpeg).
well - here's where stuff gets tricky - image.module currently does a bunch of stuff that may or may not make sense in a global context : i.e. generating a bunch of "derivative" sizes - i might not want this if i'm just attaching, say, a screenshot of a bug on a project issue... etc etc.
The advantages of doing this would be a more logical workflow, the end of images coming into the system but not being recognized as such, one fewer content types that users need to deal with and better support of mass uploading.
The last point merits a little more attention as that is actually my impetus for bringing this up. I'm working on ways to upload multiple files from one screen, either via multiple upload forms or by uploading a .zip file which gets unpacked. While this should be relatively straightforward for attachments, for images it is hairier as the concept of an image node only accomodates 1 image.
If you haven't met already - I'd invite Scott Courtney to step forward at this point - please check out the good work he's been doing on "image_import" module ... which does this kind of stuff.
Welcoming thoughts and comments! Any advantages or disadvantages that I haven't thought of? Any technical problems that I haven't forseen?
just that people don't always want want images treated the same in all instances... that's the biggest stumbling block afaict. I think it makes sense to centralize where possible (as I've tried to get us started on)... but not everywhere, 'cause then we can't keep everybody happy ;) j -- James Walker :: http://www.walkah.net/
On Monday 18 April 2005 12:30, James Walker wrote:
The last point merits a little more attention as that is actually my impetus for bringing this up. I'm working on ways to upload multiple files from one screen, either via multiple upload forms or by uploading a .zip file which gets unpacked. While this should be relatively straightforward for attachments, for images it is hairier as the concept of an image node only accomodates 1 image.
If you haven't met already - I'd invite Scott Courtney to step forward at this point - please check out the good work he's been doing on "image_import" module ... which does this kind of stuff.
Good evening! My ISP had a routing problem earlier, so I may have missed any messages after this one in this thread (presumably, they'll eventually trickle in, but right now they're not in my inbox). Thanks, James, for the kind words. I am indeed working on image_import.module, which is designed to take one or more files that have been pre-uploaded to a Drupal-accessible directory on the webserver host, and import them in to create image nodes. My module uses the API provided jointly by James' new image.module and also the file upload API provided by upload.module and file.inc. Part of the latter is an indirect usage -- that is, I wrote image_import.module with the specific goal of creating large photo albums, so the only time I touch the core Drupal file API is for functions not provided by image.module. To the extent possible, I tried to (deliberately) make calls into image.module -- the idea being that image.module might in future change how it processes and stores the data, and I wanted to decouple from specific details of that code. I *needed* to be closely coupled to image.module, because, well, that's the core purpose of my code, but I didn't need to closely couple to the upload.module API. In one case, I had no choice but to make a call to a function James intended to be private (that is, one beginning with an underscore), because there was no realistic alternative. I've asked James to consider making that particular function, or a close equivalent, a part of his public API so that I don't have to bend the rules like this. I think Robert Douglass' suggestion about creating a general-purpose multiple- file import utility has a great deal of merit. It wasn't an idea that occurred to me when I was developing the original version of image_import. I was quite literally scratching my own itch with this one -- I'm a fairly serious amateur photographer, and while I like James' new image.module a lot, I didn't want to have to import photo albums one pic at a time! But Robert's suggestion is worth considering, IMO, although as James points out it is not as easy to implement as it might sound. In addition to the issues that James points out, there is also the fact that quite a few of the Drupal core file-importing functions perform a validation step to ensure that the file being imported really positively did come from an HTTP POST operation. The reason is security -- they don't want people importing /etc/shadow or similarly sensitive files in case of a PHP injection or similar vulnerability. But this unfortunately means that my code had to reinvent some wheels in order to get the files into the system, because by definition the multiple images that are pre-uploaded are *not* part of the current HTTP POST operation -- that is, after all, the whole point of my module. :-) [There is a part of me that is perversely proud to be the poster child for the problematic use case!] What I think I might do is to create a file import API that is separate from image_import.module, and which supports a generalized import as Robert suggests. Then I'll refactor image_import.module to use that API. If someone else wants to create another module that's similar to image_import.module but doesn't do the creation of auxiliary sizes, etc., then that might be a good contrib to what would become a module bundle. I'm perfectly willing to create it myself, but I've got another iron in the fire right now and don't have time to go beyond image_import in the very near term. Sorry this ranted on so long -- I am sort of thinking out loud here. Robert is not the first to suggest this particular idea, and I do think it is worthy of consideration. Let me give it some more thought, and I'll see what I can come up with, perhaps over this coming weekend. In the meantime, comments and suggestions welcome. Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
I will fight untill my last breath fort keeping images as nodes. ;) Why the hell would you want it as something different? No, serious. Images are nodes and that is the way it should be. If they are not, you loose a lot of flexibility and need lots of additional code to emulate all sorts of hooks that are now for free. And if you do not like image nodes to show up for users, then you need finer grained permissions, not images-as-some-alien-attachement, as you seem to propose. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
HMM. I think i was not really clear in my last post. sorry if i sounded hostile. I meant that fighting as a joke, since I am always figting for more things as nodes, (users as nodes, comments as nodes etc). Sorry for not makeing that more obvious. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
Thats fine Bèr, but then I don't understand why files attached via the upload module aren't nodes. My real goal would be to have images files that get loaded as attachments turn into image nodes. I think fscache does a service like this. -Robert Bèr Kessels wrote:
HMM. I think i was not really clear in my last post. sorry if i sounded hostile. I meant that fighting as a joke, since I am always figting for more things as nodes, (users as nodes, comments as nodes etc). Sorry for not makeing that more obvious.
Regards, Bèr
participants (5)
-
Boris Mann -
Bèr Kessels -
James Walker -
Robert Douglass -
Syscrusher