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.
Hi,
there seems to be a bug on entity handling with the token replacement on custom caption text.
I made a field_collection containing an image and wanted to display it in a colorbox with a custom caption using tokens.
When I displayed it, I got a EntityMalformedException Message.
After a first look in the code, we found in colorbox.theme.inc on line 64
$caption = token_replace($settings['colorbox_caption_custom'], array('node' => $node));
where should be something like
$caption = token_replace($settings['colorbox_caption_custom'], array($entity_type => $entity));
this problem starts already in the colorbox_field_formatter_view function in colorbox.module
Thx for your help/work.
greets ifux
Comment | File | Size | Author |
---|---|---|---|
#10 | colorbox-entity_field_support-1545342-10.patch | 2.71 KB | Alan D. |
Comments
Comment #1
BerdirWhich means that the entity_type/entity needs to be passed to the theme function.
To fix this in a BC-compatible way, you can keep the #node argument there and additionally add #entity_type and #entity and then use that in your own implementation while overriden implementations can still rely on node being there.
Comment #2
frjo CreditAttribution: frjo commentedCommitted a fix to 7-dev. Please test and report back here.
Comment #3
BerdirYou need to use entity_label($entity_type, $entity) here, also once more below.
To get the entity id, you can use http://api.drupal.org/api/drupal/includes%21common.inc/function/entity_e.... Then the identifier should maybe be a combination of the entity type and id?
And, you should also update the field formatter settings form to list the token type there, you should be able to get the entity type out of the field instance I think. Not all token types map to the entity_type (e.g. term and taxonomy_term), but I think entity.module adds that information to entity_info() when it knows it.
Comment #4
frjo CreditAttribution: frjo commented@Berdir, thanks for the pointers! I have committed some changes to 7-dev now. Looks ok to you?
Comment #5
Alan D. CreditAttribution: Alan D. commentedLooking great. I think that you can do a search for the word node and replace by content or image depending on the context.
I would do this too.
Comment #6
Alan D. CreditAttribution: Alan D. commentedLet me know if you need a new issue for this (or a patch for the 2 loc), but it would it would be great to implement file tokens here too. The file tokens are not chained to the entity ([node:field_file:file-tokens....) via core nor token at the moment.
Minimal change, using the latest release (pre-entity changes):
And to get the token help:
We currently do this via a theme override:
This provides access to the file details, like the file size, etc, as well as possible integration with other modules. I'm porting ImageField Extended to D7 (long story - after high hopes for file entities and field collections we ruled both modules out) and the new version provides token values for each of the additional sub-field elements that it adds. [file:attributes-caption], [file:attributes-date-taken], etc.
Comment #7
Alan D. CreditAttribution: Alan D. commentedAs an aside, the token tree nearly kills the browser tucked into the formatter display. It would be nice to configure this in the global settings: eg: in admin/config/media/colorbox
Enabled field display token help
[*] content tokens
[*] file tokens
Then parse this to decide what tokens to display. Something like:
Worthy of a new feature request thread if you are interested.
Comment #8
BerdirChanges look good to me.
- The #node argument is explicitly always there to not break existing theme function overrides out there that rely on #node. We have for example done that do add support for field collections without having to patch the module, others might have done the same.
- Adding more things to the token_replace() function is probably better suited for a separate issue, and I disagree that the token browser should configurable. The only proper solution there is a lazy-loading ajaxified token browser.
Comment #9
Alan D. CreditAttribution: Alan D. commentedlol, that is the best quote that I have heard for a while - been tracking those threads for well over a year, and it is not going to happen for a very very long time.
Anyways, open #1555856: File Token support.
Comment #10
Alan D. CreditAttribution: Alan D. commentedThis was a bit perplexing in the user fields :)
Renames a number of comments and some t() strings.
Comment #11
frjo CreditAttribution: frjo commented@Alan D, thanks for cleaning it up! Committed to 7-dev.