_image_remove_derivatives deleting {files} entries that Image doesn't own

yeah, you shouldn't be attaching other files to the image nodes. i'm not sure when it changed but it's been that way since i've been using the module, (4.7/5.0).

mind if i ask what you are using the feature for? we might be able to come up with a workaround...

This is a very timely thread! I have just upgraded my site from 4.6 to 5 and been hit by the same issue. I use image nodes as the main content type on my site, and I therefore sometimes want to attach files.

I've not looked inside image, but is there a logic for not being able to retain attached files to this node type? If the intent is that attachments are not allowed at all, then it shouldn't be possible to attach them when the node is first created. If you can attach files, then they should persist between edits??

If I get a chance I might take a look, but I am ironing out bugs on my upgrade at the moment :-)

The "problem" seems to lie in _image_remove_derivatives() as this does a blanket delete of all files other than the original.

So the solution would be only remove those files that are to do with image, and leave the rest alone.

I've been puzzling over this and attached a quick (and dirty!) patch that only removes files whose path contains the image path, by referring to the image_default_path.

I also put the delete query inside the if statement, so it gets called once for each derivative. I also changed it to remove entries from the files table using the file->fid, since we already got this, rather than doing a string based check on filename.

I gave this a very quick check on my local set up and it seems to be ok, but it's late so there might be better ways of doing this!

marked http://drupal.org/node/145844 as a duplicate

i liked the duplicates title better

marked http://drupal.org/node/156112 as a duplicate

Here's a comprehensive approach that moves the images to an {images} table rather than {file_revisions}. It doesn't support revisions at this point but it'd make much easier to do.

here's a re-roll that gets rid some some wonky line-endings in the .install file.

better version. this includes the patch from http://drupal.org/node/142178

getting better. i was running into a warning on the upgrade about duplicate values. it should be straightened out now.

newer copy of update #4 and it adds a 'rebuild derivative images' check box so you can rebuild a single image without having to try to track it down in the admin/content/node screen.

i'm going to try to get #142178 and #156127 committed before i pick this back up.

okay i committed the other two patches. here's a re-roll.

I used the latest -dev module with the new image_142178_2.patch. But every time I use the 'rebuild image derivates' check box I get a mysql warning like this:

user warning: Duplicate entry '53-_original' for key 1 query: INSERT INTO test_image (nid, size, fid) VALUES (53, '_original', 175) in /srv/www/htdocs/community/includes/database.mysql.inc on line 172.

In fact a similar warning also showed up when I installed the module with the patch and ran update.php.

To add to my previous post, there does not seem to be any errors in rebuilding though. The files are regenerated correctly.

pknag, at some point you got two _original images attached to node 53. i'd hoped the patch committed as part of http://drupal.org/node/142178 would fix this. it corrected the problem on my machine. if you wouldn't mind, could you contact me via my contact form so i can get in touch with you to either get a dump of your table or access to your machine?

Drewish, Sent you a mail through the contact form. I can send you the mysql dump easily.
The problem exists even when I create a new image node with a new picture. It creates the image node fine, but when I use the rebuild function the warning crops up.

pknag, looking through the db dump you sent, it seems like image_update_4() should be able to correct the issues. can you try re-running that update and paste the results of it into the issue?

OK, so I backed up my database, applied the image_142178_2 patch, ran update.php, and tried to attach an image to an image node. To do this, I used "add image" on the body text field: /img_assist/load/textarea?textarea=body .

I left things as default in image_attach's popup (size: thumbnail, align: left, link: to image page, insert mode: html code).

Clicking "Insert" (on the popup) and then "Submit" (on the node) gave me the image title as text underneath the main image on the node - but no thumbnails.

