The Bearskin 8 theme is built for Drupal 8 to streamline front-end development and add value for clients in the process.
Because Drupal 8 is brand new to everyone, we learn as we go, and implement best practices as they’re created. We’ve covered our bases with the available resources online (drupal.org, blog posts, code forums, internal discussions and code sharing), not to mention attending and presenting sessions at Drupal events.
With new systems, and specifically open source ones, best practices generally evolve rapidly, from experiment to consensus; patch to accepted contribution and solution to standard.
New does not have to be scary. It can also be exciting, and sometimes the hurdle is more about spreading this feeling, especially to clients.
But let’s be honest, Drupal for a front-end developer is far from a joy ride. Markup is barely accessible without knowing your preprocess functions, or by adding contributed modules that will help you do that through the UI. You add more weight to the code base and often have to export settings through features. That’s just the beginning. You see where I am going with this? Configuration management clusters, database synchronisation requirements, code maintainability conflicts across teams, and so on.
The good news is that Drupal 8 enables a front-end developer to separate the theme layer in a way that makes sense, maintaining autonomy while leveraging parts of site building that a front end developer should control.
Hell, we may see the emergence of a new breed of Drupalers. We can call them the Templaters.
Site builders out there: dive into TWIG if you have not done so already! Need convincing? Here are highlights:
How can we be sure that the path to develop Bear Skin was the right one?
We developed our early version of the Bear Skin theme for D8 prior to the official release. For that first attempt, we basically just ported our existing D7 theme layer.
While it worked, we quickly realized that we were not taking advantage of the new configuration under the hood in D8. In parallel we were experiencing difficulties in streamlining our design/wireframe/prototype/development process.
A robust website is composed (or at least should be, by modern standards) of more than 70% reusable components. The code base is smaller and more flexible, because the architecture relies on elements that can be reused throughout instead of being replicated in various contexts.
We had integrated an atomic design approach to our flow and defined our comprehensive hierarchy of the web components we usually use, but we weren’t quite sure how it could effectively translate to a Drupal build. Welcome Pattern Lab! Originally written for mustache, it was quick to be adapted for TWIG and guess what, TWIG is our new friend.
We studied, asked questions, researched, stole, shared, listened and were able to narrow down our conceptions on what was right (for us, that is). Many shops/people developed this concept early on and helped confirm the proper approach, each with their own variations (phase2, Forum One, Aleksi Peebles and John Albin with Zen).
We built a styleguide, defined our atoms, created the templates (TWIG), wrote our styles and eventually told Drupal to use (and reuse) them. It’s not sorcery, and seeing many Drupal shops and developers working in this direction made us feel comfortable investing the time to go further.
This is not only an improvement in output and scalability, but it also respects that this workflow forces us to implement good practices, and Pattern Lab has become our safeguard during the front end planning and implementation.
Here is what our root looks like:
For those familiar with a D8 theme, Bear Skin includes the following:
| |-- 0-Atomic-Design-Plan
| |-- 00-utilities
| |-- 01-atoms
| |-- 02-molecules
| | |-- banner
| | |-- banner-with-page-title
| | |-- blocks
| | |-- comments
| | |-- messages
| | | |-- _messages.scss
| | | |-- messages.json
| | | |-- messages.twig
| | | |-- messages~error.json
| | | |-- messages~warning.json
| | |-- navigation
| |-- 03-organisms
| |-- 04-layouts
| |-- 05-pages
The .twig file is our reusable template. It is going to be picked by pattern lab (Drupal only reads html.twig files).
The .json will add static data with either strings or includes from other patterns.
The .scss file will be the stylesheet for this component (only). Additional .yml or .md files can be added to display different types of information about the pattern.
The additional .json files with the ~ symbol are duplicating the component with different data provided by the json code. This is useful if you don’t want to create many TWIG files that have the same purpose but different data attributes, for instance.
The next step is to include, embed or extend this template on the Drupal side with a .html.twig file, which will get picked up by the Drupal twig engine system. This is also the place to add some Drupal specific data attributes (if needed) or specify which part of the twig component you wish to override.
We place these in the “templates” directory, following the same atomic structure.
| |-- block--main-search.html.twig
| |-- block--system-branding-block.html.twig
| |-- block--system-menu-block.html.twig
| |-- block.html.twig
| |-- breadcrumb.html.twig
| |-- details.html.twig
| |-- form.html.twig
| |-- menu-local-tasks.html.twig
| |-- menu.html.twig
| |-- pager.html.twig
| |-- status-messages.html.twig
Let’s discuss the massive advantages of doing things this way.
Nothing is set in stone and we are likely to see this process evolve further, but these are great improvements over D7 and reasons to get excited about D8 builds. As a team it allows our vision about front end architecture and development to come to life, but also expands it as we keep discovering ways to streamline a shared development environment and offer our clients solutions that fit them best.< /p>
Special thanks to James Cole, Sean Wolfe and Stephanie Semerville for building this along with me. It’s a labor of love that accepts your contributions as well :) Found a bug? send your pull requests over here.
Before joining Zivtech in May 2013, Alban studied jazz and composition in his native France and relocated to Philadelphia in 2005. Soon after, he added web design and development to his portfolio and began specializing in Open Source Software and Drupal, working with private clients and B2B advertising agencies.
View the discussion thread.
Tell us about your project