Custom caption field

Scald does not want to fully support Token integration. If you want it, you can use the Entity Token module (in the Entity API project) and will have all fields available as token in the Atom player.

In fact we cannot use Entity Tokens module, since it makes replacements based on entity name which is scald_atom in the case, while scald module passes atom as atom. To make it work (and keep it consistent) we should pass atom with scald_atom key.

Definitely we should use [scald_atom:field_caption] in player settings after applying this patch.

Now, if

Scald does not want

, and you can write a patch, you can also write a module (it's easier !)
I use this code for years, without trouble

/**
 * Implements hook_token_info().
 */
function myModule_token_info_alter(&$data) {
  $data['tokens']['atom']['sid'] = array(
    'name' => t("Id"),
    'description' => t("The unique ID of the atom."),
  );
  $data['tokens']['atom']['field_caption'] = array(
    'name' => t("Caption"),
    'description' => t("The caption field of the atom."),
  );
  $data['tokens']['atom']['url'] = array(
    'name' => t("URL"),
    'description' => t("The URL of the atom page."),
  );
}

/**
 * Implements hook_tokens().
 */
function myModule_tokens($type, $tokens, array $data = array(), array $options = array()) {
  $replacements = array();
  if ($type == 'atom' && !empty($data['atom'])) {
    $atom = $data['atom'];
    $sanitize = !empty($options['sanitize']);
    foreach ($tokens as $name => $original) {
      switch ($name) {
        case 'sid':
          $replacements[$original] = $atom->sid;
          break;
        case 'url':
          $replacements[$original] = base_path().'atom/'.$atom->sid;
          break;
        default:
          if (substr($name, 0, 6) == 'field_') {
            $language = $atom->language;
            $replacements[$original] = $sanitize ?
             $atom->{$name}[$language][0]['safe_value'] : 
             $atom->{$name}[$language][0]['value'];
          }
      }
    }
  }
  return $replacements;
}

Hope this helps...

gifad,

you can use the Entity Token module (in the Entity API project) and will have all fields available as token in the Atom player.

I completely agree with this approach: why to duplicate functionality provided by another module. However due to the reason explained in #5, the statement I've just cited is currently wrong and the module should be fixed respectively, to make the citation true.

As for writing own module, I believe having the original module fixed is more proper approach than creating such a "crutch" in each project where I need Scald.

As for the patch, I forgot about back-compatibility. Here's corrected patch.

Alex Bukach, I agree with you about the approach, my suggestion was just a quick and dirty workaround (keywords: quick, work), just in case "scald does not want to..."

Now, about your patch :

The compatibility issue is fixed for the settings entered with the original scald package;
But other contributed player modules will have to update all "token_replace()" calls..
This probably means a "Change record", and that's perhaps what "scald does not want to..."

Also, with Entity Tokens installed, [scald_atom:field_caption] still does not work : one must use [scald_atom:field-caption] (note the different hyphen)
Go explain the user which token works and which does not...

[About my "crutch", one need to check if (isset($atom->{$name}[$language][0])) in case a field is allowed to be empty - Nobody's perfect..]

gifad, I agree, custom module is good as a quick workaround, but why not to make it work properly when it's possible? I suspect not everybody using Scald is able to write a module. :)

First, the patch does not break anything for other modules providing players. Simply they will still not support tokens provided by Entity Token module, but nothing is broken. We'll have to provide respective patches for each of them once we need this support from them, that's it.

Second, right, we have to use [scald_atom:field-caption], but anyway it's much easier than writing own module, and having some option is better than having none.

Thus, the patch (1) breaks nothing and (2) provides a simple way to use tokens for fields. Do I miss anything why it should not be committed?

If it ain't broken, why do you fix

-    $caption = token_replace($settings['caption'], array('atom' => $atom));
+    $caption = token_replace($settings['caption'], array('scald_atom' => $atom));

in scald_image.module ? (2218205-8.patch, lines 9,10)

I have the very same line in my module, and it IS broken, until I apply the same fix (same for all token_replace() using scald provided tokens).

I'm using drupal 7.34, scald 7x.1.3 or scald 7x.1.3+1-dev, token 7.x-1.5, with or without my "crutch", Entity tokens module enabled or not.
The offending token being [atom:title] or [scald_atom:title]
And yes, I flush all caches before each test.

I have the very same line in my module

gifad, what is your module?

gifad, nevermind, you are right. Finally got your point.

What would you say about this patch?

Hi Alex,

#14 is quite correct on the compatibilty side;
I just have to patch a $element['view']['token_help']['help'] in my player's settings to have the "Atoms" fieldset showing, but this is minor (not blocking)

[quote: "gifad, what is your module ?" - It's a very standard scald image player, which just manages custom (site specific) "options" of the AtomProperties dialog - BTW, that's very easy (and safe) to implement with the new widget plugin !]

Gifad, what player's $element['view']['token_help']['help'] are you talking about? Your custom one?

Also, what do you mean by "the new widget plugin"?

@Alex
The element is part of standard way to show "Replacement patterns" from Token module;
You have a sample implementation in aron.beal's patch #4

The new widget plugin is the one introduced in Scald 7.x-1.3+1-dev
Worth a tour !

Regards

Thanks gifad. #7 works great.

sample code from #7 is great. works. thank you for this.