TWIG is termed a ‘templating engine’. For an overview watch “Intro to twig templates”. A templating engine is a fancy way of saying something needs to paint your PHP variable from within Drupal to the HTML that browsers understand. TWIG actually allows HTML to be used directly in its templates. Plus, it reads the variables from your Drupal PHP code and spits it back out as HTML. Easiest way to see this is to look at a VSCode IDE editor extension which shows the TWIG template on the left pane and the resulting HTML in the right pane (if you are if a rush about 27 seconds in). Don’t automatically take the visual showing this comparison as the best tool for working with TWIG templates in your front-end work; there are many options There is an ‘xdebug’ extension that can be added to your VSCode Integrated Development Environment.
Drupal themes have TWIG Templates. If you want to change something in the way your current theme displays something on your website you can, in a lot of cases, create a custom subtheme
Overriding is done all over Drupal as the way that makes it so flexible. Drupal is a super CMS out of the box but the fact you can override all sorts of stuff makes it the best CMS out there to service a huge range of applications. The TWIG template override is a first line of flexibility.
ARMTEC, Inc. documentation includes a section on Continuous Integration/Continuous Deployment (CI/CD) Workflow and if you use that base, this key step is already established. However, one of the really important things you need to know is that when you are building a sub-theme, it is pretty common that you copy but rename one of the parent theme’s TWIG templates to handle some specific page or content type need unique to your own site. But you also need to worry about how the heck Drupal will know about this customized or edited template. The way this happens is that you use naming suggestions which Drupal offers up if you turn on theme debugging. Here is a video overview of theme debugging and it also shows how to disable the ‘cache’ so you don’t need to keep doing this manually as you work on your website. Note that ARMTEC, Inc.’s CI/CD Workflow process already does this and much more; so it is obviously the recommended way to go. Either way, clear your cache and when you ‘inspect source’ on any page on your Drupal site you will find a list of the TWIG file that is active (has a + sign in front) PLUS some suggested names of an ‘override’ file if you want to target your edit rather than fully replace it everywhere that template may be used.
One of the other things you may need to know to edit this TWIG template copy you have in your sub-theme is what variables it has from your Drupal system available to it. For the most part people who build solid base themes that you might copy have already done a very good job of indicating this in the documentation right in the TWIG template itself. So your first stop is just to read that. If your underlying website added modules which might have made other variables potentially available for your use in a template, there are additional method available to discover and inspect variable available to the TWIG templates.
TWIG was added to Drupal for both a security benefit of isolation from direct PHP and for its comparative simplicity. As noted, TWIG is going to grab information from the database and PHP with an aim to render it in HTML. Plus, if you look at a TWIG template you will see a whole bunch of it is extremely similar to HTML itself; easing use by those already familiar with front-end website code. TWIG basically adds only three basic things with this syntax:
By the way, if you notice in the first line showing a variable that there is a capital letter in the second part; this is known as CamelCase. This is a common style of nomenclature used with TWIG. Don’t get overly wrought over it. It is just a fancy way to make variables with longer, and thus unique, names easier to read.
If you have a little time, From .tpl to .twig a beginners guide to bringing designs to life with Drupal does a nice job of showing how the basic syntax translates into the use of the various variables and logic commands to talke you to an understanding of how things fit together. That video is also a good source for someone who might have used Drupal in some of the earlier versions that used .tpl template files before TWIG to quickly get an understanding of the differences and similarities.
Lets put the use of TWIG in easy context with how you first get the basics set up with the Drupal GUI where you have set up a new content type. Once you have down those basics, you are probably ready to turn to more advanced edits of your TWIG templates, especially the various ‘logic’ options. After you view that video and start to feel comfortable, you might try practicing TWIG editing online to see how you are doing.
We discussed earlier discovering the available variables. In addition to grabbing those variables you will want to learn the basics of applying code logic to them. Then Selwyn Polit’s online Drupal book is a good reference to work with TWIG code. You can also go to the source by reviewing TWIG for Template Designers right on the Symfony documentation site.
Some people who are developers experienced in the templating approach before TWIG feel like they gave up some power with its adoption by Drupal in version 8 forward and want to leverage approaches to TWIG extensions. One of those approaches is a contributed module called TWIG Tweak..
composer require drupal/twig_tweak
drush en twig_tweak
TWIG Tweak adds access to additional variables that might not be shown in the documentation in the templates you got from your parent theme; perhaps some global system variables you want to use. It also offers you some additional controls of TWIG code logic you might apply. A first peek at the use of TWIG Tweak might be to use it to place a ‘block’ in a TWIG template. TWIG Tweak exposes a number of additional functions and filters that add power to what your templates can accomplish . See a demonstration of using TWIG Tweak to deploy some functions and filters. If you prefer written material here is something to get you started with Twig Tweak
Twig Tweak Cheatsheet offers you a quick reminder to turn to as you work.
Once you are past the faint at heart stage doing minor things to some of the templates you have copied from your base theme, pasted in your custom theme, and renamed to your unique use, you might want to take on something a little more challenging to really get a feel for working with TWIG editing, nodes and views you have created in your Drupal project, and move to the next level. Here is an example of Nodes, Views, and Layout actions you can take in TWIG.
For convenient use in following along with the recommended steps in the video,
the code blocks below are provided. You run these from your terminal CLI. This first block will add more ‘context specific’ alternative template suggestions for the node twig template being customized.
<?php
function mytheme_theme_suggestions_page_alter(array &$suggestions, array $variables) {
// Add very specific content type suggestions
if (\Drupal::routeMatch()->getRouteName()== 'entity.mode.canonical') {
$node = \Drupal::routeMatch()->getParameter( parameter_name: 'node');
array_splice( &input: $suggestions, offset: 1, length: 0, replacement: 'page_node' . $node->getType());
}
}
Run this code block which invokes ‘view’ such that any variable we add, like our node with hero content, it is rendered as just part of the normal display process.
/**
* Implements hook_preprocess_page() for PAGE document templates.
*/
function simple_preprocess_page(&$variables) {
if (!empty($variables['node'])) {
$node = $variables['node'];
$her_content = $node->get('field_landing_hero')->view();
if (!empty($hero_content)) {
$variables['hero_content'] = $hero_content;
}
}
}
The context specific template being added is named:
node--landing-page--full.html.twig
You need to use this ‘preprocess code’ to attach the article list to that node template.
// Add the article list to the landing page node template.
function simple_preprocess_node(&$variables) {
$node = $variables['node'];|
if($node->getType() == 'landing_page') {
$item = $node->get('field_page_temp')->getValue();
$tid = $item[0]['target_id'];
$variables['content']['article_list'] = views_embed_view(name: 'landing_page_articles', display_id 'embed_1, $tid;)
}
}
Hope you enjoyed this more advanced example and want to learn more about data processing concepts in drupal theming .
If you are really ready to jump in the deep end and want to Demystifying Rendered Content in Drupal Twig Files your brain might hurt but you can get there!