Here's a quick and scrappy video I put together to demonstrate how we can use a base theme for our LocalGov Drupal Microsites, and then subthemes of that base theme for custom overrides.

Code Contributions

1. We have had a number of councils ask for LocalGov Guides to be added to the Microsites Platform. I now have a PR to add the LocalGov Guides module to Microsites. And then a second PR to configure LocalGov Guides to work with microsites - this is done via a submodule in the LocalGov Microsites Group module.
2. And after that, I did the same for Step-by-Step content types.
3. And after that, I did the same for Publications content types.
4. But that threw up an issue whereby we can't install Publications in Microsites because it has a dependency on LocalGov Services, which doesn't exist in Microsites. So I fixed it.
5. In our efforts to make our LGD sites more and more (and more and more) accessible, we have a proposal to add the Drupal Editoria11y module to our CMS. I have a new "LocalGov Editoria11y" module created and added to Drupal.org which downloads the Editorially module and configures the permissions for it. I have a second PR to add this new module to our LocalGov Drupal.
6. Last month I was working on some editor experience issues. One of the PRs I created was to change the "Description" tab for LocalGov Services to "Content". When complete, our tests showed that we have lots of failing tests in LocalGov Services, especially JavaScript and CSS coding standards. Great, says I to myself, that's an easy fix. But then ... I ended up needing to rewrite all the JS for LocalGov Services to remove the jQuery and use ES6+ JS instead, and then fix the coding standards. But it's great to have these larger refactors done now, or else we'll have to do them later.
7. And then I sorted all the coding standards issues with the CSS for LocalGov Services. So now we're a few steps closer to getting our automated tests to pass.
8. Maria noticed an inconsistency with our prev/next component not rendering the node titles for Step-by-Step navigation. So I created a PR to fix that.
9. I created an issue about a year ago to allow some CSS variables to be set via the theme settings page for our themes. I finally got around to working on this and now have a PR ready for accent colour, line height, and base spacing. Then I took it one step further and extended the Colour Picker Fields module we have for microsites, so now we have a generic module for that. And then I went a step further and created the LocalGov Base feature as a submodule, so you can decide for example to not turn it on for microsites. And then I went a step even further to propose microsites should start using the more generic module as its base. And then my brain went all a bit mushy!!!
10. When my head stopped being mushy, I had the bright idea to add a textarea to the theme settings so that we could add arbitrary CSS to a theme. I hope no one ships this CSS to production, but it might be handy during dev, especially in the year days before you have a sub-theme created. Here's the PR, get the popcorn!
11. Last month we released a new feature to use the name of the document instead of the file name when embedding documents via media. This through up an issue with files uploaded via webform, which Andy fixed, but then it through up another issue with files added via node file fields, which I fixed.
12. That last (node) issue was noticed when working on the Irish Planning Notices module. We also noticed that the default year for planning notices is set to 2023, so I created a PR to increase that to 2025.
13. Then I thought, why not create a view to list each year up to 2030. So I created a PR for that.
14. The LocalGov Replicate module is ready for a 1.0.0. release (and thus security team coverage), but is just waiting on an updated README. It now has an updated README. And it now has a 1.0.0 release!

August is a little quiet for meetings in LocalGov Drupal land. We close up all the meetings except Merge Tuesday while lots of people are away on holidays. On the flip side, that gives me a bit more time to write some code.

Meetings

1. Merge Tuesdays: The big story from Merge Tuesdays this month was the release of 3.0.0 of LocalGov Microsites Base, with all the goodness of the new grid system from LocalGov Base.

Code Contributions

