I think this was on the wish-list a while ago. Or maybe not.
Anyway, I felt like wanting this, so here's a cut at it.

 *  taxonomy_image_attach
 *
 * Add functionality to terms similar to the image_attach.module.
 * Allow a term editor to choose from EXISTING images rather than upload new ones all the time.
 * Currently this uses image.module handling of image nodes to index available images.
 *
 * TODO
 * The selection could be made either wider (all files/filesystem scan)
 * or narrower (images tagged in a certain gallery)

I've got it co-operating with the current term edit form, replacing the uploaded image as needed, being replaced by uploaded images as needed. Deleting category_images where appropriate, not deleting image.module images inappropriately.
Seems to work with the imagecache extension also.

Optionally (advanced) user can be given ability to choose from the image.module size presets (off by default), although now I see that taxonomy_image is doing good resizing, that's probably an un-feature.

There IS a small patch that prevents taxonomy_image.module deleting things it doesn't own, attached in the package.

Please try it out and see if it fits in the contribs

.dan.

Comments

nancydru’s picture

Being a Windows and and WinZip user, I can't open the patch file. Can you just load it as a text file, please?

dman’s picture

Um, OK.
You know that 'tgz' is just shorthand convention for .tar.gz right?

Rename it and it'll behave like the packages you are used to :-)
Sorry for typing so quick ;-)

nancydru’s picture

Only local images are allowed.Note the hair color...

Thanks

nancydru’s picture

Oops, it will delete, from the database, images it doesn't own, even with the safe-delete patch applied. I changed that code to:

  if ((substr($old_path, 0, strlen($taxonomy_image_path)) !=  $taxonomy_image_path)) {
  	// This file is not one of our own, don't actually delete it.
    $file_del_ok = true;
    $db_del_ok = true;
  }
  else {
    if ($how_many == 1) {
      // This is the only term using this file, so it is safe to delete it.
      $file_del_ok = file_delete($old_path);
    }
    else {
      // Pretend we deleted it.
      $file_del_ok = true;
    }
  }
dman’s picture

OK.
I was working on a DB I expected to be disposable, so probably didn't see that. I did notice when pre-owned files went missing (!) though.
It's all good for robustness! Thanks for picking that up.

dman’s picture

PS. Apologies for submitting something that appears to have tabs in. I got a new laptop/dev env recently and looks like my profile didn't get set up completely yet. Whoops
PPS. I think I am now a Mac switcher (!) eep.

nancydru’s picture

Uh oh. A bit of cross-posting. I modified the modification above a bit (moved the delete from term_image back out of the if).

Don't worry, Coder finds those tabs.

Small problem for me now: the new image list still shows the accidentally deleted image and I can't figure out where that's coming from. I forgot, Image creates nodes.

nancydru’s picture

Now all I have to do is decide whether or not to go ahead and commit the cache change so someone can test it.

dman’s picture

Well it doesn't BREAK anything ...until used (when it may inadvertantly delete exisiting images!)
um.
Eyeballs are good. If needed on this optional thingy.
Leave it in a dev release. I'll be re-checking it out in a few environments. Over a few weeks :-}.
As usual, it was just fixing an itch. May be some side effects I haven't forseen. But a safe fix on the file deletion is a good thing!

nancydru’s picture

Ouch: http://drupal.org/node/114774#file-check-upload You just uncovered a case where this change is not good.

Do you think changing if (file_check_upload('path')) { to if ($form_values('path')) { would suffice?

I don't have Image on my 6.x test system, so testing is kind of hard.

nancydru’s picture

Status: Needs review » Patch (to be ported)

Committed to 5.x-1.x-dev release.

dman’s picture

I'm really not au fait with the 6.x changes.
Is the story that file_check_upload() now a different beast, and had side-effects and such?

this is only a 5.x mod. if things need to be different for 6, then we'll look at it then. Or are we supposed to be doing legacy/upgrade support in realtime?
So yup. this is a 5.x thing. If something different needs to be done for 6 ... I'll get onto it when I have a few 6.x sites that may use it.

nancydru’s picture

No, file_check_upload is gone entirely. It sort of look like it is now done by if (isset($_FILES['files']) && $_FILES['files']['name'][$source] && is_uploaded_file($_FILES['files']['tmp_name'][$source])) but I don't know for sure.

But in this case it looks to me like checking if the base module's upload field has anything in it would work just as well.

At any rate, yes, I'm trying to keep both branches in sync on features.

nancydru’s picture

Title: Allow taxonomy_image to re-use images already available. I present : taxonomy_image_attach » Allow taxonomy_image to re-use images already available: taxonomy_image_attach

Just to let you know, there is a problem with the 6.x branch of Image: http://drupal.org/node/247457 http://drupal.org/node/233103.

nancydru’s picture

Status: Patch (to be ported) » Fixed

Finally committed to 6.x

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.