[drupal-devel] image_import.module ready for early testing

[Scott Courtney]

It's not done yet, but the image_import module that works with walkah's new
(and wonderful!) image module is feature-complete and ready for functional
testing to begin. I tested it last night by importing batches of images
ranging from 1 file to 50+ files, with and without auxiliary caption files,
and although there are some things I still want to improve (such as adding
really "deep" clickable help links within the module, and fixing a minor
menu annoyance), it is working correctly.

The code is *not* yet compliant with Drupal standards for tabs and indents
and such, so don't yell at me yet for that. I happen to prefer editing with
tab indents rather than spaces, so I typically use a global replace to convert
the code to space indents only after I'm done with it.

My CVS commit notice has hit the drupal-devel list, but I'm contacting the two
of you individually because I would very much value your input and testing
assistance, if you have the time, since my module specifically interacts with
both of yours.

James, I would also like to ask a favor of you with regard to your code. I
found myself having to call _image_build_derivatives() from my code, because
there just wasn't any other good way to get the resizing task done. All the
higher-level published functions that call that one do a security check to see
if the file came from the $_FILES[] global HTTP variable, and since my import
images are pre-uploaded using FTP, SCP, etc., I can't pass that security test.

So what I'm asking is, would you consider making that function non-private, a
supported part of the API for your module, so that I can [reasonably] rely on
it in future releases?

Alternatively, would you consider exposing a new public function that accepts
a skeletal $node object, with attributes of type ('image'), body, teaser,
uid, title, and file (all of which I can supply), but which has not yet been
created as a node in the database? The function I propose would add the node,
retaining any pre-supplied attributes, and would return either $nid (integer)
or the $node object itself (with new attributes, especially nid, populated).
In effect, this would migrate about 25 lines of code from import_image.module
to image.module, and would be a hook that other importing modules could use
if their image files came from a non-HTTP source.

If you aren't interested in making these changes, I'll abide with what you have
now, and just risk that I might have to do a rewrite in the future. But I think
the image_build_derivatives() [non-private] and/or the other proposed function
[which might be called image_build_node() for example) might have value to
other developers.

For instance, a module might someday exist that takes PDF
or PS files, renders the first page as a PNG or JPG, and turns that into an
image node for placement in a book hierarchy along with a download attachment
of the original file. How do I know this is plausible? Well, my boss asked
me just last week if such a thing were possible, because we may have a customer
willing to pay me to develop it and release the code as GPL when it's done. :-)
[This is by no means a certainty; we're just exploring options. The customer
has an extremely large document library of PDF/PS files and they are wanting
to webify access to it.]

I would very much appreciate and respect your opinions, testing reports,
suggestions, and constructive criticism of my module so far. I'm looking to
get it polished up in the next couple of days and then move it from sandbox
to contributions/modules. I've also submitted a project node for it, but
experience says it may be a week or more before that gets approved (my last
one was a week ago and still isn't on drupal.org yet).

The code repository is at:

http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher/image_import/

Kind regards,

Scott (drupal.org "syscrusher")

-- 
-----------------------+------------------------------------------------------
Scott Courtney         | "I don't mind Microsoft making money. I mind them
scott at 4th.com          | having a bad operating system."    -- Linus Torvalds
http://4th.com/        | ("The Rebel Code," NY Times, 21 February 1999)
                       | PGP Public Key at http://4th.com/keys/scott.pubkey