Write Up: Twig theme sprint @ DrupalCon Munich

During DrupalCon Munich we had two sessions devoted to Twig.

The first was a high-level session on twig geared towards front-end developers: A designer-friendly theme system in Drupal 8?. The second was a core conversation geared to hearing more from front end developers about what they wanted from the theme layer: A new theme layer for Drupal 8

If you missed either one of these sessions I would recommend watching the videos (links above) to get caught up.

After getting an overwhelming consensus from both the above sessions that Drupal 8 should commit to using Twig for the theme layer, we had a really great sprint on Twig at DrupalCon Munich.

Photo thanks to Amazee Labs

We had one table of engineers working on how to get the twig rendering engine dealing with Render Arrays by turning them into objects, while at the same time trying to merge our working sandbox back in to Drupal 8 HEAD. It would be great if we could get a volunteer who'd be willing to rebase for us once a week or so while we're making progress on the sandbox. If this sounds like it's up your alley, contact me!

We had three full tables of committed front end developers helping us convert the existing template files and theme functions into twig, and at the same time studying the markup produced by core to identify places where theme functions (now template files) could be consolidated.

For anyone who wants to get involved, there are plenty of theme functions that still need to be converted! Please take a look at our spreadsheet and if you see something you'd like to convert, follow our step-by-step instructions on how to convert to twig.

In addition to the four tables of hard-working sprinters, we also had a whiteboard with a crowd of 5 to 15 people chattering about what we should be doing with twig, pretty much all day long (thank you everyone who participated in the debates and made yourselves hoarse!).

We came to some great conclusions about how twig can work with both the existing render and preprocess, paving the path to getting twig working for our first patch.

We also decided where our markup should live in core (a 'templates' directory inside every module that needs to provide it's own markup). Another thing we can write patches against now. (see http://drupal.org/node/1760530)

We also discussed and decided on how we should be using Twig template inheritance in core (we won't use it in core template files, but we can show an example of how it could be done in core themes).

Unfortunately, using twig template inheritance will create an namespace conflict with 'block' meaning one thing in Twig and another in Drupal, which prompts us to change the name of blocks.

On Thursday Aug 30th, at 7:30pm GMT we are all going to meet again in IRC to grab the link to a Google Plus Hangout where we can discuss which template files should be consolidated, and which template files should stay. The idea is to create a more streamlined set of base template files for core, more closely reflecting Jacne's concept of standard components. Please read her blog post before we meet, I immagine we'll start there.

As soon as we make some decisions on which template files to keep and which to throw out, we can start paring down our theme system (with patches against core! This does not need to wait for Twig to get in).

Then we begin writing preprocess functions to handle the variables for the template files that will stay - cleaning up the templates and riding them of unnecessary PHP logic, moving all we can up one level to the preprocess layer.

Another thing we can work on right away (before Twig gets in) is the removal of the process layer. Now that attributes are being handled smartly, we don't need that layer to flatten arrays of classes. We'll also need to move all the stuff that gets done there up to the preprocess layer, and that can be done now with patches agains core (any volunteers?)