If you see the following code from views/filefield_handler_views_data.inc you should note the "TODO." It would be great if this were fixed. I believe it would fix #600594: Integration with Views? Addendum in the imagefield_extended module's queue and allow many other modules that use the data field to be more extensible.

<?php
    $form
['data_key'] = array(
     
'#title' => t('Data key'),
     
'#type' => 'radios',
     
// TODO: Pull these values from the modules that extend FileField.
     
'#options' => drupal_map_assoc(array('description', 'title', 'alt')),
     
'#required' => TRUE,
     
'#default_value' => $this->options['data_key'],
     
'#description' => t('The data column may (or may not) contain any of the following data. Select the data that should be output for this field.'),
     
'#weight' => 4,
    );
?>

Comments

Thanks for filing an issue for tracking this issue. The question is how should this actually be implemented? My guess is that we'll need a hook like hook_filefield_data() that would report the name of values stored in the 'data' column.

<?php
function imagefield_filefield_data() {
  return array(
'title' => t('Title'), 'alt' => t('Alt text'));
}
function
filefield_filefield_data() {
  return array(
'description' => t('Description'));
}
?>

What you stated seems resonable, but looking at the serialized string created by imagefield_extended there may be some issues with the way strings are constructed in that module:

a:2:{s:16:"album_song_title";a:2:{s:4:"body";s:12:"1. El Choclo";s:6:"format";s:0:"";}s:15:"album_song_desc";a:2:{s:4:"body";s:19:"by Angel G. Villodo";s:6:"format";s:0:"";}}

Notice that the two fields I added were album_song_title and album_song_desc. These have "body" inside of the string, which does not seem to exist in title, alt and description.

a:2:{s:3:"alt";s:14:"CD Tray Insert";s:5:"title";s:51:"Decisions for three percussion players - Back of CD";}

See these contain no "body."

Hmm, yeah that makes things more challenging. It also means that FileField's existing Views integration won't work with the data added by ImageField Extended without some modification. However if ImageField Extended is consistent with its structure, I would probably be fine with a simple check like this:

<?php
if (!is_array($data[$key])) {
 
$output = check_plain($data[$key]);
}
elseif (isset(
$data[$key]['body']) && isset($data[$key]['format'])) {
 
$output = ($data[$key]['format'] === '') ? check_plain($data[$key]['body']) : check_markup($data[$key]['body'], $data[$key]['format']);
}
?>

yes, in my experience the 'body' is consistently used in the structure and should work the way you wrote above. This will cover getting it working within filefield I think and then I can try to reference whatever hook you decide on over in imagefield_extended. Once you make a decision on the implementation I will post a patch following the decision here to the imagefield_extended module and that should really solidify data on filefields being used in views.

Subscribe: Thx quicksketch & nicholas.alipaz, it will be nice to get this feature request resolved in my queue.

@quicksketch - the module, ImageField Extended was extended to use the cck alter hooks and is based on the FileField rather than ImageField now, with no custom widget [sick of requests to extend to accommodate other modules]. I will wait until the Drupal 7 port before renaming it, but the same functionality should be automatically included with any ImageField / FileField. I still have to look at the Drupal 7 fields Image and File to see what this means.

Is there any need for expanding ImageField Extended for other fields? I think that there has only once been a single request for something other than a checkbox or textfield, a select list. If so, any recommendations on the need for these. I think keeping only 1 to 1 relationships will be a definite so it will not complicate any Views integration issues.

Anyway open to suggestions, you can use my contact form to send through your thoughts.

Is there any need for expanding ImageField Extended for other fields?

I would probably discourage extending the functionality of ImageField Extended to other fields. ImageField Extended is just a stop-gap measure until the CCK project gets Multifields/Multigroups figured out (it's actually already in the 3.x version, but there's a big question about what to do since Multifields are not in Drupal 7).

Speaking of Drupal 7, you'll find that ImageField Extended is going to have quite a hard time because the is no longer a "data" column at all, so you can't just tack on extra information like you can currently. I'm not sure if ImageField Extended is even going to be possible in Drupal 7. It certainly is going to need an entirely different approach, since it's going to have to maintain it's own schema.

Fingers crossed for Multifields getting into D7 CCK and an upgrade path of some description... Silently say thanks and exit so not to clutter the thread any more....

