Used as a single repository, where we keep our base build for all our Drupal 9 sites, Syd holds the basic configuration and setup on every Drupal site we build. In acting as a base theme, Syd ensures we keep everything efficient, standardised and sustainable over the longer term.
There have been a few recent updates to Syd however, so we wanted to talk you through what’s changed.
What’s changing with Syd?
From the perspective of the end user, the functionality of Drupal 8 and Drupal 9 remains the same. Where the big change comes is with Drupal starting to reduce legacy code as it moves towards Drupal 10. I know right. We’ve only just started talking about Drupal 9 and we’re alrady talking about 10. It’s always good to plan. Set to be released in 2022, Drupal 10 is set to have many alterations and new features.
The biggest change with Syd in Drupal 9 therefore is the codebase. Drupal 9 is purely composer-based, meaning there is a composer.json file that lists all the requirements for the codebase. This covers what version of Drupal is being used, to individual modules and their dependencies. It’s pretty much a master list of what the site is running on.
To install everything we need then, we just run a single command - ‘composer install’. This will grab everything required and plonk it where needed. It certainly makes it easier to maintain the codebase and keep track of changes and versions.
What about Twig?
Drupal 9 ships with a newer version of Twig. Twig is the template language used in the themes, but in truth it is more or less the same as Drupal 8 with just a few tweaks and improvements.
For Syd on Drupal 9, we’ve ported over our Drupal 8 version. We have checked everything we use is still supported, changed anything that wasn’t, and generally given it a spring clean.
Has Un.titled done anything to the Drupal base theme?
We are favouring Typescript over Javascript now, which we find gives us more modern and maintainable code.
We have dropped IE11 support completely, and we’ve been using the latest version of Laravel Mix, which will give us a faster and more reliable working environment.
We have also added project-wide linting and code formatting, which basically means everyone is working from the same rule book as opposed to using everyone’s local settings. This means when we save a file, it will auto-format to the ‘house style’. This makes it easier to swap projects and devs and ensure it will all look the same, meaning it will be easier for the team to find their way around.
Anything else?
We are also in the process of handing off more Drupal functionality to standalone React-based apps. This will allow us to leverage the flexibility and better user experience, rather than having to make do with what Drupal gives us.
It’s a step towards going fully headless and for us is a step in the right direction. It gives us wins on short-term projects, as we can replace more and more of the site’s functionality with bespoke React apps.
So for example, features such as ‘What’s ons’ will be using an in-house developed React app going forward. This is much nicer for the end user to manage, and means we are less restricted by what Drupal Views can offer without heavy custom development.
