Call to undefined function _event_date() when using signup broadcast

i haven't investigated, but this definitely sounds like a bug to me. should be easy to fix if anyone wanted to try rolling a patch for it.

Me, me.
Errm here's the patch :-)
The description of the body-field is changed additionally depending on whether event.module is present or not ("%time" is hidden but will be replaced by t('[Untimed]') if you insert it).

Stefan

cool, thanks. a few minor nits:

1. for this:
   

   +  $supported_strings = ('Supported string substitutions: %event, %username, %useremail.');
   +  if (module_exists('event')) {
   +    $supported_strings = ('Supported string substitutions: %event, %time, %username, %useremail.');
   +  }
   

   i'd rather see the non-event $support_strings defined in an else block instead of defining it twice like this.
   or, you could do something like this:

   $tokens = array('%event', '%username', '%useremail');
   if (module_exists('event')) {
     $tokens[] = '%time';
   }
   $token_text = t('Supported string substitutions') .': '. implode(', ', sort($tokens)) .'.';
   ...
   

2. i know this problem is in the existing code, but if you're going to be changing it, you should fix it in this patch... the %foo variables should never really be presented inside a string passed to t(), since they're in fact not translatable at all, and aren't the usual usage of % placeholders in t() strings. my solution above fixes this too, but if you go another route, please preserve this fact.
3. again, i'd rather see $trans['%time'] = t('[Untimed]') initialized in an else case than defined twice.

all of this would be easy for me to just fix before i commit, but i'm posting it here for educational value, and to make it more likely that future patches you submit for signup (and i hope they keep coming!) will be more likely to be committed as-is, instead of requiring additional work from me.

thanks,
-derek

i know this problem is in the existing code, but if you're going to be changing it, you should fix it in this patch... the %foo variables should never really be presented inside a string passed to t(), since they're in fact not translatable at all, and aren't the usual usage of % placeholders in t() strings. my solution above fixes this too, but if you go another route, please preserve this fact.

What about using t('Supported string substitutions: %tokens.', array('%tokens' => implode(', ', sort($tokens))));
Using this you would have the option to place the tokens whereever you want within the string due to translation.

sure, that works. i suppose the RTL translators would prefer it this way, in fact. ;) it means the token list will be passed through theme('placeholder'), and therefore both check_plain()'ed (needlessly) and wrapped in <em> tags (probably for the best). but yes, that'd be fine with me with. thanks.

it means the token list will be passed through theme('placeholder')

Hm, true.
But this is not necessary, i.m.o. (I used "%" because I was not really familar with the "new" three options yet). The strings are defined within the module and don't contain neither html nor other risky data.
So we can use !tokens?!

_{PS: the patch is ready; you only have to (dis-)agree to this}

% is fine. as i said, it's needlessly calling check_plain(), but it's not double-escaping anything, so it's still correct. however, visually, these are placeholders, and therefore, they should go through theme('placeholder') so that they're wrapped in <em> (at least by default... themes are free to consistently change how placeholders look by implementing this theme function themselves). that's what i tried to say above, but perhaps wasn't clear enough. thanks.

Ok, you've persuaded me :-)
The tokens really look better after theme('placeholder').
Attached is the (hopefully) completed patch to be committed.

greetings,

Stefan

yup, that's just lovely. reviewed, tested, and committed to HEAD. thanks. minor, tiny change: i left the commented-out %info in there, just to remind us that we're still not handling that case, even though we might want to be.