Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Depends on #1996910: Add context to system filters
Since Twig is now in core, and with the above patch, giving the ability to filter using the Twig rendering engine will give the power of the PHP filter without the security implications.
With Twig with have control blocks, i.e. if, for, etc that give so much power in how the content will be rendered.
So an example in a Commerce module instead of creating a token to display all the items purchased, these can be rendered individually.
{% for item in transaction.items %}
{{ item.title }} {{ item.cost }}
{% endfor %}
Or even when sending a email when the user is created. we could add a list of roles
{% spaceless %}
{% for role in account.roles %}
{{ role.name }}
{% endfor %}
{% endspaceless %}
This is extremely powerful, and is already built into Drupal 8, so adding the ability to filter by this is something that should be also done.
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | drupal9.filter-module.1996922-14.patch | 2.5 KB | gordon |
| #14 | drupal9.filter-module.1996922-14.patch | 53 bytes | gordon |
| #11 | 0002-Add-new-Twig-filter.patch | 2.48 KB | gordon |
| #8 | 0002-Add-new-Twig-filter.patch | 2.45 KB | gordon |
| #2 | 0002-Add-new-Twig-filter.patch | 2.37 KB | gordon |
Comments
Comment #1
gordon CreditAttribution: gordon commentedI have updated the twig filter to work with the new filtering system
Also I have found that the twig filter will work in a WYSIWYG editor unlike the php filter which doesn't
Comment #2
gordon CreditAttribution: gordon commentedMinor cleanup
Comment #3
cweagansIt seems to me that this would be best left to contrib.
Comment #4
gordon CreditAttribution: gordon commentedActually if you take a look at this, the core of this is about 4 lines.
Twig itself is in core, and this is really a small change, also using Twig makes much more sense than using the PHP filter in core.
I already have this as a contrib module for D7 http://drupal.org/sandbox/gordon/1991592 (just waiting on a patch to the entity module)
Also given that Twig allows for controlling flow within the text which no other filter can do except the PHP filter and doesn't have the inherited security issues.
I will not be disappointed it this ends up in contrib, but I feel makes more sense in core.
But this does depend on #1996910: Add context to system filters which I feel is much more important to get into core.
Comment #5
cweagansIt doesn't matter how many lines it is. If you're entering PHP/Twig code from the UI, you're doing it wrong. Period.
Comment #6
gordon CreditAttribution: gordon commentedI agree that PHP should be discouraged, In fact with Twig being avaliable I think that the PHP filter should be removed from core.
Twig is completely secure, and sandboxed, so no matter what a user can do they cannot access anything we do not let them.
Here is an extract from the Twig home page
This is why we chose it for the new templating engine, and I beleive this makes sense to be a filter in core. Give us huge functionality with none of the draw backs that the PHP filter gives us.
Comment #7
cweagansThis is not a matter of security. If you can write code, do it in a code editor and put it in the appropriate place in the filesystem. We absolutely should not make it easy to do it wrong.
Comment #8
gordon CreditAttribution: gordon commentedYou can't always push these things into code, creating complex mail templates is always a pain, or even in modules like rules where you are giving users access to PHP for complex templates output being able to get a middle ground in using Twig will allow for so much, but without being able to kill your site is so much better.
Sometimes doing it in code is just going to take too long esp when you have a major deadline, so having Twig avaliable means you have a good middle ground, the power of PHP without the problems associated with it.
Also I have updated the patch to stop broken Twig syntax from bring down the system.
Comment #9
cweagansThis is exactly the mentality that leads to broken sites. Doing it in the UI may save you time up front, but it usually ends up in more time spent down the road de-crapifying the setup (for instance, wanting to do something more complex than what entering PHP through the UI will let you do).
In this case, you'd only be able to override markup with the context that's passed, which is what templates allow you to do.
So why should we do this when doing the same thing the correct way is like this:
1) Copy base template to theme folder
2) Change markup
3) Clear cache
This is not a difficult or time consuming process, and it certainly doesn't warrant allowing users to enter template code in the UI.
Comment #10
sdboyer CreditAttribution: sdboyer commentedwe've discussed the possibility of writing Twig from the browser a fair bit, and while i'm not categorically opposed to the idea, my concern would be that the user has no insight into what variables are available for use in the template. without that information, the feature is incomplete.
more importantly, though, this is a feature, and the time for those is past. so, moving to 9.x.
Comment #11
gordon CreditAttribution: gordon commentedUpdated version of the patch
Comment #12
jthorson CreditAttribution: jthorson commentedRetriggering patch.
Comment #13
jthorson CreditAttribution: jthorson commentedComment #14
gordon CreditAttribution: gordon commentedUpdated Patch
Comment #15
gordon CreditAttribution: gordon commentedMissed the patch
Comment #16
catchComment #17
joelpittetHead's up I have this started in a sandbox and it may make it's way into twig module.
https://www.drupal.org/sandbox/joelpittet/2612292
Comment #18
mikeker CreditAttribution: mikeker as a volunteer commented@joelpittet's sandbox has made it into the Twig contrib module. See #2388441: Plans for Drupal 8.
Regarding the earlier discussion about code in the UI:
That greatly depends on what you consider "code." Sure, PHP in the UI was a kludgy workaround with all sorts of problems. But we support (even encourage) content editors to write HTML in the node body field, and provide site builders the tools to limit that HTML so that editors don't break layouts or add XSS holes.
Twig provides a limited, sandboxed set of tools for generating HTML. There's no way to touch the DB. Yes, you can include business logic in your display but that's not a security issue, that's a site architecture decision.
Having a Twig text formatter (either in core or contrib, but I would prefer to see it in core) is just another way to allow editors to generate HTML while giving site builders the tools they need to limit that HTML.
Comment #22
joelpittetThis is in https://www.drupal.org/project/twig, likely not going to get into core, if the up take on that module is big, maybe it will get into core one day.