1. Reviewing a simple PR that becomes a headache: basically what prop type is an attribute in Drupal.
2. We all (or at least lots of us) use and love DDEV. I created a web component a few months ago to display a banner on any website with the DDEV sponsor Call to Action. The DDEV folk have updated their API so they sponsor amount can now be dynamically created in the web component and asked me to update the web component. So now if they update their requested sponsor amount, anyone using the web component to display the banner will also get the new update automatically. Not exactly LGD, but definitely a tool a lot of us LGD developers use.
3. What looks like it might be a tricky issue often turns out simple. We are no longer printing empty h4 tags for facets if there is no facet title.
4. I tried to focus on Microsites as much as possible this month, starting off with a tricky issue we have with the new grid system vs the alignment of blocks in the footer. I think I might have a fix for it now.
5. I'm very surprised no one has noticed until now, but if you click anywhere on a page on mobile for our microsites, then the focus is immediately set to the 'Menu' button. It was only noticed when Dan tried to click on an input for directories. I have a PR ready for it now.
6. I created/updated a PR so we have a better aria-label for facet blocks for Directory Channels on Microsites. But ...
7. Then I had the idea that it would be good to apply this to all LocalGov Drupal sites, so I created an issue to apply it to LocalGov Base and also a PR to go with it.
8. There is an open issue for a very tricky bug/feature (not sure which) that we have, in that we have a CSS class called .padding-horizontally which was added liberally to templates so that content would not bump up against the side of a page. However, this class means some things have more padding than others when you have nested templates. Christopher and me have started a major PR to fix this (and add some extra features to a new component we are creating called 'Section') so we can stipulate if it's a bleed component, or constrained component, etc. Hopefully we'll get this finished in the next few weeks and release it as part of a new major version of LocalGov Base.
9. Another item that's been a bit frustrating is our original JavaScript for the Step-by-Step components, which doesn't fully follow Drupal best-practices (e.g. text strings are not translatable, it's using jQuery, etc). We started some discussions about, then Christopher wrote a PR for it, and I got it tested and approved. Team Work!
10. I got some nice work done on the Modules List module, which will become part of the LocalGov Drupal Telemetry suite. Two items I fixed and released were updating the code to follow Drupal's coding standards, and changing the path from admin/modules/overview to admin/modules/modules-list.
11. Following that, I created an issue to add a submodule for Modules List module to list some system information such as Drupal version, PHP version, Database type, etc. I have that ready now in a merge request but don't want to merge it until we chat about it at a Tech Group Drop-in. I'm unsure if it should be a submodule (it doesn't really have anything to do with modules list) or a standalone module or perhaps it's a security issue and should not be a module at all! So many questions.
12. Fixed two tiny issues with the Scarfolk theme. Those kinds of issues that are hanging around for ages, but are so simple no one wants to look at them.
13. For the LocalGov Replicate module, we check the route name of that current route and then change the word 'Replicate' to 'Clone'. This becomes inefficient since we don't know what modules/routes may be added in the future to a site. So now I have it fixed to check for any route that begins with entity.node..
14. Following on from this, Replicate module dropdown operations button on admin/content uses 'Replicate' as it's string instead of 'Clone'. But not any more.
15. And then I had a major item to check with the LocalGov Replicate module: does it work with microsites? Answer = no. So I wrote a localgov_replicate_microsites submodule to fix that. We now have an RC1 release for the LocalGov Replicate and will hopefully have a 1.0.0 full release next week.
16. As part of our 'Editor Experience' mission, we want to start standardising the names of our tabs when editing content. I not have PRs open for the first tab in each content type to be 'Content' instead of the current jumble of 'Content', 'Details', 'Description', etc.
17. Another part of our 'Editor Experience' missing is being able to add names to our documents, so that when they are displayed on the screen to users it will read something like this: My File (PDF, 2MB), instead of like this currently: my-file.pdf (PDF, 2MB). I've opened two PRs to sort this (1 and 2) and also a follow-up PR to make things even better.
18. The Blogs Module is one that gets a little left aside (I think), as I don't know if many people even know it's there. So I did a good triage of the issues and nominated myself as a maintainer.
19. Another 'Editor Experience' item we have is to change the listing at admin/content so it lists the last person to update a piece of content rather than the owner of the content, and then also be able to filter by that criteria. I created a PR for most of that, but can't figure out how to filter by the username of the last person to update the content (I can only figure out how to filter by their user ID).
20. Since our "newsroom" field on the news article content type is a required field, we print a message reminding editors "Hey, you need to create a newsroom first", but if a council sets that field as not required, the message is still printed. I created a PR to only show the message if the field is required, but also to hide the field if there are no newsrooms available and the field is not required.

Online Course: Build a LocalGov Drupal Website

Did I mention I have a course coming out soon called "Build a LocalGov Drupal Website"? Why not sign up for updates about the course - and perhaps get a discount code when it's released.

I spent some time over the past few weeks writing up a 10-part blog series of Drupal training topics (with some LocalGov Drupal-specific topics in the mix too).

To make it easy to find your way around them, here's a Table Of Contents:

1. Drupal Training 1: Local Development Environment
2. Drupal training 2: Drupal concepts
3. Drupal training 3: Site building
4. Drupal training 4: Extending Drupal with Modules
5. Drupal training 5: Theming Drupal
6. Drupal Training 6: LocalGov Drupal features out of the box
7. Drupal Training 7: LocalGov Drupal extra features
8. Drupal Training 8: LocalGov Drupal Theme System
9. Drupal Training 9: LocalGov Drupal Microsites Platform
10. Drupal Training 10: Deployments and Backups

The list isn't exhaustive, but if you are thinking of contracting someone to facilitate some Drupal/LocalGov Drupal training, it should make a good starting point for topics to learn about.

I've been working on a template design for LocalGov Drupal recently, which I will make available for free for anyone to use as their starting point. 

Full disclosure: it will be the design that I use for an upcoming course I am going to release called "Build a LocalGov Drupal Website".

In this post I want to share some things to consider when designing for LocalGov Drupal.

Understand the LGD Template System

If you know what the LGD templates are going to output, you can design with that in mind. Why is this important? There are three main reasons:

1. Your developers will not need to create custom templates for each component, allowing them to work faster.
2. Any updates to LocalGov Drupal from the core team (e.g. if we fix an accessibility issue) will automatically be applied to your website when you update the codebase.
3. Our templates are designed to follow the GOV.UK Design System patterns so should be very safe to use, saving your time/effort/money on researching new patterns.

An Example: the header

Our header template is quite complex, with a number of regions. It expects things in a certain order: Logo, Services dropdown button, Menu.

If you want to put things into a different order (logo, menu, services button) or add more to it (second menu above the main menu, search block, etc), then your developers will need to maintain a custom version of the header template. But not only that, a custom version of the header template cannot exist without a also overriding the general page template. We should file an issue to see if we can streamline this in the future, but for now, this is how it works.

In my course, we will use a custom header template so that we can see the process of what is involved.

Design Tokens

LocalGov Base theme has a lot of CSS variables for things like fonts, font sizes, widths, spacing, line-heights, and more. Most of these can be left as defaults (for example --spacing currently resolves to 1rem, and all other spacing variables are based on that (--spacing-large is calc(var(--spacing) * 1.5) - 1.5 times 1rem).

Try to only create new tokens/variables for things that are specific to your brand guidelines. These will probably include fonts, line-height, colours. If you think about this closely, the custom variables.css file that will be needed for your custom tokens could be as small as something like this:

body {
  --color-accent: #123456;
  --color-accent-2: #ffe146;
  --font-primary: roboto;
  --font-secondary: "Roboto Slab";
  --line-height: 2;
  --width-container: 72rem;
  --color-grey-lightest: #f5f5f5;
}

Designing a Styleguide

The styleguide you design can be as complex or as simple as you want. I like to keep them simple, so there is very little discussion needed about what is what, and even less maintenance for the future.

It's a good idea to have a grid system worked out for your page widths. The LGD grid system uses a 12-column grid, so it will make sense to follow that. You can set the max-width of your content area to whatever with you want. In the LocalGov Base theme there's a variable called --width-container. You can have that at any width you wish - 60rem (usually 960px) or 90rem (usually 1440px), etc. You can then apply that grid system to every frame in your Figma file, so when you design a component, it will automatically fit correctly in each page design.

Often I will just put the colours, fonts, and spacing scale into the design system. In Figma make sure to create a 'Style' for each of these so you can easily apply it to any item in your design. Here's an example:

Designing LocalGov Drupal Components

Components

LocalGov Drupal has a lot of components. Not all of them need a custom design. What you get "out of the box" should suffice for many needs (e.g. the accordion, quote, alert, etc components). With this being the case, let's focus on the custom designs that we will need. These might include things like:

• Header
• Footer
• Breadcrumbs
• Box Link
• Page Header - title and introduction/lede
• Link Block
• Top Task
• Call Out Box
• Image/Media with Text
• Card
• Teaser

If you need more, feel free to design more. But remember the more you design, the more you need to maintain and document.

Patterns

Once you have your individual components designed, it's time then to think about your patterns. Patterns are amalgamations of components (either multiples of the same component or individual components placed along with each other) to show how individual components should be used. You might design patterns for:

• Banner
• Box Links Listing (multiple box links to create an initial IA for a service)
• Page Header (page title and page introduction)
• Link Blocks (multiple link blocks to create a service listing)
• Card List (multiple cards for the featured news)
• Teaser List (multiple teasers for listing pages/search results)

Here's an example of a card listing pattern with three components:

1. Styled Header
2. 3 Cards
3. CTA Link

Designing LocalGov Drupal Pages

Now that we have our styleguide, our components, and our patterns mapped out, we are ready to start designing our pages.

Create a frame for each page you need. In my course will we design the following:

• Homepage
• Homepage with Alert
• Homepage with Promos (call out boxes)
• Service Landing Page
• Service Sub-Landing Page
• Service Page
• Directories Channel
• Step-by-Step Page
• Guide Page
• Listing Page (news, for example)
• News Page
• Blog Page
• Event Page
• Search Modal

Each component that goes onto a page at this point should be an "instance" of a component from your components directory. This means if you change the design of a component at the component level, all the instances of that component will also update. Some examples:

Homepage

• Header - component
• Banner - component
• Box Links - pattern
• Services Listing - pattern
• Image with Text - component
• Card Listing - pattern
• Call Out Box - pattern
• Footer - component

And that might look like this:

Listing Page (e.g. News)

• Header - component
• Breadcrumbs - component
• Page Header - pattern
• Divider - component
• Search Block - pattern
• Filter Block 1 - pattern
• Filter Block 2 - pattern
• Teaser Listing - pattern

Wrap Up

What we can start to see here is that it's possible to design beautiful LocalGov Drupal website, that follow the well-tested patterns of the GOV.UK Design System. By having an understanding of how the LocalGov Drupal base theme works, we can do this at scale, quickly, without sacrificing any quality. That's how we make the foundational aims of LocalGov Drupal a reality.

If you'd like to use this design as the base for your own, you can view the Figma file here.

If you'd like to get notification about the "Build a LocalGov Drupal Website" course, you can sign up for updates here.

I took June off and spent the month in Spain with my family. We had a great time, very relaxing and all work thoughts switched off. Then ... I came back to drowning in a sea of GitHub notifications, so excuse me while I try wade through a month's notifications and respond to what needs to be responded to.

Meetings

1. Merge Tuesdays: I always enjoy these meetings. Delighted this month to have a new features for responsive tables released for LocalGov Base. And we also merged a PR to remove lots of words from our URL aliases for new sites.
2. Tech Group Drop-ins: One of these in particular was very interesting, when Bob from SRS Wales came along and instigated a discussion about security. You can read the extensive notes we kept from this. Another really interesting session we had was debugging facets issue with Northumberland Council where facets were working fine in the base theme but not working in the custom theme. Always good fun to work our way through these tricky things.
3. Tech Governance: These meetings are always an eye-opening in how much effort it takes to run a successful open source community. We spent a lot of time this month discussing supporting more than one version of the base theme at a time (for example when we introduce breaking changes such as moving from flexbox to grid).
4. Community Meetup: Interesting one this month. Was great to see my work building the Irish Council Planning Notices module being demonstrated.

Code Contributions

1. I couldn't help myself. Tim in Tipperary County Council made a really cool module for reporting blight in your area by pulling in data from Met.ie. I couldn't help myself from doing a little bit of tidying up and refactoring so the module is easier to install. And then some more refactoring, and then even more refactoring.
2. It turns out LocalGov Scarfolk has a missing dependency on LocalGov Base if trying to install it on its own. But now there's a PR to fix that.
3. Something I really enjoy is reviewing and refactoring code. Our elections module is very powerful, but much of the JavaScript in the module did not follow Drupal's coding standards. So I wrote a PR to rewrite it.
4. I had written a version of a module a number of months back to allow content editors to clone content, with the Replicate module being the base for my work. We decided a few weeks ago that we would use the Replicate UI module as the base instead, so we would then have very little custom code to maintain. So I spent some time removing the code from my original writing of the module and re-wrote the module to use Replicate/Replicate UI as the base.
5. In an effort to get this module to a 1.0.0 state for an official release, I also wrote a suite of tests for it. Hopefully we'll get those merged soon and the 1.0.0 release made. Update: Reader, it's merged!
6. And then we moved the project to Drupal.org, so it's one less module we will need to move there when we migrate all projects there.
7. And now I need to check if the module works for the Microsites Platform, and if not to create a submodule that will sort that out.
8. I was doing some training sessions with Islington Borough Council recently, and they wanted to see an example of a Drupal module that makes API calls to an external resource. I thought the module I started work on recently for Netcall Converse Queue Data would be a good candidate for this. But the bonus was that I also did some work to refactor the module and use a service and dependency injection to connect to the Netcall API instead of placing this in the .module file.
9. I rewrote our Grid system recently and am now making a push to use the same system for our other templates that were not part of the original rewrite. E.G. layout paragraph templates use a template from Stable9, but that uses it's own system. To try to have better consistency, I created an issue to get some traction for this, and now have also create a PR to make some movement on it.

Bonus

I had some very nice mentoring sessions/Slack chats with the good folk of North Yorkshire County Council. They are trying to ensure their website is as accessible as possible so we had some chats about the cookies page and overflowing tables on small screens. Which is now fixed from a PR we merged to LocalGov Base.

And then I did the same with some of the Northumberland devs, to try figure out why a Twig Tweak function wouldn't embed a directory search block in a template.

I really enjoy hopping on these quick calls to sort out an issue for a council or agency, whether they are a client or not.

Meetings

I got to lots of meetings this month, all the usual ones - Merge Tuesday, Tech Group Drop-in, etc. Two meetings that stood our for me, however, were the content group session about images in LocalGov Drupal and the Accessibility Awareness Day meetup where I led a breakout room on accessibility testing tools.

I've been really enjoying the Tech Group Drop-in meetings of late. I usually don't have any questions that need answering, but I love being at the meetings to help out others who do have questions that need answering.

One meeting this month that was very productive was the Open Digital Cooperative business development meeting, where we continued working on our 3-year business plan. This month we focussed on competitor analysis and market capture.

Code Contributions

• A nice little PR to add an author filter to the default /admin/content list.
• A PR I've been meaning to get around to for a long time, but one that also doesn't excite me is the one to add the linting tools to .ddev commands. Finally, I got around to it and now we can run commands to lint and automatically fix our CSS and JS coding standards. You can do this by ddev stylelint-fix web/modules/contrib/localgov_alert_banner/**/*.css or ddev eslint-js-fix web/themes/contrib/localgov_base for example.
• And with that done, I got to (hopefully) complete another issue that has been open for longer than I wnated it to be - linting the JS files in LocalGov Base.
• Apparently tables added through the WYSIWYG breaks content reflow. Well, not if I can help with my nifty PR.
• After showing that PR for responsive tables off at Tech Group Drop-in, we came to the conclusion that we should do some more work to create a theme setting checkbox so this doesn't affect any existing sites that might already have a custom solution. So then I built that!!!
• We scoped out a feature to supplement the Media Entity Usage module, so now when you are on the media listing page - /admin/media/ - you can see how many times each media item is being used across your website.
• One I'm delighted with: our "LocalGov Repos" dashboard now automatically updates every night at 3am.
• I got a nice little accessibility issue (hopefully) fixed for Microsites directory channel search/facets blocks.
• I read a very interesting article from Andy Bell of Picalilli about styling alt text on images. It was so interesting, I created a pull request to style the alt text of the images of LocalGov Base.
• A little fix and another similar little fix to make LocalGov Microsites menus more accessible.
• I created - and we released - a new version of our grid system, but it broke existing sites that had created overrides, so we reverted it on the 1.x branch and released it as a new feature on the 2.x branch.

LocalGov Telemetry

I got started this month on a "LocalGov Telemetry" module. The point of this is so we can have some data on how many sites are using what modules/features. This might make it easier to deprecate features and/or remove them if they are not being used.

And after starting it, I realised others - besides LocalGov Drupal users - might like to use this, so I abandoned LocalGov Telemetry and created Modules List on Drupal.org. We can then use Modules List as the basis for LocalGov Telemetry.

Training Your Developers for LocalGov Drupal

As a highly-opinionated CMS, implementing LocalGov Drupal successfully requires developers to have a good grasp of specific concepts and tools crucial for managing and optimizing your site. Below is a loose outline focused on guiding developer training to leverage LocalGov Drupal effectively.

Drupal

Local Development with DDEV

DDEV is a popular local development environment setup for Drupal. Trainers should emphasize the installation process, benefits of containerization, and the simplification of development environments, ensuring a consistent developer experience across different machines.

Basic Drupal Concepts

Developers need to understand Drupal's core concepts such as nodes, terms, blocks, and views. An understanding of config management (it's easy once you get your head around it) is also necessary.

Site Building

Site building involves creating content types, lists, and page components. Training should offer hands-on experience in using Drupal's admin interface to structure content types and page components (using paragraphs module in LocalGov Drupal) and build dynamic pages and lists efficiently.

Extending Drupal

Drupal’s extensibility through modules is a key feature. Developers should know the difference between when to use a module on Drupal.org and when to write a custom module. Training should include creating simple custom modules and using contributed modules to avoid unnecessary custom code.

Theming Drupal

A comprehensive understanding of the libraries system, CSS system, JavaScript system, and Twig templates is necessary for theming. As well as that, developers should have an understanding of frontend PHP - preprocess functions, views pre-render functions, etc. Trainers should focus on creating custom themes and understanding best practices for designing maintainable and performance-optimized themes. We have a really nice theme generator for LocalGov Drupal.

LocalGov Drupal

Features Out of the Box

LocalGov Drupal offers specific features that cater to local government needs. Some of these include directrories, guides, step-by-steps, news, events, and of course the services suite. Training sessions should cover these built-in features, showcasing how they can save time and increase efficiency in project delivery.

Building and Interaction

Understanding how features are built and interact is crucial. Developers should learn how different components connect, ensuring seamless integration for user-friendly interfaces and functionality.

Theme System Design

The theme system in LocalGov Drupal is designed to be flexible. You can get lots done by writing only a small amount of code, but knowing all the built-in features to allow you to do this takes time to master. Developers should be trained on adapting the generated theme to align with their branding while maintaining adherence to standards such as for accessibility, performance, etc.

Maintainable Site/Theme Development

Building a site/theme maintainably involves using best practices in development and ongoing support. Training should include strategies for creating clean, modular code that allows for future enhancements.

DevOps

Deployment Processes

Effective deployment processes are essential for smooth transitions from development to production. Developers need to be familiar with tools and techniques for deploying changes safely and efficiently.

Backup Strategy

A robust backup strategy ensures data integrity and quick recovery in emergencies. Training should include setting up regular backups of content and configurations to minimize data loss risks.

Adding New Features in the Future

Planning for future growth includes understanding how to integrate new features without disrupting existing functionality. Training should cover best practices in version control, coding standards, and testing to ensure sustainability and scalability.

Can't wait until you find your perfect training partner?

Here's a few links to get you started in the meantime.

• LGD Docs - https://docs.localgovdrupal.org/devs/
• LGD YouTube - https://www.youtube.com/channel/UCgOTBrkZvJwCuODRpHxZIIA
• Some of my video tutorials - https://www.youtube.com/@markyconroy/search?query=localgov
• Drupal developer docs - https://www.drupal.org/docs/develop

Investing in structured training for developers to work with LocalGov Drupal ensures the creation of sustainable, adaptable, and powerful websites that can effectively serve the needs of local governments.

Meetings and Meet-ups

1. Merge Tuesday: Y'all'll be glad to hear LocalGov Publications Importer is coming along very well, thanks to some great work from Andy and Rupert.

Code Contributions

1. Nik opened an interesting issue last week with Gin/Gin Toolbar CSS being called on the frontend when opening things in modals, but not being available since we are not in the backend of the website. I'm not fully sure of the solution for this just yet, but I've added to the conversation an idea that I think will allow us to use the needed styles without doing much work (or future maintenance). Win!
2. We have a small set of icons in our localgov_base theme. But everytime I am implementing a custom theme, I need to use different icons (e.g. X instead of Twitter or a new social media platform has become popular). I usually try to have these contributed back to LocalGov Base so everyone can use them. Then I thought: "why not put the whole of font-awesome into LocalGov Base?" so we have a really good library of available icons. So that's what I did in this PR.
3. Here's a juicy one: at the moment our header.js file presumes all sites will use 768px as the breakpoint for when mobile menus, etc kick in. We now have a PR to create a theme setting, so individual sites can decide at what breakpoint they want the mobile JS items to kick in so they won't need to override the whole of header.js.
4. Live previews module is almost ready for the big time, and now has some tests available as well.

Recently, I've only been able to get around to about a day a week of LocalGov Drupal contributions. Which has meant sacrificing some of these update blog posts in order to get more PRs or other work done. Let's try get back on track.

Meetings and Meet-ups

1. Merge Tuesday: This was got very into the details of Drupal and Single-directory Components, and we now, thankfully, have an SDC for the node--full.html.twig file.
2. ODC BizDev: A short but productive meeting about a business plan for LGD in the age of LGR.
3. Tech Governance: A really interesting chat about migrating our code to Drupal.org, and also recreating LocalGov Base components using Single-directory Components.

Code Contributions

1. I've had a PR open for a while for a better design for the contact component by default. I got some more work done on that, and I think it's now ready for approval.
2. We are pushing hard to get the Live Previews module ready for LocalGov Drupal. A bug got reported last week concerning adding/editing the logo from within the Live Preview interface. I have a PR open to remove the logo field from there, I can't imagine people using that feature to change their logo, and if we need it we can add it back in later.
3. The publications cover page has a listing on publication items with an icon (SVG) and the title of the linked document. SilkTide is reporting that there is no text content in the SVG which is wrapped in a <a> tag. But we have aria-hidden="true" set for that SVG, since the next item is also a link - this time a text link linking to the document. I wonder if this is just SilkTide reporting false positives? Feel free to join the conversation.
4. The aria attributes on the mobile menu for microsites seem to have been giving some issues. Menus are very tricky things to get right, espeically when you have multi-level menus. We have a PR now that I hope will fix any aria-* issues in the microsites mobile menu.
5. I got around to some other small fixes for microsites such as 'Focus colour for off-canvas menu items'.