Twigging Out at DrupalCon Portland
I spent most of this year's DrupalCon in the CoderLounge sharing tables with up to 20 other volunteer contributors profiling Twig. We were making sure Twig could be merged into Drupal 8 without slowing it down. By Friday I had only managed to get a simple documentation patch committed, but I learned a lot about the contribution process, made some friends, and had a great time!
I arrived in Portland after a 16 hour flight from Australia and straight away ran into Drupal 8’s mobile initiative and Zen Theme creator John Albin Wilkins at Starbucks. I joined him on the railcar to Portland’s city center and took the opportunity to ask a ton of Drupal related front-end questions.
Curious about what he thought about the status of Twig, I brought up some rumors I heard suggesting that Twig wouldn’t make it into core. He hinted that Twig would make it but that it still needed a lot of work. The mobile initiative was not quite as important as working on Twig. So I guess if I wanted to help with something, Twig was going to be a priority while I was in town.
We continued to discuss other areas that sparked my interest, like CSS. I asked what CSS would look like in Drupal 8. John explained that styles would be pulled out of their respective modules in core and placed in their own folder where display-oriented CSS would prevent repetition. Drupal 8 would also follow a more SMACSS approach. I also learned later in the week that John had a meeting with the creator of SMACSS, Jonathon Snook to talk about a new book titled, “SMACSS for Drupal” or something of the sort.
When I asked John about grid-systems, it seemed as though he preferred Zen-Grids (he is the creator!) to Susy, but liked the way Singularity deals with asymmetrical grids.
Twigging Out
Check-in wasn't for another 4 hours, so I made my way with John straight to Acquia’s offices where a pre-conference sprint was taking place. I was able to briefly meet some of the higher-profile Drupal contributors there but soon found myself in a small conference room tucked behind rows of cubicles where the Twig sprinters had gathered. I was greeted by Scott and Joel (D.O name “Cottser” and "joelpittet" respectively), who was a huge help in getting everyone set up. Thanks guys!
Scott explained that there was not many template conversions left to do but performance concerns still lingered. We needed to address those before Twig could be merged into core. The best way to measure how well a patch to core performs is through a process called profiling. This is where all back-end functions needed to render a page are measured so bottlenecks in performance can be discovered. The profiling process is painstaking but not particularly complex when the steps are followed properly. So it made sense to teach people how to profile so that they could follow the slow-going steps to could reproduce the appropriate test scenarios it takes to accurately profile a patch.
The first two days of 'sprinting' for me was more 'squinting' as I tried to set up my system. Installing the newly pulled Drupal 8 forced me to update my version of MAMP in order to have a newer version of PHP that Drupal required. Installing the required tools meant following a long list of instructions that would change as the other members on the team experienced different issues and quickly updated the instructions on D.O. However, everything became much clearer when fabianX, a soft-spoken profiling and Twig specialist, flew in the next day and started whipping everyone into shape. It is crazy when someone with that much skill comes into a room and becomes the de facto source of information; everyone patiently waits for him to come around the room and help solve their problems. It seems like if it wasn’t for him, we might not have merged Twig into core before the end of the conference, which seemed like everyone’s unspoken goal.
Profiling was processor intensive, the scenarios were sometimes tricky to reproduce, and the profiling results hard to decipher. Not everyone's machines were the same, so results would vary. However, through the process of benchmarking* we could compare how the latest version Drupal 8.x performed against the branch modified for Twig. The process involved installing a tool called xhprof and another tool built by fabianx, called xhprof-kit.
Benchmarking: The act of running a set of operations in order to assess the relative performance of an object, normally by running a number of standard tests and trials against it.
The kit would be used to compare wall-time, processor output, and a few other variables that I didn’t quite understand between the 8.x version of Drupal 8 and the branch with the new templating system. Once accurate results were in, we would paste what we got into the the issue's comments and someone with more experience would interpret what was found. Getting accurate results however required a lot of boxes to be checked, including proper caching (APC, Drupal) and that our computer that was 'primed' (after running profiling command a few times). We also had to make sure no other programs running and a whole other box of worms were squiggling.
Before we could determine that there was a real problem with a patch, many profile instances needed to be run on different machines, keeping track of all these was difficult in the Drupal issue queue. fabianx created his own API that saved and analyzed Drupal 8 profile results. Those of us that were were successful in setting up the profiling framework were issued an API key that we could use to push our results to. This way profiling data could be more easily accessed in the future.
While rewarding, the profiling process was quite complicated and some front-enders refused to take part in the process. MortenDK was looking forward to a Dream Markupsession after the new twig templates were committed to core. “I am a front-ender! I don’t do any of this profiling SH*#," he at one point interrupted after his Angry Themer session, "more backenders need to make twig preform better, then us markup geeks will make the HTML and CSS beautiful!” Maybe Morten had a point because I definitely felt like I would have had a bigger impact with some sitebuilding and markup tasks. I am happy though that I challenged myself with the profiling and got to experience the process of merging a major feature into an active open source project as large as Drupal.
Having Twig in Drupal 7 will make theming much easier for those new to Drupal, but what about porting Twig to Drupal 7? A BOF I attended on the last day of DrupalCon addressed exactly that. Twigify is a tool for assisting with the conversion of Drupal themes and modules into Twig and those in attendence were quite impressed about using Twigify to help those still using Drupal 7's PHPtemplate, use Twig. That was confusing.
The finale of my Drupal Twig adventure came at the largest Drupalcon session I have ever attended. In front of what had to be more than 500 people, JenLampton, fabianx, and JohnAlbin updated the community on the status of Twig and finished to room of applause as they announced that Twig would make it into Drupal core.
If you are interested in the helping with Twig or want more details on its status in core this blog posted a few days ago by fabianx is a must-read.
Sessions and Bofs
“We are doing OOP wrong”, Mark Sonnenbaum - This session just made me feel dumb. The PreviousNext backenders found it enlightening though.
“Assetic”, Sam Boyer - This session focused on handling front-end assets like javascript, sass, and image optimization with a PHP-based Symphony tool similar to Ruby’s asset pipeline called Assetic that will be included in Drupal core. - Assetic is needed to help with the completion of the SCOTCH initiative, aka blocks in core. - Asseic will replace drupal_add_js and drupal_add_css so we can use compiled languages like CoffeeScript and Sass using binary filters. - Drupal 7 JS weight system is bad, Assetic will replace D7’s integer weight with a dependency model that will allow scripts to be placed at the bottom or head of the document using a more flexible approach.
“Modernizr”, Ruple - The Modernizr module does a lot of cool things for you good. A stub is being included in Drupal core.
“Breakpoint”, Snugug and Mason Wendell - This session focussed on using the Breakpoint module and SingularityGS to create awesome responsive websites. The session covered a bunch of reasons why you should use these tools, which the speakers wrote. I concur, and I have promoted these tools in the past myself.
BOFs - I attended a BOF on the “Magic Module” because I am a fan of Snugug's work and I wanted to meet him in person and ask some more complex frontend questions. Snugug, the creator of the Aurora theme invited all of Drupal’s main theme developers together to talk about how they can consolidate some of the themes’ common PHP/JS magic stuff into a common module, that module being his ‘Magic’ module. The BOF was attended by JohnAlbin (Zen), MortenDK (Mothership), Rupple (Modernizr), and more. It ended up just being a general front-end discussion rather than a discussion solely based around the module, which I still need to evaluate as a possible addition to our workflow.