Looking Forward to Drupal 8: Twig


The next major version of Drupal is in the works, and it’s shaping up to be one of the most substantial changes to date. With so many new features, there’s something for everyone to be excited about. As a front-end developer and Drupal themer, it probably goes without saying that the feature I’m looking forward to the most is the inclusion of the Twig templating system.

Why I'm Excited: Consistency

Currently, Drupal’s front-end is powered by the PHPTemplate theme engine. Templating is broken out into two categories; template files, which are a mix of HTML (for structure) and PHP (for content and minimal logic), and theme functions which is straight PHP that returns an HTML string.

And here is the first problem, two methods for creating our site’s markup and no real rules as to when to use one method over the other. To further complicate things, there’s a lack of consistency on how the dynamic bits are added to the templates/functions. Sometimes you can just print a variable, [prism:php][/prism:php], and sometimes you pass elements into the Drupal render() function, [prism:php][/prism:php].

All these variations make getting desired markup very difficult, especially for new web designers or front-end developers whose focus should be on semantic markup. Instead, newcomers are met with a steep learning curve and mysterious, inaccessible markup. Twig aims to fix this in a couple ways.

Death to Theme Functions

With Twig, all theme functions are being converted to Twig template files. The idea is simple, if you want to change a piece of markup you find it’s template, copy it to your theme and override it. No more copying and pasting massive PHP functions into template.php and wading through the (sometimes heavy) logic happening there.

One Syntax to Rule Them All

Twig uses double curly braces to print dynamic content. Instead of [prism:php][/prism:php], you’ll write [prism:php]{{ page_title }}[/prism:php]. Want to do different things with your HTML IDs vs classes? Before, you’d have something like [prism:markup]

nid; ?>” class=””>[/prism:markup]. When is my content an object? When is it an array? With Twig, it won’t matter. Instead you’ll just use the dot syntax: [prism:markup]
[/prism:markup]. It doesn’t matter how your data is structured, your syntax will be the same for everything.


Of course, you’ll still need some logic, conditionals and loops. And you can do that with the syntax:

[prism:php] {% if page_title %}

Why I'm Excited: Separation

On top of the templates and theme functions, Drupal has a preprocess layer that allows developers to alter the data before it gets rendered. The idea is that you have separation between business logic and structure.

The problem is that there is nothing enforcing this. Because both templates and theme functions are nothing but PHP, there’s nothing keeping large amounts of logic (or worse, actual database queries) out of the presentation layer. On top of many security concerns that others are way more qualified to talk about, we’ve made already complex templates even more so.

Twig templates aren’t PHP, and because of that you can’t write PHP in them. You’ll still have the preprocess layer (or some semblance of it) to handle your logic and alterations. However, now there is more than just the honor system keeping that logic where it belongs.

A Whole New World

There’s much more to the move to Twig than I’ve covered in this short article, and the full integration is still being worked on. Things are changing every day, so there’s a lot to stay on top of. But all of the possibilities that Twig offers, and the lower barrier to entry make this the feature I’m most excited about.