When unhiding the extended taxonomy functionality of Gallery_Collection, see issue Gallery Containers (http://drupal.org/node/1037002), and allowing one gallery to have more than gallery_collection term, drag and drop sorting is not working properly anymore. As a matter of fact, the sort order for the particular term being sorted will be lost.
What happens is that the existing sort order for the given taxonomy term will be deleted before the new sort order is inserted, and inserting the new sort order will run into primary key violation and not be inserted.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Per Jansson’s picture

One 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

/**
 * Reorder a gallery collection.
 */
function media_gallery_reorder_collection($collection, $order) {
  // Get a complete ordered list of the galleries in this collection.
  $galleries = db_query('SELECT ti.nid FROM {taxonomy_index} ti LEFT JOIN {media_gallery_weight} mgw on ti.nid = mgw.nid  WHERE ti.tid = :tid ORDER BY mgw.weight ASC, ti.nid ASC', array(':tid' => $collection->tid))->fetchCol();
  // Sort the list.
  $galleries = _media_gallery_reorder($galleries, $order);
  // Resave gallery weights for the entire collection.
  db_delete('media_gallery_weight')
    ->condition('tid', $collection->tid)
    ->execute();
  $query = db_insert('media_gallery_weight')
    ->fields(array('tid', 'nid', 'weight'));
  foreach ($galleries as $weight => $nid) {
    $query->values(array(
      'tid' => $collection->tid,
      'nid' => $nid,
      'weight' => $weight,
    ));
  }
  $query->execute();
  return TRUE;
}

Line 189 :

$galleries = db_query('SELECT ti.nid FROM {taxonomy_index} ti LEFT JOIN {media_gallery_weight} mgw on ti.nid = mgw.nid  WHERE ti.tid = :tid ORDER BY mgw.weight ASC, ti.nid ASC', array(':tid' => $collection->tid))->fetchCol();

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:

...LEFT JOIN {media_gallery_weight} mgw ON (ti.nid = mgw.nid AND ti.tid = mgw.tid) WHERE ... 

This solution has also been posted under the issue Gallery Containers (http://drupal.org/node/1037002), which issue describes how to unhide the taxonomy.

Moloc’s picture

Title: Drag and drop sorting of galleries will break when unhiding taxonomy Gallery_Collection functionality » Drag and drop sorting of galleries will break when a gallery is in multiple collections (terms)
Version: 7.x-1.0-beta6 » 7.x-1.0-beta7
Status: Active » Needs review
FileSize
986 bytes

This 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.

Per Jansson’s picture

@Moloc
Yes, SELECT DISTINCT would be wrong. Thanks for pointing out (and writing the patch)

lsolesen’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

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