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