[drupal-devel] Make image module an extension of upload module
scott at 4th.com
Tue Apr 19 01:34:58 UTC 2005
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.
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
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 Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184
scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184
More information about the drupal-devel