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.
Very good point @Fabianx! Even though our current render system always returns safe markup, it might not be always the case if someone is using custom renderer / modified twig extension. Better to be safe than sorry!
I looked at this patch very carefully, and this looks like a fancy way to do a Twig include, right?
Exactly! This way we can get the best parts of the theme system in use; such as documented variables in the theme hooks, preprocess functions for actual data preprocessing and a way to do overrides in child themes. Maybe in future even modules could work the same way so that they provide components and you could just override a component inside your theme. And if you need to change something on the data, you would also override the connector template.
Include would be faster if you don't need those Drupal-specific features.
Most people don't have to care about most of Drupal's features even though they are available. This would be just a way to scale this model to become slightly more flexible so that we could potentially introduce this workflow in core!
Another question, the theme looks similar to twigs include, but wouldn't it then also make sense to have one that works similar to twigs embed, so that we can override twig blocks within the embed?
The theme() function returns a render array because core already renders array printed with {{ }}. And we can now apply filters to the raw render array (including the render filter if you really want a string). See #3082816: Make theme() function return render array
Comments
Comment #2
lauriiiComment #3
lauriiiThe syntax to try this is:
Comment #4
joelpittetThis is awesome and RTBC other than these nitpicks
\n after namespace.
single quotes
/false/FALSE/ and /null/NULL/
short array
Probably don't need this feature now.
missing single quote after 'items'
Comment #5
lauriiiThanks for the review @joelpittet!
Comment #6
Fabianx CreditAttribution: Fabianx as a volunteer and at Tag1 Consulting commentedIt might be better to use a Twig_Node_Print unless we are 100% sure that we do not want to pass this through auto-escape, which might be true.
Nice work! - Looks great!
Comment #7
lauriiiVery good point @Fabianx! Even though our current render system always returns safe markup, it might not be always the case if someone is using custom renderer / modified twig extension. Better to be safe than sorry!
Comment #8
Fabianx CreditAttribution: Fabianx as a volunteer and at Tag1 Consulting commentedRTBC - Looks good to me then! :)
Comment #10
JohnAlbinI looked at this patch very carefully, and this looks like a fancy way to do a Twig include, right?
In vanilla Twig, you can use a theme hook's template with:
But you can't use a Drupal theme hook suggestion (e.g.
item_list__node
) and none of the preprocess hooks or template suggestion hooks are called.Using a suggestion in
theme
would work, right?Are there any other reasons to use theme over include? Include would be faster if you don't need those Drupal-specific features.
We need some docs.
And we need some tests!
But I've committed this patch in the meantime. Really good work!
Comment #11
JohnAlbinComment #12
lauriiiThank you for the commit @JohnAlbin!
Exactly! This way we can get the best parts of the theme system in use; such as documented variables in the theme hooks, preprocess functions for actual data preprocessing and a way to do overrides in child themes. Maybe in future even modules could work the same way so that they provide components and you could just override a component inside your theme. And if you need to change something on the data, you would also override the connector template.
Most people don't have to care about most of Drupal's features even though they are available. This would be just a way to scale this model to become slightly more flexible so that we could potentially introduce this workflow in core!
I agree with both!
Comment #13
kevinquillen CreditAttribution: kevinquillen at Velir commentedWhats the status on this patch? I think still allowing for override while supporting
include
like functionality is a great addition.Comment #14
dionsjWould using the
theme
call, does it also retain the caching metadata (from #cache render array)?The reason I ask is that we've recently started encountering this issue:
Allow explicit bubbling of cacheability metadata inside Twig template (when accessing data from instead of rendering render arrays)
Another question, the
theme
looks similar to twigsinclude
, but wouldn't it then also make sense to have one that works similar to twigsembed
, so that we can override twig blocks within the embed?Comment #15
JohnAlbinComment #16
JohnAlbinI'm thinking of changing how the
theme()
function works. (Not how the theme tag works.)#3082816: Make theme() function return render array could use some reviews.
Comment #17
JohnAlbinI created a bunch of child issues with justifications for each change I wanted to make to this work. They are all completed now.
{{ }}
. And we can now apply filters to the raw render array (including the render filter if you really want a string). See #3082816: Make theme() function return render arrayThis is how the function works now:
With Twig's new named arguments, you could also call that function like this:
Or like this:
I also kick-started the discussion in the core issue today by posting a patch, so if we want to discuss implementation details, it's probably best to do that there: #2818121: Create alternative to Twig include function to improve Drupal integration
Comment #18
JohnAlbinComment #19
JohnAlbinUpdated title to match core issue.
Comment #20
JohnAlbinWith #3091827: Use variadic arguments for template function and #3091775: Rename theme Twig function to be called 'template()', the latest version of this is now:
The
template()
function also accepts as its first argument:"item-list"
or"item_list"
or"item_list__node"
.Comment #21
Fabianx CreditAttribution: Fabianx as a volunteer and at Tag1 Consulting commentedI think this can be closed now again or is there more to do?
Comment #22
JohnAlbinThis function is now documented at https://www.drupal.org/docs/contributed-modules/components/twig-function...