Closed (fixed)
Project:
Media Gallery
Version:
7.x-1.0-beta7
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
24 Sep 2011 at 06:05 UTC
Updated:
13 Jul 2012 at 23:41 UTC
Jump to comment: Most recent file
Comments
Comment #1
Per Jansson commentedOne fix for this is the following:
The table holding the sorted galleries is media_gallery_weight, easy to check.
In the file
media_gallery.pages.inc line 184 to 208 approx we find the following function for reordering galleries
Line 189 :
returns a result that will violate the key constraints of media_gallery_weight and when this happens, first your sort order for the term you are sorting will be deleted and then when inserting the new one it does not work and you get an SQL exception (in the ajax calls), thereby leaving you with a deleted sort order but not updated. This happens if there are galleries with more than one gallery collection taxonomy term and as soon as the primary key constraint is violated. It does not happen immediately, don't be fooled by it looking smooth.
One way to fix the SQL above is to use SELECT DISTINCT, another is to use the full primary key in media_gallery_weight, nid and tid, in the LEFT JOIN condition, rewriting the left join:
This solution has also been posted under the issue Gallery Containers (http://drupal.org/node/1037002), which issue describes how to unhide the taxonomy.
Comment #2
moloc commentedThis issue is only reproduceable, if you change the default media_gallery content-type. If you change the unlocked media_gallery_collection field to allow more than one collection-terms be chosen, the mentioned select statement is wrong and returns not the correct entries.
The applied patch fixes that.
The patch uses the mentioned LEFT JOIN condition, as this will fetch the correct entries.
Using DISTINCT is wrong and will result in the same behavior as before.
To reproduce this bug, you should also apply the patch in #1228094: Gallery rearranging is not stored.
Comment #3
Per Jansson commented@Moloc
Yes, SELECT DISTINCT would be wrong. Thanks for pointing out (and writing the patch)
Comment #4
lsolesen commented