The PHP version of Pattern Lab has been a trusty tool for a long time, especially for many of us working with Twig and component-based theming for Drupal. However, ever since a decision was made to focus development efforts on Pattern Lab Node, it has been clear that it would eventually become necessary to switch from using the PHP version to using the Node version.

I have been meaning to do this for months now, but finally got round to it after reading swentel's article.

All the great work already done and to be released by the Layout Initiative has inspired me to think about how core’s definition files can be used in component-based theme development. As a result I am now happy to announce two Drupal modules and a Pattern Lab plugin which enable new ways of using core’s definition files.

A quick overview of some things happening with Drupal’s Layout Initiative from the perspective of component-based theming, a theme development approach that has been gaining popularity in the past few years.

Decoupled Drupal has been an increasingly visible topic at Drupal events and on the web for several years now. But what is the percentage of decoupled Drupal sites out of all Drupal sites?

Twice a year the new Drupal upgrade model makes me both excited about new features and worried about the possibility that the sites I maintain will break. I think there are some ways how the upgrade experience could be made better.

After working almost exclusively with the latest and greatest version of Drupal since 2015, I am now facing some Drupal 7 projects. I did not want to give up using atomic design and Pattern Lab, so I decided to create a PHPTemplate (.tpl.php) PatternEngine for Pattern Lab.

When Pattern Lab renders a pattern, it does not by default include the data for any included patterns. There are plugins that can be used to include this data, but the many different ways to include patterns within another and to implement data inheritance can cause confusion.

The recent announcement that Drupal is looking to adopt React has inspired me to live up to my Twitter bio, and be an active advocate for open standards-based technologies.

Drupal needs to adopt a JavaScript framework for its administrative interfaces. The selection of this framework is an important decision, which should not be based on just technical merits or popularity.

As I experienced some issues upgrading to Drupal 8.3, I thought I should be more prepared this time, and tried out the Release Candidate version of Drupal 8.4.

Drupal 8 has a new upgrade model, and the promise is to make upgrades easy forever. The idea behind the upgrade model is great, and has already been proven in other projects like Symfony. However, there might still be some issues that need to be solved, as demonstrated by the recent 8.3 release and the security release that followed it.

A great new Drupal 8 module, UI Patterns by Nuvole, has just been released. UI Patterns can expose stand-alone theme components (patterns) to Drupal and enables them to be used with the core Views module and well-known contrib modules like Field Group, Display Suite and Panels.

Shila theme has been developed for over a year now. I have learned many lessons from it being used on several production websites, and the theme has changed a lot. Here is a recap of the most important changes and the reasons behind them.

Starting right from the Driesnote, it seemed like the topic of theme components was coming up everywhere at DrupalCon New Orleans 2016. Out of all the activity in this area I have been especially interested in two things: presenters and component folders. I think that they are two key pieces required for the next step, which is component projects.

A lot has happened since my first Pattern Lab post in January. The eve of DrupalCon New Orleans 2016 seemed to me like a good time for a summary.

After experimenting with Pattern Lab and Drupal 8 theme development for a while I am starting to see a whole new role for Pattern Lab StarterKits.

In the solutions described in this post I have tried to use the existing extension mechanisms built into Pattern Lab as much as possible, and not to introduce any dependencies to Drupal core. The end result is that Pattern Lab can be used on its own with just the Twig templates, CSS and other assets from a Drupal theme.

When presented with something that almost instantly seems obvious, you don't need much more convincing. For me atomic design was like that. After making the choice to use atomic design and Pattern Lab in a real world Drupal 8 project and seeing the methodology validated, I have wanted to design and build all websites in this way.