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_... Kind regards, Scott (drupal.org "syscrusher") -- -----------------------+------------------------------------------------------ Scott Courtney | "I don't mind Microsoft making money. I mind them scott@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