Drupal Theming

Jest is the defacto standard for testing in modern JavaScript, but until now, we haven't been able to leverage it for testing in Drupal. Thanks to twig-testing-library, that's changed.

Allow sitebuilders to easily add classes onto field elements with the new element_class_formatter module.

In a previous article Using ES6 in your Drupal Components, we discussed writing our javascript using the modern ES6 methods and transpiling down for older browsers. It still used jQuery as an interim step to make the process of refactoring existing components a little easier. But let's go all the way now and pull out jQuery, leaving only modern, vanilla javascript.

Automated accessibility tools are only one part of ensuring a website is accessible, but it is a very simple part that can catch a lot of really easy to fix issues. Issues that when found and corrected early in the development cycle, can go a long way to ensuring they don’t get compounded into much larger issues down the track.

In most of the projects we build, the HTML markup provided by core just gets in the way. There is way too many wrapper divs. This can cause issues when trying to create lean markup that matches what is produced in a generated styleguide.

In this post, I'll introduce you to the concept of bare templates, and how you can remove unnecessary markup from your Twig templates.

When optimising a site for performance, one of the options with the best effort-to-reward ratio is image optimisation. Crunching those images in your Front End workflow is easy, but how about author-uploaded images through the CMS?

With the release of Drupal 8.4.x and its use of ES6 (Ecmascript 2015) in Drupal core we’ve started the task of updating our jQuery plugins/widgets to use the new syntax. This post will cover what we’ve learnt so far and what the benefits are of doing this.

For a long time I’ve been compiling my Sass into a single CSS file - styles.css, but recently, with our component based design/frontend process and Drupal 8’s lovely Library system I’ve been wondering if the single file was still a good idea. Looking at the amount of unused CSS loading into any given page was a little bit painful.

A common problem that I’ve faced, particularly in the last few years, is how to deliver the complex, component driven design that clients want while also giving content authors full flexibility with those components without creating an un-maintainable, or brittle product.

A requirement that comes up from time to time is being able to use content stored in Drupal and produce rich HTML emails. In a lot of cases the design of these emails matches the design of the existing, already implemented front-end website.

In a recent project, we explored ways of creating HTML email’s which wouldn’t require us to start from scratch and would also evolve as the website’s look and feel did. Our design goals were thus:

• Use the existing website’s CSS to skin the emails.
• Use existing Drupal site-building tools to construct the markup for these emails.
• Allow admins to easily create and preview HTML emails.