The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Use Filters for the Token content rather than asking users to write PHP.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | token_custom_php_filter_1336622.patch | 7.95 KB | gaspaio |
| #1 | token_custom.patch | 6.52 KB | robloach |
| #1 | screenshot12.png | 43.65 KB | robloach |
Comments
Comment #1
robloachExposing PHP to the end user is definitely not a good idea. This patch makes it use filters instead. The upgrade path is supported.
Comment #1.0
robloachUpdated issue summary.
Comment #2
dave reidHow does this work if $options['sanitize'] = FALSE is provided from token_replace()?
Comment #3
dave reidAside from #2, I think this is a *great* change. Easily allows 'simple' tokens while also allowing the complex PHP tokens.
Comment #4
gaspaio commentedOk thanks. This change was actually on my short term roadmap, i totally agree with the fact that a default PHP field is a nono.
I'll check your patch over the weekend ; i'm curious to see how you pass the $data array to the filter when php filter is on.
Thanks.
Comment #5
gaspaio commentedAdded a few changes to your patch : the $data and $options arrays are now available to the evaluated php code (if php filter is used). It should solve #2 and keep the current features.
Comment #6
gaspaio commentedJust commited latest patch to the newly created dev release.
The issue remains open for a while since this still needs some testing.
Thanks.
Comment #7
gaspaio commentedSince this is a major change, that might not please all of the module's users, this patch was moved to the a new version branch - 7.x-2.x (it should be visible in a few hours).
Version 7.x-1.x will keep the old PHP-only approach and receive bug fixes only.
Comment #8
gaspaio commentedComment #8.0
gaspaio commentedUpdated issue summary.