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.
It would it would be great to implement file tokens here.
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):
case 'custom':
- $caption = token_replace($settings['colorbox_caption_custom'], array('node' => $node));
+ $caption = token_replace($settings['colorbox_caption_custom'], array('node' => $node, 'file' => (object) $item));
break;
default:
$caption = '';
And to get the token help:
if (module_exists('token')) {
$element['colorbox_token'] = array(
'#type' => 'fieldset',
'#title' => t('Replacement patterns'),
'#theme' => 'token_tree',
- '#token_types' => array('node'),
+ '#token_types' => array('node', 'file'),
'#states' => array(
'visible' => array(
':input[name$="[settings_edit_form][settings][colorbox_caption]"]' => array('value' => 'custom'),
),
),
);
}
There are about 10 file tokens to the approx 2MB token tree (1000's tokens) that is being generated from the node system, so minimal additional overhead, but very handy.
Comment | File | Size | Author |
---|---|---|---|
#1 | colorbox-file_tokens.patch | 1.17 KB | Alan D. |
Comments
Comment #1
Alan D. CreditAttribution: Alan D. commentedPatch to help speed this up.
Since the commiter log is fairly short, do you know about "Adding a commit author" - http://drupal.org/node/1146430? It is something that I'm trying to do on all my projects now to credit users that contribute (though not that this two liner is worthy, lol)
Comment #2
frjo CreditAttribution: frjo commentedThanks for this nice improvement to Colorbox! Committed to 7-dev.
I know about "Adding a commit author" and would apply it if I received git aware patches.
Do you do it manually otherwise?
Only when people ask for it or always?
Comment #3
Alan D. CreditAttribution: Alan D. commentedExcellent, thanks!
In core, you do not get credit this way, in the Views queue you always get credit. It depends on the maintainer. It is personal choice as there are no guidelines.
Personally, I think it helps generate community involvement with others outside of the core maintainers, making some more likely to spend time on patches, thus in the benefit of all involved. I assume these are also taken into account with ratings at http://certifiedtorock.com but it is impossible to tell.
I've only just started doing this myself, but I try to do it with the raw patch, commit this locally, do any required cleanup / modifications, then also commit locally, then push.
I find git integration with Eclipse terrible still, so I use a command line tool to add, commit and push / pull.
For me, a typical patch workflow is:
1) Copy and paste off drupal.org directly into a running project, checking code style / functionality etc.
2) Doing any modifications required. If directly involved, doing these myself or giving feedback for the person working on it.
3) Once generally happy with the patch, I would commit the original patch raw to the local clone, then my own changes (if any) and push through.
Of the 50 or so patches that I have received, I have never had one with generated with format-patch and I do not generate patches myself this way.
Comment #4
frjo CreditAttribution: frjo commentedThanks Alan D for the workflow example! I to always use git in cli, I do most stuff in cli :-).
I will see if I can automate the --author stuff.