Selecting "Filter tag" instead of "html code" (on the popup) (and input format: filtered html on the node) gave me the image-attach gibberish underneath the main image node instead ([img_assist|nid=13536|title=Calendula|desc=|link=node|align=left|width=125|height=83]).
(But then, I haven't been able to get any drupal [] commands to work, dunno why not.)

I can see the appeal of this: add related images' thumbnails, with links, below the main images ... lovely idea, really.

If that's not how you're supposed to add images to image nodes, I'd love to hear how this should be tested.

Thanks!

Hetta, thanks for giving this a look. I haven't tested this with img_assist. i should probably install it and test it out. by add i just meant create a few new image nodes from node/add/image or via the image_import module. but if everything else looked good for you that's a very good sign.

Image import works a treat with this patch applied to image 1.4. I can see no problems in galleries or elsewhere, either.

It's possible that the patch is working perfectly well for img_assist as well, but img_assist is currently wonky, in that it doesn't display images ... http://drupal.org/node/151767

yeah the img_assist is a separate issue that currently affects 1.4.

this patch adds views support for the image tables.

few changes:
- renames the {image}.size field to {image}.image_size to distinguish it from file sizes. this means you'll need to drop the {image} table and re-run image update #4.
- renames the _image_get_sizes() function to image_get_sizes() but adds a helper function _image_get_sizes() for backwards compatibility.
- removes _image_remove_derivatives() and moves the code into image_update() which is the only place it should be called.
- _image_save() now takes an optional array of sizes to save. i'm not totally sure this is the best way to do it, it might be better to just have a parameter that tells it to skip the original.

I'd love to give that a shot, but:

---- start quote ---
hk@linux:/$local/sites/all/modules/image> patch < image_133436_5.patch
patching file image.install
patching file image.module
patching file views.inc
can't find file to patch at input line 596
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|Index: contrib/image_attach/image_attach.module
|===================================================================
|RCS file: /cvs/drupal-contrib/contributions/modules/image/contrib/image_attach/Attic/image_attach.module,v
|retrieving revision 1.9.2.15
|diff -u -r1.9.2.15 image_attach.module
|--- contrib/image_attach/image_attach.module 4 Jul 2007 04:40:32 -0000 1.9.2.15
|+++ contrib/image_attach/image_attach.module 11 Jul 2007 18:36:07 -0000
--------------------------
File to patch:
---- end quote ---

That's with the latest dev file: the image_attach.module ends at line 409. Gotta run now, else I'd see how to get the cvs file ... (cvs.drupal.org for image shows image_attach to be dead? And the rest, too, except for a readme file.)

it looks like you might need to try "patch -p0 < foo.patch"

that last patch had some db_queryd() calls in it.

This new patch is the same as the previous one. It still has the db_queryd. I just edited the calls and seems to work so far. I will post more results of testing soon.

ah, right you are. here's a re-roll that'll apply cleanly to the current DRUPAL-5 branch.

I can confirm that img_assist does not work with the latest dev version of the module. It gives a fatal error saying that the function _image_insert() cannot be found. It looks this function used to exist in the 1.4 version of image and took three args. The dev version of the image module has only the image_insert() function defined which takes only one arg.
I had been using the 1.4 version of img_assist with the img_assist_v2.patch posted on http://drupal.org/node/156246. This was working earlier.
Should this be a new thread? I posted it here since I had also used the latest patch posted here which seems to be working fine so far.

do you mean -dev or with this patch? if it's not working with the -dev version i think that's be an issue with img_assist. i'm going to post a message to the image group to try to coordinate so that everything works for the next release. perhaps i'll bump the version number to 5.2 to make it easier to spot compatible versions.

re-rolled

i'm trying to pull out the rebuild thumbs part of this code and get it committed in #133436. i'll revisit this once that's committed.

Drewish, to clarify your question in #35: Img assist does not work with the -dev version because it looks for _image_insert() function which is non-existant in the new -dev release. img_assist works with the 1.4 version of image. In 1.4 I noticed there are two functions: image_insert() which in turn calls _image_insert() both with three args. The new -dev version has just image_insert() with one arg. Looks like either image module should have the old _image_insert() function or img_assist should adapt to the new function call. I do not know much of either to even figure this out. The img_assist group kind of moves very slow and so I was hoping I can find a fix here. It should really be a new issue though.

Drewish, to clarify your question in #35: Img assist does not work with the -dev version because it looks for _image_insert() function which is non-existant in the new -dev release. img_assist works with the 1.4 version of image. In 1.4 I noticed there are two functions: image_insert() which in turn calls _image_insert() both with three args. The new -dev version has just image_insert() with one arg. Looks like either image module should have the old _image_insert() function or img_assist should adapt to the new function call. I do not know much of either to even figure this out. The img_assist group kind of moves very slow and so I was hoping I can find a fix here. It should really be a new issue though.

Looks like acidfree also has the same problem. It is looking for _image_insert() with three args.

Drewish before I send you on wild goose chase, the problem comes from the latest patch not from the -dev version. The new patch image_133436_8.patch removes the _image_insert function. Sorry, it was my mistake, I have so many tar files that I was confused as hell here.

i've committed this to HEAD since it'll be going into a DRUPAL-5-2 branch. i'm going to mark this a fixed and handle anything else in subsequent issues.

--------------
great work drewish

I get these problems on drupal 5.6 with php 4.4.7 and image module 5.1.6:

1) only user1 and users with specific permission can see the image in the node
2) the attached image disappear when re- edit a node.

I found a lot of patchs in http://drupal.org/node/133436

which pach will fix this issue?

Make a backup of your database, apply one patch, clear your various drupal caches (I use phpmyadmin for that), check what happens, reverse that patch, apply the other patch, clear your caches, check what happens, and report back.

Thanks.

You could, of course, also contemplate upgrading to 5.x-2.x-dev -- and if your problem persists, open a new issue for it. This one is closed.