When an image node is edited it changes position in the gallery, and in image taxonomy listings. This is not the usual 'most recently edited' item floating to the top. The edited image simply shifts to a different place in the gallery with no apparent logic.
As far as I can tell this happens because image module sorts the images in a gallery by the node creation timestamp, and for some reason the creation timestamp is being incremented a little on editing the node. (Of course the changed timestamp also changes as expected.)
Here's and example.
Lets take this gallery http://sphop.perlucida.com/image/tid/62
And change the title from sphp_2002_061_henk.jpg to Seagulls on this image:
http://sphop.perlucida.com/node/322
Prior to the change we have the following (info extracted from the db):
nid: 322
title: sphp_2002_061_henk.jpg
created: 1117550744
changed: 1117550744
And the image is listed between sphp_2002_062_henk.jpg and sphp_2002_060_henk.jpg as you'd expect.
We change the title and image moves to appear between sphp_2002_067_henk.jpg and sphp_2002_066_henk.jpg as you can see:
http://sphop.perlucida.com/image/tid/62?from=12
The db now gives:
nid: 322
title: Seagulls
created: 1117550756
changed: 1117558316
So, why does the created timestamp change at all, and can I stop that happening?
I should say that the images in the gallery were initially imported using import_image.module - but I don't see what this could have to do with that.
Comment | File | Size | Author |
---|---|---|---|
#9 | created.patch | 602 bytes | killes@www.drop.org |
#3 | node_module_created.patch | 591 bytes | dtan |
#1 | node.module.created.patch | 591 bytes | dtan |
Comments
Comment #1
dtan CreditAttribution: dtan commentedYou'll notice that there is an authored on text box. . .it doesn't provide seconds, so when the timestamp is created, it picks up the current minutes seconds. Thus if you edit a node (any type) and view its created field in the db, and continuously repeat over 60 seconds, you will see the created loop back down.
Here is the patch. . .which is actually applied to the node.module.
Comment #2
ezheidtmann CreditAttribution: ezheidtmann commenteddtan, your patch contains html.
Comment #3
dtan CreditAttribution: dtan commentedanother one :)
Comment #4
Jose Reyero CreditAttribution: Jose Reyero commentedHey dtan, I'd say very good catch :-) , tested the patch and seems to be ok.
Anyway, I think this bugfix needs to be posted to Drupal core.
Comment #5
mfb+1
Comment #6
adrinux CreditAttribution: adrinux commentedNo time to test this until next week myself, but It's already got two +'s so I'm moving it to core and re-titleing.
Thanks to dtan for hunting this one down :)
Comment #7
adrinux CreditAttribution: adrinux commentedHad time to test dtan's patch properly and can now say definitively that it does fix this problem.
That is, without this patch the node created timestamp changes on a node edit. With this patch applied only the node changed timestamp changes, as you'd expect.
So +1 on this getting applied ASAP.
Comment #8
adrinux CreditAttribution: adrinux commentedI made a version of this patch for CVS HEAD: http://drupal.org/node/26960
Comment #9
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedOk, it is a bit difficult to see why this fixes the problem, but yes it does. The incorrect data format causes node->created to change by up to 59 seconds which can cause time ordered nodes eg from uploads to change position.
I've re-roles the patch for cvs from http://drupal.org/node/26960 and attach it here.
Comment #10
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedThe previous review was brought to you by Patch Bingo!
http://drupal.org/patchbingo
Comment #11
Dries CreditAttribution: Dries commentedCommitted to HEAD and DRUPAL-4-6.
Comment #12
(not verified) CreditAttribution: commentedComment #13
Uwe Hermann CreditAttribution: Uwe Hermann commented