Conditional date token

Actually, I've had the same thought. For example, if the updated date is not equal to the created date, then add a "changed on..."

I'll have to think about how this might be done.

I think the Token module needs to consider this.

This is an interesting idea, but I don't think it makes sense for token.

The token module is a simple API for text replacement, not logic.

Logic belongs in code.

So who owns the node token creation? Personally I think there should be a token created there that is the last changed date - and it should be either "created" or "changed," perhaps with a companion token that tells which it was. I agree that it is a "code" issue, but it is a Node issue.

Marked #454460: Include "last updated" date as duplicate.

Sorry for the dupe- subscribing. If I get some free time I'll also try to contribute thoughts / patches to this.

There might be some useful information in #354039: Token logic module patch. I think the consensus is that implementing logic with tokens is redundant, and something that should simply be handled with PHP. So would it be possible to

• Allow PHP input in Submitted By, and
• Solve this problem using PHP?

If so, we should move this back to the Submitted By queue.

Allow PHP input in Submitted By

Not in a module I'm involved with. IMO, code belongs in text files.

Ain't gonna happen in Submitted By either.

But I see no problem with logic creating tokens, as many do now.

  if ($object->changed > $object->created) {
    $last_edit_date = $object->changed;
    $last_edit_type = t('changed');
  }
  else {
    $last_edit_date = $object->created;
    $last_edit_type = t('created');
  }
... make tokens

That sounds reasonable. I am just curious, why is everyone opposed to using PHP? Is it a security issue? I do in fact agree with the quote mentioned in the other thread along the lines of "why reinvent PHP with square brackets?" Then again I am relatively new to this :)

Yes, PHP can open up security exposures. It is also not necessarily available.

function submitted_by_token_values($type, $object = NULL, $options = array()) {
  $tokens = array();
  switch ($type) {
    case 'node':
      $node = $object;
      $tokens['author-link'] = theme('username', $node);

    // Conditional last edit tokens. See http://drupal.org/node/377726
    $editor_uid = db_result(db_query("SELECT uid FROM {node_revisions} WHERE vid=%d", $object->vid));
    $editor = user_load(array('uid' => $editor_uid));
    $tokens['last-editor'] = theme('username', $editor);
    
    if ($object->changed > $object->created) {
      $last_edit_date = $object->changed;
      $last_edit_type = t('changed');
    }
    else {
      $last_edit_date = $object->created;
      $last_edit_type = t('created');
    }

    $tokens['last-edit-type'] = $last_edit_type;
    $tokens += _submitted_by_token_date($last_edit_date, 'last-edit');
  }
  return $tokens;
}

function submitted_by_token_list($type = 'all') {
  $tokens = array();
  if ($type == 'node') {
    $tokens['node']['author-link'] = t('Link to author.');
    // Conditional last edit tokens. See http://drupal.org/node/377726
    $tokens['node']['last-editor'] = t('The last user to edit the node.');
    $tokens['node']['last-edit-type'] = t('The last edit type (created, changed) for the node.');
    $tokens['node']['last-edit-small'] = t('Node last edit - small');
    $tokens['node']['last-edit-medium'] = t('Node last edit - medium');
    $tokens['node']['last-edit-large'] = t('Node last edit - large');
    $tokens['node']['last-edit-since'] = t('Node last edit - interval');
    $tokens['node']['last-edit-yyyy'] = t('Node last edit year (four digit)');
    $tokens['node']['last-edit-yy'] = t('Node last edit year (two digit)');
    $tokens['node']['last-edit-month'] = t('Node last edit month (full word)');
    $tokens['node']['last-edit-mon'] = t('Node last edit month (abbreviated)');
    $tokens['node']['last-edit-mm'] = t('Node last edit month (two digit, zero padded)');
    $tokens['node']['last-edit-m'] = t('Node last edit month (one or two digit)');
    $tokens['node']['last-edit-ww'] = t('Node last edit week (two digit)');
    $tokens['node']['last-edit-date'] = t('Node last edit date (day of month)');
    $tokens['node']['last-edit-day'] = t('Node last edit day (full word)');
    $tokens['node']['last-edit-ddd'] = t('Node last edit day (abbreviation)');
    $tokens['node']['last-edit-dd'] = t('Node last edit day (two digit, zero-padded)');
    $tokens['node']['last-edit-d'] = t('Node last edit day (one or two digit)');
    $tokens['node']['last-edit-hh'] = t('Node last edit hour (two digit, zero-padded)');
    $tokens['node']['last-edit-ii'] = t('Node last edit minute (two digit, zero-padded)');
    $tokens['node']['last-edit-ss'] = t('Node last edit second (two digit, zero-padded)');
  }
  return $tokens;
}

function _submitted_by_token_date($date, $prefix = NULL) {
  if ($prefix) {
    $prefix .= '-';
  }
  $values = array(
    $prefix .'small'  => format_date($date, 'small'),
    $prefix .'medium' => format_date($date, 'medium'),
    $prefix .'large'  => format_date($date, 'large'),
    $prefix .'since'  => $date ? format_interval(time() - $date) : t('Never'),
    );
  $date = (int)$date;
  $values += array(
    $prefix .'yyyy'  => date('Y', $date),
    $prefix .'yy'    => date('y', $date),
    $prefix .'month' => date('F', $date),
    $prefix .'mon'   => date('M', $date),
    $prefix .'mm'    => date('m', $date),
    $prefix .'m'     => date('n', $date),
    $prefix .'ww'    => date('W', $date),
    $prefix .'date'  => date('N', $date),
    $prefix .'day'   => date('l', $date),
    $prefix .'ddd'   => date('D', $date),
    $prefix .'dd'    => date('d', $date),
    $prefix .'d'     => date('j', $date),
    $prefix .'hh'    => date('h', $date),
    $prefix .'ii'    => date('i', $date),
    $prefix .'ss'    => date('d', $date),
    );

  return $values;
}

Afaik, this is the right status...

Very disappointing - this clearly belongs in the node tokens code.

Nothing about this is "clear" other than the fact that Eaton and I both dislike the idea of fancy tokens like this. 1) it's token bloat for a very specific use case 2) it's possible for anyone who needs this to do so in their own modules.

Just because token module is the centralized point for the API doesn't mean that it should also provide every single token.

May its an interesting idea... But, not working on all times... try again...

Email Database