Just playing with these hooks for the first time in Drupal 6 and just found an interesting limitation, you can not extend the existing values. I'm returning some values to append to the data array, and by doing so, I nuked the existing values loaded by FileField.

The quick workaround was to change my implementation of the hook_file_load() slightly, then modify the other code to move this into the FileField data array to integrate with FileField UI Extras, [I'm getting too many additional fields per image but the workflow is so easy to use!]

  $file->data['filefield_terms'] = filefield_terms_get_terms($file);
# to
  $file->filefield_terms = filefield_terms_get_terms($file);

Would it be worth doing an array_merge_recursive() instead of just array_merge() for all merges when loading this data? If so, I guess this should be lodged against Drupal 7 core, but I haven't looked closely at that code yet.

Members fund testing for the Drupal project. Drupal Association Learn more


quicksketch’s picture

The "data" array doesn't even exist in Drupal 7, so this won't be a problem there. In truth you probably shouldn't be using $file->data in Drupal 6 either unless you intentionally want that data to serialized and saved into the "data" column in the field's database table. However I do think you may have found something with $file->data not merging properly. I believe we should do a normal array_merge() on the data after (or before) calling hook_field_file_load(), since it's definitely unexpected that adding something would nuke the normal data that is stored in there.

Alan D.’s picture

While using the data array, I was manually unsetting the value before serialization. The issue was that this overrode existing values. I'm about to take off on a OE for a year, so I haven't much time to look into this.

quicksketch’s picture

Category: feature » support
Status: Active » Fixed

While using the data array, I was manually unsetting the value before serialization.

Ah, well that sounds quite separate. If you're putting things into $file->data on load you should be taking them back out before save if you don't want them saved, but you shouldn't be modifying properties of $file->data that you didn't add. That said, what you're during currently by loading something directly into $file->filefield_terms is perfectly acceptable and will actually be the only approach available in Drupal 7, so I'd suggest you stick with it anyway. Please reopen if you have further questions (and enjoy your trip!)

Alan D.’s picture

Thanks. Hoping we do not run into any Grizzlies, as we have heaps of camping planned. ;)

quicksketch’s picture

Category: support » bug
1.11 KB

After one more look at this during my work on #480754: filefield_meta: store audio metadata from getid3, I found the problem you are describing. FileField Meta currently does not implement hook_file_load() at all, but I'm adding an implementation so that it will properly load meta information for files that were uploaded before the module was enabled. However since FileField Meta stores its information in the "data" column, I ran into the exact problem you described: If implementing hook_file_load() and putting information in $file->data, that information is lost when FileField overwrites this with its own information.

This patch corrects this and merges the $file->data (if any) with the data loaded from the FileField column.

quicksketch’s picture

Sorry that last patch is way off. This patch properly merges the $file['data'] (provided by hook_file_load() implementations) and $item['data'] (provided by FileField) if they both exist.

Status: Fixed » Closed (fixed)

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