Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
$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,
);
Comment | File | Size | Author |
---|---|---|---|
#39 | filefield_handler_field_data.inc_.rej_.txt | 1.85 KB | nicholas.alipaz |
#35 | filefield_data_hook.patch | 4.08 KB | quicksketch |
#35 | imagefield_data_hook.patch | 766 bytes | quicksketch |
#34 | filefield_data_hook.patch | 3.85 KB | quicksketch |
#34 | imagefield_data_hook.patch | 4.08 KB | quicksketch |
Comments
Comment #1
quicksketchThanks 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.
Comment #2
nicholas.alipaz CreditAttribution: nicholas.alipaz commentedWhat 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:
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.
See these contain no "body."
Comment #3
quicksketchHmm, 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:
Comment #4
nicholas.alipaz CreditAttribution: nicholas.alipaz commentedyes, 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.
Comment #5
Alan D. CreditAttribution: Alan D. commentedSubscribe: 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.
Comment #6
quicksketchI 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.
Comment #7
Alan D. CreditAttribution: Alan D. commentedFingers 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....
Comment #8
srobert72 CreditAttribution: srobert72 commentedSubscribing
Comment #9
maijs CreditAttribution: maijs commentedSubscribing, without Views integration, Imagefield Extended cannot be widely used.
Comment #10
nicholas.alipaz CreditAttribution: nicholas.alipaz commentedHere 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.
Comment #11
maijs CreditAttribution: maijs commentedIs 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)...Comment #12
nicholas.alipaz CreditAttribution: nicholas.alipaz commentedActually 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.
Comment #13
maijs CreditAttribution: maijs commentedNicholas, 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.
Comment #14
quicksketchAs 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.
Comment #15
nicholas.alipaz CreditAttribution: nicholas.alipaz commentedquicksketch, 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
Comment #16
quicksketchHi nicholas, yes a patch would be much, much preferred. I can't tell what's changed in your version.
Comment #17
nicholas.alipaz CreditAttribution: nicholas.alipaz commentedHere is the patch. I haven't heavily tested it so it may need some work.
Comment #18
nicholas.alipaz CreditAttribution: nicholas.alipaz commentedoops, that last patch seems to remove something that changed recently. Here is a better version of the patch.
Comment #19
maijs CreditAttribution: maijs commentedAlthough 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.
Comment #20
nicholas.alipaz CreditAttribution: nicholas.alipaz commentedquicksketch, 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.
Comment #21
quicksketchIf 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:
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.
Comment #22
phpteamer CreditAttribution: phpteamer commentedThe 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.
Comment #23
nicholas.alipaz CreditAttribution: nicholas.alipaz commentedI 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.
Comment #24
mark. CreditAttribution: mark. commentedCan 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.
Comment #25
nicholas.alipaz CreditAttribution: nicholas.alipaz commentedYou should only need to change the line:
to read:
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.
Comment #26
asb CreditAttribution: asb commentedsubscribing
Comment #27
milos.kroulik CreditAttribution: milos.kroulik commentedsubscribe
Comment #28
milos.kroulik CreditAttribution: milos.kroulik commentedsubscribe
Comment #29
gg4 CreditAttribution: gg4 commentedsubbing
Comment #30
cmseasy CreditAttribution: cmseasy commentedsubscribe
Comment #31
kliker CreditAttribution: kliker commentedsubscribe
Comment #32
attiks CreditAttribution: attiks commentedI 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
Comment #33
mattiasj CreditAttribution: mattiasj commentedsubscribe
Comment #34
quicksketchThis 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.
Comment #35
quicksketchSorry I got my file names mixed up, here are the final patches.
Comment #36
nicholas.alipaz CreditAttribution: nicholas.alipaz commentedIt looks good to me by the looks of the code in the patch, I will try to find time to test it if possible.
Comment #37
Thomas_Zahreddin CreditAttribution: Thomas_Zahreddin commentedsorry to say that,
there is a typo in
views/filefield_handler_field_data.inc:33 now:
parathesis
suppose should be -> parentheses
(plural of parenthesis)
Comment #38
quicksketchThanks, fixed the typo.
Comment #39
nicholas.alipaz CreditAttribution: nicholas.alipaz commentedI 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.
Comment #40
quicksketchYou 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.
Comment #41
Alan D. CreditAttribution: Alan D. commentedAs 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