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.

Dries Buytaert, the BDFL of Drupal, has just published a blog post in which he states that “React is the right direction to move for Drupal's administrative interfaces”. A related issue has also been opened on drupal.org.

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.