I’m more than a little late on the traditional DrupalCon recap this year, but even with some time between me and Nashville what I took away is still quite vivid. Better get it in writing before the remaining echoes of country music drown it out.

My most important takeaway from my trip was that the Nashville Predators let fans smash a car painted with the opponents logo before games. Beyond that, I did also learn some things while at DrupalCon.

There is a lot of excitement behind Layout Builder and layout related initiatives

What the Layout Initiative was able to accomplish with the release of Layout Builder as an experimental module in Drupal 8.5 was extremely impressive. It is a great foundation that the initiative already appears to have clear plans to flesh out and improve. It was promising to see many well attended sessions on this topic, coverage in the Driesnote, and quite a bit of excitement about layouts and Layout Builder buzzing through the halls of Music City Center.

The biggest gap I see in what exists thus far is the disconnect between the block based layout builder and the blocks UI. You currently have to leave the layout builder interface to create new custom blocks before you can add them to a layout, and these blocks have the potential to flood the main Drupal custom blocks UI. I was very happy to hear that there is an issue related to inline creation of custom blocks that should help bridge this gap. In a BOF on Components and The Layout Initiative a number of other relevant issues were identified that could potentially improve the experience and make Layout Builder play even more nicely with component based workflows. I’m hoping to follow along with these, go hands on frequently, and help out where I can.

Many are decoupling, but approaches vary

To poorly paraphrase Matt Davis:

Many people build websites this way outside of the Drupal world, they just don’t call it decoupled

There was a lot of great discussion at the Decoupled Summit (Lullabot has a good recap) but also a feeling that while decoupling continues to gain momentum in the Drupal community, there are still a wide variety of strategies and some alignment on best practices yet to come. That said, I think some of that feeling may just come with the territory of the flexibility of an API based approach and the wide array of application frameworks that can consume these APIs.

An interesting topic that came up was the concept of content preview and managing editorial layouts. In the developer case studies portion of the summit we saw a number of attempted solutions to these problems, including an amazing offering from 1XInternet that allowed content managed in Drupal to be edited in either the Drupal or React UI with updates syndicated in near real time. Wow factor aside, conversations later in the summit brought that entire approach into question. The counterpoint being that these editorial conveniences are page-centric in nature and thus won’t always make sense in a truly decoupled context. In this case we’re either putting in a large amount of effort to replicate the traditional coupled website editing experience, or this only represents one portion of the editorial experience we’re trying to manage. It is understandable that we’re often falling back to the page centric approaches we’re familiar with, but this is more evidence that our approaches to decoupling are still maturing.

Discussions during the summit also often crossed into two key initiatives...

The Drupal community is pushing to modernize...

The Javascript Modernization Initiative looks to improve Drupal’s JavaScript by improving the experience of maintaining Drupal’s current JavaScript codebase, and also creating a new alternative admin UI for Drupal based in React. The initiative has already introduced the AirBnB standards and a JavaScript build process to Drupal Core, but there are more welcome changes on the horizon. One focus area is improving Drupal’s JavaScript based test suite by phasing out the use of PhantomJS and transitioning to Nightwatch.js. They are also attempting to manage aspects of the project primarily on Github which I’d imagine would be a welcome change for many JavaScript developers.

Another common theme that kept coming up is that the JS initiative has a small group working on these issues and could really use additional help. This is another area where I’d love to find a way to contribute in the coming months.

In addition to serving as a proof of concept for how Drupal might utilize React, this UI also crosses over nicely with the API-first initiative since the alternative admin UI that is being developed depends on Drupal’s API. The API-first initiative aims to advance Drupal’s web services in support of decoupling and other new types of integration. Closing gaps in Drupal’s API (file upload support was one that came up as a high priority for 8.6) that could support a decoupled admin UI would also make Drupal’s API more suitable for consumers outside of core.

…but there could be more alignment on how we’re approaching modernization