Subscribing

Subscribing, without Views integration, Imagefield Extended cannot be widely used.

StatusFileSize
new2.72 KB

Here is a reworking for the filefield_handler_field_data.inc which seems to be working on my system. I created no hooks, just did some smart discovery to see what labels are available in the database and then do some checks to allow getting their values properly.

Is there are way to extend Filefield's filefield_handler_field_data class by ImageField Extended to enable this functionality? I don't believe Filefield maintainer will make changes in code just to satisfy Imagefield Extended data structure (body, format, formatted)...

Actually he did mention doing a check within his module above. #735512-3: Views filefield-data should not be hard-coded

Also, the issue is not that imagefield_extended needs to support views, it is that all modules that extend filefields data should be supported in views by filefield if they follow a predetermined structure.

Nicholas, I agree that standardized approch is desirable. What I wanted to say is that body, format and formatted keys within data array is something that for now is specific to Imagefield Extended only. On the other hand it gives other modules an opportunity to reach Filefield Views field handler at least for these fields.

As far as I know, ImageField Extended is pretty much the only module that saves additional user-facing data in the data column. Generally I don't encourage using the data column at all, since it's a dirty hack more than something that should be widely used. If you needed to sort/filter on that data, clearly you'd need an additional column or table. Yet another reason why "data" doesn't exist in Drupal 7. I don't really care what we do with the data column, because we don't need to think about long-term consequences because it's already dead.

quicksketch, did you have a look at the altered inc file I supplied? If you would rather it as a patch then I can redo it as so, just let me know.
#735512-10: Views filefield-data should not be hard-coded

Hi nicholas, yes a patch would be much, much preferred. I can't tell what's changed in your version.

Status:Active» Needs review
StatusFileSize
new3.31 KB

Here is the patch. I haven't heavily tested it so it may need some work.

StatusFileSize
new3.01 KB

oops, that last patch seems to remove something that changed recently. Here is a better version of the patch.

