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.

CommentFileSizeAuthor
#1 colorbox-file_tokens.patch1.17 KBAlan D.
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Alan D.’s picture

Status: Active » Needs review
FileSize
1.17 KB

Patch 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)

frjo’s picture

Status: Needs review » Fixed

Thanks 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?

Alan D.’s picture

Excellent, 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.

# original patch in place
git add -A
git commit --author="cr0ss <cr0ss@432492.no-reply.drupal.org>" -m "Issue #1548496 by cr0ss, Alan D.:Name field and Devel generate integration."
git commit -m "Issue #1548496 by cr0ss, Alan D.:Name field and Devel generate integration (small refactor and code cleanup)."
# my changes if any; these were minor changes and formatting in this case
git add -A
git commit -m "Issue #1548496 by cr0ss, Alan D.:Name field and Devel generate integration (small refactor and code cleanup)."
# push both through
git push -u origin 7.x-1.x

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.

frjo’s picture

Thanks 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.

Status: Fixed » Closed (fixed)

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