Allow taxonomy_image to re-use images already available: taxonomy_image_attach
| Project: | Taxonomy image |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | patch (to be ported) |
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.
| Attachment | Size |
|---|---|
| taxonomy_image_attach.gif | 31.02 KB |
| taxonomy_image_attach.tgz | 3.17 KB |
#1
Being a Windows and and WinZip user, I can't open the patch file. Can you just load it as a text file, please?
#2
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 ;-)
#3
Thanks
#4
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;
}
}
#5
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.
#6
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.
#7
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.#8
Now all I have to do is decide whether or not to go ahead and commit the cache change so someone can test it.
#9
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!
#10
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')) {toif ($form_values('path')) {would suffice?I don't have Image on my 6.x test system, so testing is kind of hard.
#11
Committed to 5.x-1.x-dev release.
#12
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.
#13
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.
#14
Just to let you know, there is a problem with the 6.x branch of Image:
http://drupal.org/node/247457http://drupal.org/node/233103.