Complete with its admittedly clickbait title, core conversation A Farewell to Twig received the passionate discussion that the session appeared to be aiming for. This early and theoretical discussion focused on the concept of making client rendering a first class citizen in Drupal and potentially focusing more on decoupling rather than solving all aspects of front end development. One possible approach involved enhancing Drupal’s front end to be decoupled out of the box and then offering one or more decoupled front ends that could optionally be used with Drupal. There were various theories on how far this would go - from shipping with a Twig front end by default (a common concern from the audience was related to continuing to support Twig for small to mid range projects, and also for general consistency) all the way to the concept of not shipping with a front end by default.

It was a thought provoking discussion that also sparked some dissonance with the other things I’d been hearing and thinking about throughout the conference. Much of Dries’ focus in his keynote was on improving the content creator and site builder experience, along with promoting Drupal to non-technical decision makers. This aligns nicely with the layout work (which also featured prominently in the keynote,) but it feels at odds with the focus within the community on decoupling. Can both directions be correct? Should both efforts be happening in parallel? Should I just relax and enjoy all of the new functionality and improvements Drupal has to offer? No easy answers here, so I’ll just link to a relevant meme.

Tangentially related, Steve Persch talked about Drupal’s mission statement compared to WordPress' during the What's possible with WordPress 5.0 presentation. Those missions are best summarized as:

Wordpress: Democratize publishing
Drupal: Ambitious Digital Experiences

I’d agree that Drupal’s mission statement isn’t as easy to hang your hat on when compared to WordPress. And does ‘Ambitious Digital Experiences’ really represent what was focused on during the Driesnote? I’m not so sure.

Presenting at DrupalCon was a ton of fun

I also had the pleasure of presenting Hot JAMS(tack): Building a Music Discovery App with Drupal and React. This was my first time speaking at DrupalCon and I had a ton of fun doing so.

Probably my most interesting takeaway from the session was from an informal poll before the recording even started. The vast majority of people in the room either identified as being new to decoupled Drupal, or new to React. In fact, the vast majority was new to both. This seems to confirm my working theory that there are a lot of people interested in decoupled concepts in the Drupal community but are struggling to find a way to get started. I hope this talk provided a decent starting point and inspired some people to dive in and start experimenting.

Thanks to everyone who attended, packed the room, and provided thoughts and feedback.

This was my most social sprint experience

This DrupalCon sprint was different for me in that I spent the majority of my time having some great conversations rather than actively writing code. I finally had a chance to meet Kaleem Clarkson face to face and talk about how he’s been using the Foundation Patterns theme. I also got to meet and have a nice conversation with Murray Woodman talking to him a bit about how I’ve been using the UI Patterns module, along with his work with Bricks and Modifiers. Especially interesting as earlier in the week I had been talking with Scott at HS2 about how he’s been using the Modifiers module.

And I got lunch at the best BBQ place in Nashville (according to one of my many Lyft drivers anyway.)

Kevin!

It was a damn pleasure to be there in person to see Kevin Thull accept the Aaron Winborn award

Looking forward to continuing the momentum

As always, DrupalCon has me energized and ready to run with this Drupal related excitement (although not enough to get this post out quickly for some reason.) I hope to continue speaking at camps, find some ways to contribute to the initiatives that took up most of my focus at DrupalCon, and an episode of the Developing Up podcast that I recorded with Mike Miles at DrupalCon will be released sometime in the future as well.

Other Great Sessions:

• Advanced Configuration Management in Drupal 8
• Keynote: Drupal and the secret of my success | Steve Francia
• Site Building 2.0: How Layout Builder will change everything
• Introduction to React Design Patterns

Sessions I’m Still Hoping to Watch:

• Build banging sites with BPM: Bricks, Paragraphs and Modifiers
• Advanced topics in decoupled Drupal
• Next Level Twig: Extensions
• Shifting UX to the Editorial Experience
• JavaScript and Accessibility: Don't Blame the Language
• Weather.com's Project Moonracer - Decoupled User Interfaces

