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.
At PNX, style guide driven development is our bag. It’s what we love: building a living document that provides awesome reference for all our front end components. And Drupal 8, with its use of Twig, complements this methodology perfectly. The ability to create a single component, and then embed that component and its markup throughout a Drupal site in a variety of different ways without having to use any tricks or hacks is a thing of beauty.
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 recent Drupal 8 project of ours had some great requirements around it’s landing pages, aimed at reusing existing components in a range of layouts and combinations. Paragraphs quickly established itself as the site-building tool of choice and Flexbox always wins for me as the CSS grid/layout approach, so we looked at how the two could be combined to give the client the flexibility they needed, without over-complicating the editor experience.
Base themes in Drupal are incredibly useful but often add bloat to the finished sub-theme when care isn’t taken to remove unnecessary css files, or files that are 5% used and 95% overridden. When porting aGov to Drupal 8 we took the opportunity to improve how it’s theme inheritance is managed, making it easier to create trim, lightweight sub-themes.