While working on #228159: Custom emails sent upon status change I decided it'd be nice to just use token.module for the token replacement stuff in signup_status_mailer. To do so, we need to expose some signup_status 'signup' tokens (which will be supported directly by various signup-related modules) for data contained in a specific signup. Stay tuned for a patch.
see also #549646: Expose signup-related node and signup values to token.module
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | 549648-6.signup_status_tokens.patch | 3.96 KB | dww |
| #5 | 549648-5.signup_status_tokens.patch | 3.78 KB | dww |
| #4 | 549648-4.signup_status_tokens.patch | 3.78 KB | dww |
| 549646-5.signup_tokens.patch | 10.14 KB | dww | |
| #2 | 549648-2.signup_status_tokens.patch | 2.78 KB | dww |
Comments
Comment #1
dwwComment #2
dwwNow with filter_xss(), just to be safe. The status name and description are entered by admins, not end users, but still. Since these tokens are used in plain text email, check_plain() isn't really what we want (and in fact, we don't even care about filter_xss(), either). However, if other modules start using these tokens in an HTML context, better safe than sorry...
Comment #4
dwwUpon further discussion, seems better to provide both regular and raw versions of these tokens, and let customers decide which to use as needed.
Comment #5
dwwNow without the PHP syntax error. ;)
Comment #6
dwwAfter more elaborate testing, there are cases where
$signup->statusis empty (e.g. users who signed up for something before signup_status was enabled, etc). So, now we're a little more careful about initializing those token values to avoid PHP notices.Comment #7
dwwGiven the review(s) by greggles and more testing from me, committed to HEAD.
Comment #8
dwwFollowup: Looking more closely at the default core tokens provided by token.module, it seems like '-' is used more frequently as the delimiter inside token names, not '_'. So, I just committed a change to switch from, e.g. [signup_status] to [signup-status] to HEAD.