See you in Seattle!

This pretty much sums up my DrupalCon Nashville experience. Thanks to Chris Greatens for the goofy photo.

Very much looking forward to spending next week in Nashville attending my 4th DrupalCon. The spontaneous and unplanned stuff is half of the fun, but there are a few things that are locked on my schedule.

Monday: Decoupled Summit - I'm excited to hear more about what people are doing in the decoupled Drupal space. This will be my first time attending a summit at DrupalCon as well.

Tuesday 1 PM: Components and the Layout Initiative BOF - I'll be leading an open discussion on how the Layout Initiative might impact our component-based workflows. I've really enjoyed the BOFs I've led in the past and expect this to be no exception.

Wednesday 3:45 PM: Hot JAMS(tack): Building a Music Discovery App with Drupal and React - I'll be sharing my experience building a music discovery app with Drupal and React in my first ever talk at DrupalCon.

Thursday: Who knows!

Friday: Sprints - after a week of exciting new ideas, having a sprint to go hands on is a great way to end the week. I plan on getting back to some forward progress on the Foundation Patterns theme.

Can't wait to say see friends old and new, learn a bunch of cool new stuff, and land a country music recording contract.

As always, I learned a few things this week upgrading projects to Drupal 8.5 and applying the most recent highly critical Drupal security update.

The first is yet another reminder to carefully read and consider the documentation. The highest priority projects that I needed to apply the security release to were on 8.4.5 at the time of the pre-announcement. I took this as a good opportunity to upgrade to 8.5 and then kind of got tunnel vision about getting these projects, and also my lower priority D8 projects up to 8.5 in preparation for the security release. Not having looked back at the security advisory since my initial read, I lost sight of the fact that I could easily apply the patch to their current D8 version and worry about 8.5 when the pressure was off a little bit. Thankfully I was reminded of this during a well timed check in meeting with the Drupal practice at HS2 - a few of my 8.5 upgrades were a little behind schedule. Having the flexibility to apply the security update to older versions of D8 really helped and most likely prevented us from rushing a few upgrade related regressions out into production.

Speaking of the 8.5 upgrade getting a bit behind schedule, minor Drupal updates (8.4, 8.5 and so on) are still more challenging than I'd expect them to be. Jeff Geerling's post Updating drupal/core with Composer - but Drupal core doesn't update proved invaluable as I ran into the same issue. I also had another pretty tricky dependency conflict that eventually required me to remove and work around a dependency (again, Jeff Geerling's post helped quite a bit here.) After successfully upgrading to 8.5 composer-wise, I found that a patch to Page Manager needed to be applied for the site to even run.

I'm getting better with managing Drupal projects via composer, but still have some room to grow. Lowest hanging fruit is that I need to start managing patches via composer. Once that clicked in my brain it was a little to late to experiment with it. Next time. I also still sometimes get tripped up with the difference between the ^ and ~ version constraints in composer.json which is embarrassing to admit.

I also ran updates on Drupal instances based on API-first distributions. Those were a bit of a different beast. In my case, most were single purpose enough that I was able to just run composer update and call it a day. That said, each distro had their quirks. The version of Reservoir I was using had a dependency conflict that prevented the upgrade until I manually locked Reservoir at Alpha 4. Contenta seems to have a patch that won't apply to 8.5

I'm all for learning, but also looking forward to this process becoming smoother sailing in the future.

A great listen that could serve as a solid introduction to the JAM Stack concept. Especially interesting was the focus on some common counter arguments to the JAM Stack (dynamic things like forms, comments and so on) and how those may be more achievable than one might originally assume. As I try to add a little more punch to the JAM Stack focused portion of my DrupalCon talk I see myself going back for another listen.

With a new critical Drupal security release on the horizon, static site builds are looking better and better. I'm glad I won't have to won't have to worry about this site (Drupal isn't accessible to the public) while I scramble to apply the security release elsewhere.