Although I very much would love the funcionality of this issue, I think a hook (like in #1) is much better approch rather than for Filefield to search (in a hackish way, I'd say) for keys to show. Other modules implement the hook to let Filefield know what keys they have.

Also, body, format and formatted might also be the model of what Filefield looks after in Views handler render() function.

Sorry, no code provided, only ideas.

quicksketch, you have any comments on this? I didn't feel it was "hackish" but perhaps I am wrong. I mean those keys are going to be where they are whether we provide a hook or we search for them. And like quicksketch said, "I don't really care what we do with the data column, because we don't need to think about long-term consequences because it's already dead."

quicksketch, if you would prefer an alternative approach then please describe and I will see what I can do. The only issue I see with the hooks is the time to adopt the new hooks in other modules. I am under a deadline and needed to go with my patch for one site, but can change later if this changes and other modules follow suit.

If we want to be flexible (aka "clean") about it, then we should indeed make not one but two hooks. One hook that returns a list of items within the 'data' column, and then another hook that actually displays data when requested. So in other words we should have an additional hook that handles something like this:

<?php
function mymodule_filefield_data_render($item, $data_key) {
  return
check_markup($item['data'][$data_key], $item['data']['format']);
}
?>

So this would be better generally speaking. Though as I've said, the "data" column is little importance to me personally and in the future of this project.

The patch is not working. The field is not listing in the views editing page? Either it won't support Drupal 6.16 Version or what?.. Advance Thanks.

I think I may have missed some sguiggly brackets in my mysql statements {}. If your database has a prefix then this will not work. I am not going to rework the patch since it is not the way the guys here want to do it.

Can you please give some info on how to rectify the problem? I am forced to use a db prefix and I really need a way to accomplish this task. The way the PHP code is written doesn't matter to me.

You should only need to change the line:

$row = db_fetch_array(db_query("SELECT %s FROM %s WHERE %s <> 'b:0;' LIMIT 1", $fdata, 'content_' . $field, $fdata));

to read:
$row = db_fetch_array(db_query("SELECT %s FROM {%s} WHERE %s <> 'b:0;' LIMIT 1", $fdata, 'content_' . $field, $fdata));

But I don't really suggest using this live. It was just to demonstrate an idea, and hopefully get the ball rolling on getting this functionality in views.

subscribing

subscribe

subscribe

subbing

subscribe

subscribe

I agree we should use hooks to fix this, but in I needed this now ;p

I had to change _filefield_get_field_data() because I was gettings errors:
1/ added db_storage = 0 to the first select
2/ added extra check to make sure $data is an array

function _filefield_get_field_data() {
  $result = db_query("SELECT field_name FROM {content_node_field} WHERE db_storage = 0 AND type = 'filefield'");
  $options = array();
  while ($field = db_fetch_array($result)) {
    $field = $field['field_name'];
    $fdata = $field . '_data';
    // we check for %s <> 'b:0;' since this is what an empty serialized string looks like (empty strings won't work)
    $row = db_fetch_array(db_query("SELECT %s FROM %s WHERE %s <> 'b:0;' LIMIT 1", $fdata, 'content_' . $field, $fdata));
    $data = unserialize($row[$fdata]);
    if (is_array($data)) {
      foreach ($data as $key => $val) { // push all the keys into an array
        $output = check_plain($key);
        array_push($options, $output);
      }
    }
  }
  return $options; // our list of labels
}

subscribe

Version:6.x-3.x-dev» 6.x-3.7
Status:Needs review» Fixed
StatusFileSize
new4.08 KB
new3.85 KB

This patch adds the new hook for hook_filefield_data_info(), as well as the utility function filefield_data_value(), which can be used to print out a value given a portion of the $item['data'] array, such as $item['data']['description']. Since FileField and ImageField both just contain plain-text strings for its data, this data is simply passed through check_plain() and needs no specialized function.

I've gone ahead and committed this patch, please let me know if any changes look like they're necessary to assist ImageField Extended or other modules that utilize the $data column.

Also attached is the patch to ImageField which defines ImageField's "alt" and "title" columns. Both patches will be included in the 3.8 version of both modules.

StatusFileSize
new766 bytes
new4.08 KB

Sorry I got my file names mixed up, here are the final patches.

It looks good to me by the looks of the code in the patch, I will try to find time to test it if possible.

Version:6.x-3.7» 6.x-3.9

sorry to say that,
there is a typo in
views/filefield_handler_field_data.inc:33 now:
parathesis
suppose should be -> parentheses
(plural of parenthesis)

Thanks, fixed the typo.

StatusFileSize
new1.85 KB

I was attempting to try out the patches and look into patching imagefield_extended but the patch didn't complete. I have attached my rejected parts from the patch. I did not test further due to the rejects.

$ cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -d filefield-HEAD contributions/modules/filefield/
...
$ cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -d imagefield-HEAD contributions/modules/imagefield/
...
$ cd filefield-HEAD/
$ wget http://drupal.org/files/issues/filefield_data_hook_0.patch
$ patch -p0 < filefield_data_hook_0.patch
patching file filefield.module
Hunk #1 succeeded at 526 (offset 53 lines).
Hunk #2 succeeded at 971 with fuzz 2 (offset 433 lines).
patching file views/filefield_handler_field_data.inc
Hunk #1 FAILED at 18.
1 out of 1 hunk FAILED -- saving rejects to file views/filefield_handler_field_data.inc.rej
$ cd ../imagefield-HEAD/
$ wget http://drupal.org/files/issues/imagefield_data_hook_0.patch
$ patch -p0 < imagefield_data_hook_0.patch
patching file imagefield.module
Hunk #1 succeeded at 311 (offset 16 lines).

Version:6.x-3.9» 6.x-3.7

You don't need to try out the patches, they have already been included in FileField 3.8 and 3.9. The only thing that needs patching in the current version of FileField is the small typo posted in #37, which won't affect functionality.

As per the ImageField Extended support for this patch see #600594: Integration with Views? Addendum which is still to be implemented (eg: to implement the new hook). I'm only got marginal internet access, and limited time as we make our way down the eastern central american coast, so I personally haven't the time to fix this issue, but I am open to having co-contributors for IF Extended if anyone wants to speed things up. Ping this thread if your interested - #927738: Co-maintainers. Only precondition is that you have had experience with at least one other Drupal module so that you understand the protocol for CVS, etc.

Cheers

Status:Fixed» Closed (fixed)

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