The imagefield module which depends on the filefield module is not displaying title and alt fields correctly (see http://drupal.org/node/350297) because the data is still being stored in a serialised array and has not been unserialized.

The patch attached appears to fix this issue but needs testing to make sure that it hasn't broken antthing else in filefield... or maybe this is not the correct place to fix this???

Comments

upupax’s picture

Patch doesn't work for me.
I've tried to modify or create new contents, but I still get warning: unserialize() expects parameter 1 to be string

drewish’s picture

Status: Needs review » Needs work

please post patches, not .gz files.

alexpott’s picture

StatusFileSize
new799 bytes

@upupax - Have you removed the changes you made to try the solution posted on http://drupal.org/node/350297
@drewish - okay here's it posted as a patch

alexpott’s picture

---

drewish’s picture

Status: Needs work » Needs review
StatusFileSize
new879 bytes
new879 bytes

Fixed the comment. Anyone else able to test this?

upupax’s picture

After reinstalling both modules everything seems solved..
Thanks a lot!

markus_petrux’s picture

The fix seems to solve the issue, but maybe the root of the problem is in CCK itself?

Curiously enough, CCK handles serialization transparently in content_write_record(), handling insert/update. However, it doesn't offer a similar feature on field data load. :(

CCK invokes hook_field('load') and filefield already does the unserialization in filefield_field_load(), so it seems the problem may only happen when field data is not loaded by CCK. Probably from Views? ...and this problem happens when the CCK views handler for a field invokes content_format() from the render method. Maybe that method could deal with unserialization, but that would be a CCK issue.

In cck/includes/views/handlers/content_handler_field.inc

     $item = array();
     foreach ($db_info['columns'] as $column => $attributes) {
-      $item[$column] = $values->{$this->aliases[$attributes['column']]};
+      if (empty($attributes['serialize'])) {
+        $item[$column] = $values->{$this->aliases[$attributes['column']]};
+      }
+      else {
+        $item[$column] = unserialize($values->{$this->aliases[$attributes['column']]});
+      }
     }

CCK could also handle the unserialization of field columns from content_storage('load'), and then filefield would not have to worry about it.

             foreach ($db_info['columns'] as $column => $attributes) {
-              $item[$column] = $row[$attributes['column']];
+              if (empty($attributes['serialize'])) {
+                $item[$column] = $row[$attributes['column']];
+              }
+              else {
+                $item[$column] = unserialize($row[$attributes['column']]);
+              }
             }
alexpott’s picture

Comment #7 seems to make a great deal of sense - after all if CCK is doing the serializing then it should handle all the unserializing!

markus_petrux’s picture

Well, I just opened bug report in the CCK issue queue: #364440: Inconsistent management of serialized columns

Let's see if this can be resolved in origin. If so, current code in filefield that unserializes the data could be patched to only invoke unserialize if $item['data'] is string, so it would still work with versions of CCK older than the one that could include support for unserializing in CCK itself. Well, maybe, it's just an idea.

drewish’s picture

drewish’s picture

Status: Needs review » Fixed

went ahead and committed this to HEAD. simple fix so there's no sense in waiting for CCK.

Status: Fixed » Closed (fixed)

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