This is the restart of http://drupal.org/node/113614 . That issue is beyond control IMO. So what would we like to do here, what's the use case? I have two typical cases which very nicely show the problems we face:
- Allow users to enter tokens in text for mails. This typically means text.
- Allow an action with a user specified message.
Now what's a user here? Surely the user has some special privileges but likely not on the level of executing PHP.
When implementing, another problem we face is that some content is only available in HTML: node bodies and teasers, as stored in the database must be ran through check_markup, it can be markdown, bbcode, whatever. So the token system output can not be anything but HTML if we want it to work with node bodies and teasers. Also, because the output here is HTML escaped we must make the rest of the tokens HTML escaped. Then case1 can be handled by drupal_html_to_text and case2 is OK. If you want to use a token in another context, then you can freely convert as the token output is only escaped, it's a reversible operation, so if you want to see Briggs & Riley with a literal ampersand, then you can run html_entity_decode.
Now that the rationale is set, the implementation is quite straightforward. I guess we will need a token info hook as well.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | token_proposal.patch | 2.44 KB | chx |
| token_proposal.patch | 1.55 KB | chx |
Comments
Comment #1
dave reidAside from the fact that I'm betting
function drupal_token($matches)should probably befunction _drupal_token($matches), I very much like this token concept. We'll definitely need a token info hook. I'll try and keep reviewing as this progresses.Comment #2
chx commentedI have added a
variabletype to tap into the variable subsystem. I think we should let a higher level admin change which tokens can be used in a given environment. We could use a variable info hook to provide defaults (much sought after feature), documentation and then we have the token description already. Same with schema where we already have the description. This would leave particularly little to be done in the token info hook itself.Moshe tells me we already use token for security tokens. Also, PHP has a tokenizer. Confusion. We need a better name.
Edit: I forgot to tell you guys about the new
$unescapedparameter which allows you to use tokens in node bodies and similar places to avoid a double encode.Comment #3
chx commentedAt webchick's request, an example of the new system would be "[title] created on [created:Y-m-d]" which gets replaced with the node title and the created date formatted as year-month-day. It's not that different from the old one...
Comment #4
chx commentedI let anyone else do whatever they please I am done here.
Comment #5
strategictech commentedI would like to propose the use of DOMDocument as a replacement for this. SGML, or xhtml, provides a mechanism for adding "Tokens" called tags. I do not see a reason to build another interface to handle this.
Comment #7
michaelfavia commentedI think that the discussion at the issue that this forked from is coming to a decent conclusion and rendering this moot now that chx has decided to focus his efforts elsewhere. Please reopen if youd like to adopt this issue.