I believe the "delta" in the node reference table refers to the offset in a field with multiple values. As in: an array of references from one field indexed by their delta's. This is used to display the nodes referenced in a particular order.
this module sets the delta to be the NID, much like the (non javascript) select widget defined in nodereference.module . It's not really a problem with the normal multiple select widget because there isn't any obvious ordering to how you've selected the nodes, but with multiselect, you can induce a particular ordering, thus the delta field can have a useful value. For instance, if I select (in this order) to reference nodes 4, 1, and 2, then submit my node, the published version will have the nodes referenced in the order 1, 2, then 4.
If it's not clear what I mean, use the autocomplete widget, and reference nodes 4, 1, and 2. Their order is maintained.
I've hacked the module in such a way as to re-index the node_field array in multiselect.module and it works, so I think it should be possible to fix, but I'd rather have someone more comfortable with the module change it.
here's what I changed (starting from line 180):
case 'process form values':
//Replace the node values
if ($field['multiple'])
{
$node_field = content_transpose_array_rows_cols(array('nid' => $node_field['nids']));
//since the node_field is ordered correctly, we can manually re-index the deltas.
$new_delta = 0;
$reindexed_node_field = array();
foreach($node_field as $old_delta => $nid ){
$reindexed_node_field[$new_delta] = $nid;
$new_delta++;
}
$node_field = $reindexed_node_field;
}
else
{
$node_field[0]['nid'] = $node_field['nids'];
}
When I save a node using this code then view it, the order is as expected, but when I edit the node, the form populates the multiselect widget in the order of the referenced nodes's nids, thus when saved it reverts to the undesirable ordering.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | save_deltas.diff | 3.47 KB | michael_kirk |
Comments
Comment #1
Mac Clemmens commentedThank you -- I was having this problem when using the module to add sidepanels in a particular order to the sidebar of my page. You saved me a big headache!
Comment #2
funkeyrandy commentedgreat fix!!!!!
any ideas how to get the newly ordered list to stay that way when re-editing??
Comment #3
michael_kirk commentedThis works for both populating the edit form and saving the data from the form.
Populating the edit form:
Previously:
All possible values are generated.
All previously selected values are generated.
The field is populated with all values.
All entries that were not previously selected are removed from the field via javascript.
Now:
All previously selected values are generated.
All previously unselected values are generated.
All values is the concatenation of both (selected+unselected). This allows proper ordereing when...
All entries that were not previously selected are removed from the field via javascript.
Saving the data from the form:
Using the order of entries in the field rather than the value of the field to index the results.
edit:
my initial patch didn't work with previewing the node. I've fixed that too and attached an updated patch encompassing all my changes.
edit edit:
sorry, I attached a patch with debug statements in it, and forgot to set an important variable. Really, the newly attached patch should do it, for real this time. seriously.
Comment #4
michael_kirk commentedComment #5
michael_kirk commentedThis doesn't work in the case of previewing. I guess that's yet to come.
edit: done (updated initial comment with new patch, up 2 ^^^^^)
Comment #6
michael_kirk commentedI checked this into -dev tonight.
Comment #7
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.