Expose signup-related node and signup values to token.module
dww - August 14, 2009 - 21:38
| Project: | Signup |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | dww |
| Status: | closed |
Description
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-related data as tokens, both node tokens (for node settings) and for 'signup' tokens (which will be supported directly by various signup-related modules) for data contained in a specific signup. Stay tuned for a patch.

#1
While I was at it, I simplified some code to take advantage of theme('token_help') instead of our own custom version of that.
#2
In testing, I noticed that during new signups,
$signup->signup_timewasn't being set. Now fixed.#3
Greggles balked at the variable named "curtime". ;) Here it is as "current_time".
#4
Now with filter_xss() on the custom signup form values, just to be safe. 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, especially since these are entered by end users (even anonymous visitors). Also, to be extra paranoid, I cast the signup limit value to an int. ;)
#5
Upon further discussion, seems better to provide both regular and raw versions of this token, and let customers decide which to use as needed.
Also adds the attendance bit as another signup token.
#6
Now with a description on the token help fieldset encouraging users to choose the -raw versions where available, since this is for ASCII email.
#7
Given the review(s) by greggles and more testing from me, committed to HEAD and DRUPAL-6--1.
#8
Followup: 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. [node_signup_limit] to [node-signup-limit] to both
HEAD and DRUPAL-6--1.
#9
Follow-up: There were cases where the 'mail' field isn't inside our happy $signup object, resulting in PHP notices. Cleaned up and fixed in HEAD and DRUPAL-6--1.
#10
Automatically closed -- issue fixed for 2 weeks with no activity.