Currently, file_metadata_table_sort() has a special-case for if you're trying to sort on 'cid', even though that's now a column not handled natively by this module at all. ;) That brings up the interesting question of how sorting should work in case another module is altering a new column into place. I haven't actually thought about this much, but I wanted to open an issue about it so I don't forget. ;)
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | 1867100.patch | 6.09 KB | jthorson |
Comments
Comment #1
jthorson commentedOne approach would be to add another parameter to hook_file_metadata_table_metadata(), indicating whether a field should be considered numeric or string-based.
So instead of:
We could use:
This would require minor tweaks to file_metadata_table_metadata() to have it store the sort parameters as well ... in which case I would rename the function file_metadata_table_types(), and create a new file_metadata_table_metadata() wrapper function which returns only $key => $type['title'] (identical structure to the existing function today).
After these changes, the sort function could be modified as follows:
Comment #2
jthorson commentedImplemented as described above.
Comment #3
jthorson commentedCommitted as b71041f.
Comment #5
jthorson commentedModule name change.