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.
I'm able to use $entity successfully in display code entered into the field configuration form directly. However, attempting to use $entity in a custom display function results in an error indicating that $entity is undefined. Any chance it can be made available to custom display functions?
Additionally, while working on this, I found that:
computed_field_field_job_posting_number_display($field, $entity_field_item, $entity_lang, $langcode)
...resulted in errors indicating that $entity_lang and $langcode were undefined. I had to remove them from the function's arguments list.
Comment | File | Size | Author |
---|---|---|---|
#2 | computed_field-pass_entity_to_disp_func-1883156-2.patch | 2.41 KB | rjacobs |
Comments
Comment #1
rjacobs CreditAttribution: rjacobs commentedYes, this would be a nice tweak. Being able to use the "display code" as a way to dynamically aggregate data from other fields and/or entity info into a custom field is a nice feature of this module. However, as wrd pointed out, this is currently is not possible without storing code in the DB (which is not ideal).
It looks like the custom display function is called inside computed_field_field_formatter_view() with the following:
Given that $entity is also available in the computed_field_field_formatter_view() scope, it would seem this could be accomplished via a simple adjustment of the above snippet to something like:
$entity would have to be added to the end for backwards-compatibility I suppose. Some string tweaks would also be needed on the settings form details.
It would be interesting to hear from a maintainer as to whether-or-not there is a good reason not to do this, especially as $entity is already available to eval'd versions of the display code.
Comment #2
rjacobs CreditAttribution: rjacobs commentedHow about the attached patch? This was made with git format-patch and is against dev. It's based on the points from comment #1
wrd, perhaps you can test this out?
Comment #3
rjacobs CreditAttribution: rjacobs commentedI'm going to categorize this as a bug report for now. My justification for doing this is the fact that the module description states the following:
The issue here is that in the case of a custom field that a.) does not store it's values in the database, and b.) uses a custom display function (as opposed to evaluated code), I don't think it's actually possible to "draw on anything available to Drupal". Specifically it does not seem to be possible to tap into the values of "other fields", as the values passed to the custom display function do not contain any reference to the current entity id, let alone the entity itself. This means that we can't even do an entity_load() to get the entity data.
If I'm being too liberal on my use of "bug report" here, please change back. However, unless I'm missing something, this is a somewhat limiting situation and the fix should be pretty straightforward. I know it's always possible to define custom fields manually with the fields API to get around this, but for prototyping purposes it's sooo much more efficient to use this handy module.
Comment #4
rjacobs CreditAttribution: rjacobs commentedJust wanted to bump this.
Is there anyone else out there interested in this? I can't review my own patch and my guess is that the maintainers aren't interested in things not marked RTBC.
Sometimes one just needs a tool to build dynamic chunks of content that are computed from existing entity data (no need to add the data to the database), and having that chunk act like a field is very powerful for prototyping purposes. It would be a shame to have to write my own tool to do this given that this kind of feature seems squarely within the intended domain of computed_fields.
Comment #5
AaronBaumanI'd argue it's all but imperative that display_func have access to the same arguments as the hook_field_formatter_view function.
(In fact, I'd argue that the display_func should have exactly the same function signature as hook_field_formatter_view, but at this point that would break all existing implementations and therefore not be practical.)
Definitely a bug, since the display_func has necessarily less functionality than it would had it been defined only through field settings.
RTBC++
Comment #6
rjacobs CreditAttribution: rjacobs commentedThanks for reviewing Aaron!
Comment #7
colanCommitted in d41e3f4.