Thanks to Big Blue Door for sponsoring my time to work on LocalGov Drupal.

Ideas to get started

Contribute what you want

I think the first thing to think about when contributing to LocalGov Drupal - indeed to any open source project - is to contribute what you want to contribute. We are always open to see what someone wants to contribute, and it might be a great idea we haven't thought of ourselves. If it's suitable, we'll accept it or ask for some modifications to bring it into line with our standards. If it's not something we are interested in, at least you have gained that knowledge too.

As an organisation, consider being a stakeholder of an initiative

All agencies have specialties. If yours is accessibility, have a look and see what accessibility needs LocalGov Drupal has. If you speciality is performance, perhaps do an audit of hour our sites fare, and suggest improvements. If your speciality is something else, figure out where we are falling short of your high standards in this area and help us make it better.

Perhaps you'd like to become known as "the agency" that does X in LocalGov Drupal. Be that agency and take a vested interest in a feature - blogs, directories, news ... whatever. It's always handy if someone has a question for us to be able to say "go chat with [your agency name here] about that".

If you are feeling really adventurous, you could propose a whole new feature for LGD and if it's a good idea, go build it. That's how I got started, I proposed a re-write of the entire frontend of LocalGov Drupal.

Ask questions

Instead of looking to contribute something specific, how about you hop on to the Slack and just ask questions for things you need to know about LGD. Then when you get answers, use that information to add to the documentation to benefit everyone. Or create tutorials and videos to show off what you now know.

Check the roadmap

We have a roadmap of activities on the LocalGov Drupal website. Have a look at it to get an idea for where we are going in the coming months and see where you can be of help.

Come to a meeting

We have lots of meetings. Come to some, learn, ask questions. After a few of these you should have lots of ideas for ways to help us out.

• Merge Tuesday to you know what new features have been released
• Tech group drop-in to ask any technical questions you might have
• Tech group governance to find out about who is maintaining what
• Content group to learn about how council content designers are using the platform
• Product group to see what we are working on
• And many more

Ideas for specific skills

Developers

We have two bookmarks on the technical group Slack channel

1. Pull requests that need to be reviewed
2. Pull requests that need to be merged/have been reviewed

These are two great places to get started. Someone has already done the work, but we are always stuck for people to help out reviewing it before it can be merged.

Frontend Developers

Have a check on the LocalGov Base repo. That's our main frontend repo. 

Following that, have a look at the LocalGov Microsites Base repo. That's the main base theme for microsites. There's a few niggling issues there about the menu system (especially for multi-level menus).

LocalGov Claro is our base admin theme. I really like it, and there's very few issues, but I'm sure it could be better.

Backend Developers

The main bulk of our project is backend work. Check any of the repos issues and there should be something for you - Guides, Step-by-Steps, Services, Directories, etc.

Content People

Documentation can always be better. have a look at our docs site and see what's missing. For example, if you look at the Designers page on the documentation, you'll see we have a link to news wireframes that links to a private PenPot. It would be good to find out if we can get an image of the wireframes and add them to the docs site.

Hopefully those ideas will spark your imagination and I'll see you soon contributing as much as possible to this great public resource.

One of the patches I wrote last week got merged on the day I wrote it. That's the fastest I've ever seen an issue go from being reported to being fixed and merged. Let's see how this week goes ...

1. All demo content created with the demo_umami_content module is created with the same timestamp. This is fine in general, but we have some views that sort items by their created date, which is moot since they all have the same created date and time. Catch created an issue for this, and I created a merge request to set each node as being created one day after the previous node, so our sorting will work better. We have 19 nodes created with the demo content module, so this means:
   1. Node 19 was created yesterday
   2. Node 18 was created 2 days ago
   3. Node 17 was created 3 days ago
   4. and so on
2. Sometimes you find gems, such as an accessibility issue we have open for over 5 years noting that the Umami theme does not have all of its content inside HTML landmarks. There's two solutions for this - move all the content that is outside of the <main> element to inside it, or create a new <section> to place all that content. I created a merge request to place all the content inside the <main> element, at least to get the conversation started.
3. I started on an issue about 2 years ago to stop using hardcoded CSS values in the Umami theme and start using CSS variables. I had it in such as way that it was ready to merge - I thought - until the issue started expanding to include SVGs as well. Now we've moved half of our Umami CSS to Single-Directory Components, so that MR doesn't work any more. I'm now starting to think about how to get it redone in our SDC-enabled world. That's going to be next week's task.

Woah, another very enjoyable Friday making Drupal core better than it was yesterday. Thanks to Code Enigma for sponsoring this time.

When contributing to Drupal core, or any distribution of Drupal like LocalGov Drupal, or doing anything that needs you to install and reinstall Drupal a lot, it gets frustrating having to go through the same steps. 

I often hit the up arrow to use my last command in my terminal which might look something like this:

ddev drush si standard -y && drush cex -y && git add config/sync && git commit -m "config" && ddev drush uli

What does that do?

1. Installs Drupal using the standard profile
2. Exports the default config to the config/sync directory
3. Adds this config to a dummy git repo that goes no where - this is so if I need to do something that changes config, I can re-export the config and do a git diff to see what changes I need to add back in to my module/installation profile
4. Gets me a login link

However, I often need to install the Umami profile, since I am a Drupal core maintainer for that. And I often need to install the LocalGov Drupal profile, since I am the frontend lead for that project. And sometimes I need to install the demo_content module with LocalGov Drupal. 

With all that in mind, I decided to create a bash script that would install any of these profiles and allow me to choose which one when I run it. Here's the script:

#!/bin/bash

set -x

#!/bin/bash

echo "What profile do you want to install?"
options=("Standard" "Umami" "LocalGov" "LocalGov (with Demo Content)" "LocalGov Microsites" "LocalGov (with Elections)")

# Check if a command-line argument was provided
if [ $# -gt 0 ]; then
  # Use the command-line argument as the profile selection
  profile_selection=$1
else
  # No argument provided, fall back to interactive selection
  select profile_selection in "${options[@]}"
  do
    break
  done
fi

case $profile_selection in
  "Standard" | 1)
    ddev drush si standard -y
    ;;
  "Umami" | 2)
    ddev drush si demo_umami -y
    ;;
  "LocalGov" | 3)
    ddev drush si localgov -y
    ;;
  "LocalGov (with Demo Content)" | 4)
    ddev drush si localgov -y
    ddev drush en localgov_demo -y
    ;;
  "LocalGov Microsites" | 5)
    ddev drush si localgov_microsites -y
    ;;
  "LocalGov (with Elections)" | 6)
    ddev drush si localgov -y
    ddev drush en localgov_elections_demo_content -y
    ;;
  *)
    echo "Invalid option. Please run the script again with a valid option."
    exit 1
    ;;
esac

ddev drush cex -y
ddev drush cr

# wait 3 seconds, so the config has fully exported
sleep 3
git add config
git commit -m "config"

ddev drush uli

This script gives me six options:

1. Standard - the standard installation of Drupal
2. Umami - the Demo Umami profile
3. LocalGov - the default LocalGov Drupal installation profile
4. LocalGov (with Demo Content) - installs the demo content module after installing LocalGov Drupal
5. LocalGov Microsites - the LGD microsites platform profile
6. LocalGov (with Elections) - enables the elections suite of modules, I needed that lots over the past few weeks

Now, when I want to re-install Drupal, I can run bash _install-drupal.sh (it has the underscore so it stays at the top of the directory I have it saved in). That will then ask me to enter 1-6 for what profile I want to enable, or I can run bash _install-drupal.sh 2 to install profile 2, which is Demo Umami.

This came in very handy today when working on a hook_install() to set various created dates for the demo content in the Umami profile. I had to reinstall the site to test it about 20 times, so this was a real time-saver.

After the profiles install, I then export the config. After that I wait 3 seconds, if not the git add config often doesn't get all the config and the directory may not have finished getting cleared out and restocked.

I hope that help you. If you have any improvements, I'd love to hear them.

Meetings and Meet-ups

1. Merge Tuesday. We got enough merged today to - hopefully - have a stable release of LocalGov Elections this afternoon. Then we had a very deep conversation a patch failure for LocalGov Services that is stopping councils from upgrading to Drupal 10.3.
2. Tech Group Drop-in. We worked on clearing the last stable blockers for the LocalGov Elections module. We succeeded and tagged a 1.0.0 release.

Code Contributions

1. I rewrote part of my PR to change the title structure of elections results pages, to make sure some views pages didn't break when trying to access the results.
2. We have a number of dev and beta modules in the LocalGov Elections suite, so I spent some time testing the latest stable versions of these to see could we remove the dev versions - we could!
3. The results timeline feature is proving to be a tricky piece of work to get right, so we have decided we don't need it for the upcoming elections, but that it will be very handy for the local elections. I created a PR to remove it for now.
4. We have a checkbox to turn off the number of votes needed for a majority - since it's not needed on some election types - but some people were skipping it by accident. We have now a PR to ensure that the setting is always false when viewing a national parliamentary election, such as the on e in the UK this week.
5. And then we decided that wasn't the approach we wanted to take, so we now have another PR to simply set that field as off by default instead.
6. I'm a big fan of consistency and separating concerns, so it's always frustrated me that we use the same view mode in LocalGov Drupal for our teaser listings (e.g. news listing) and our card listings (e.g. featured news items). Why not have a consistent way of styling cards and a separate consistent way of styling teasers (and other view modes). So now we have a PR to do just that - add a card view mode to LocalGov Drupal. It even has an update hook so all LGD sites can take the same approach.
7. We had a PR to add the "Compare revisions" button to the top of the page (as well as the bottom) but it seems the maintainers of the Diff module have implemented it already so we don't need to. I then updated my PR to make the button sticky at the top of pages when you scroll which is helpful if there's been a lot of revisions and you can't see the top or bottom of the list on your screen.
8. Tests are very important to the LGD team, we try to have as much test-coverage as possible. I hadn't realised, but our LocalGov Claro theme didn't have any tests, so I created a PR to add our default theme test suite to it.
9. Sticky headers are a common feature on websites - always sticky, or sticky when you scroll back up the page, etc - so why not create that feature for LocalGov Base so we have it available for all councils if they want it. I started work on that this week, but it tricky to get config updates into themes since they don't have a .install file. I've now also started a LocalGov Base Supports module to solve this. Hopefully I'll get it finished next week.

I got two pretty nice things completed this week (I only had time to spend a half a day on Drupal contributions this week). Both took a lot longer than expected. You win some, you lose some!

• I love how easy it is to turn on Twig debug settings via the new admin/config/development/settings page. However, I get frustrated everytime I click the first checkbox, because it exposes more options and which then moves the second checkbox down the page. So I thought, let's create an issue to swap the order of these two checkboxes, and of course a merge request to go along with it. It's a pretty small change, but damn it took ages to do as I managed to get myself into a git conflict hell-o-rama creating the branch.
• I created a module about 2 years ago called LocalGov Sa11y, which integrated the Sa11y accessibility checker into LocalGov Drupal websites. However, it's a very generic module, so I decided to make it available on Drupal.org instead so any Drupal website can use it. I contacted the owner of the https://drupal.org/project/sa11y namespace and asked if I could take over it. I expected a response next week or some future time, but they got back instantly and made me a maintainer of it. So now we have the Drupal Sa11y module available on Drupal.org, sponsored by Code Enigma. Pretty cool.
• I thought it would take about an hour to put that module on Drupal.org but it took over 2 hours, by the time I had finished removing all the old code, adding my code, removing all the references to LocalGov Drupal, closing all the old issues, updating the project homepage, etc.

Drupal and other open source products get better when people can spend the time to work on it, either because they have spare time or they are funded. Thanks so much to Code Enigma for sponsoring my time.

I only managed to get one day's sponsored work done this week as it was my wedding anniversary so I took a bit of time off early in the week to celebrate. But, we still got lots done, here's the run down.

Meetings and Meet-ups

1. Tech Group Drop-in. The always interesting meeting of the week. This week we discussed hosting on Azure, Polyfill.io, and Adrian Bateman's "Restricted Content" module.
2. Microsites Meetup. This is a relatively new meet-up for councils and agencies working with the LGD Microsites platform. Today we talked about theming a microsites out of the box with no design help and Single Sign-On for Microsoft when using microsites.

Code Contributions

1. It's all elections this week. After reaching a cool Beta release last week we now need to get a stable release this week. First up, testing a PR from Adnan to correct some permissions for the Election officer role.
2. Then I fixed an issue that was breaking the elections demo content module. It's always something simple once you track it down, in this case a field name of localgov_elections_election which should have been localgov_election.
3. I tried to look at rewriting the elections timeline page, but it's a bit of a gargantuan task, so I've postponed it until we have the other stable blockers fixed. I'm not sure if we actually need this page for a stable release, or if it's more of a "nice to have".
4. I'm a big believer in having as few dependencies as possible in our codebases. For example, the whole of the LocalGov Drupal frontend system exists with 0 dependencies. To this end, we now have Font Awesome removed as a dependency in LocalGov Elections, with the 2 icons we needed inlined as SVG - no point in loading the whole of FA just for 2 icons.
5. I created a small accessibility checker module called LocalGov Sa11y as part of the LGD Microsites project, which will work on any Drupal website, not just an LGD or LGD Microsites website. However, it had no documentation on how to use it. Now it does!
6. And now that there is some documentation for LocalGov Sa11y, and since the module will work with any version of Drupal, I decided to see if the folks who own the https://drupal.org/project/sa11y namespace would be interested in letting me use that instead of maintaining the module on GitHub.
7. Editors (and visitors) often like to see a list of what changes were made to pages on their website. We now have a PR open to create a "Change log" block showing all the revisions of a piece of content. Thanks to Anthony from Annertech for the initial work on this feature.

Another very satisfactory week's contributing to LocalGov Drupal to make it better for everyone, sponsored by Big Blue Door.

Week 2 in my "luckiest person alive to have this job" chronicles. Let's see what we achieved this week to make Drupal better for everyone.

1. The initiative meetings are still going on. This week I attended the "Experience Builder" update. This looks really interesting, really ambitious, and really cool - a mix of layout builder + paragraphs + Gutenberg + a kitchen sink ...
2. We got an issue to stop using the body field in the Umami profile merged, so that makes Drupal core one bit better.
3. I created an issue on Drupal.org just before DrupalCon in Prague in 2022 to simplify the default markup from the field.html.twig file. It got a lot of attention at the time, but since we didn't get it fixed then, the enthusiasm has waned a little bit. This week I revived it with an updated proposal for the markup for that file.
4. Kind of related to last week's blog post about setting up DDEV for Drupal core contributions, I decided to automate it with a bash script, then I wrote a blog post to help others contribute to Drupal core more easily.

Thanks to Code Enigma for sponsoring the time to work on these type things. I hope this knowledge is beneficial to others and encourages more Drupal core contributions.

First create a file called setup-drupal.sh and place that "somewhere" on your computer. I have it in a folder called /Users/markconroy/projects/drupal-contrib/. 

Then create the directory you want to install core for contribution into. I use /Users/markconroy/projects/drupal-contrib/drupal-core/

Then, using terminal, cd to that drupal-core directory and run the bash script from there, like so bash /path/to/the/setup-drupal.sh. 

Viola!

#!/bin/bash

set -x

# Configure the DDEV project
ddev config --project-type=drupal --php-version=8.3 --docroot=web

# Start the DDEV project
ddev start

# Create a new Drupal project
ddev composer create drupal/recommended-project:^11.x-dev

# Navigate into the web directory and remove all files
cd web
rm -rf *
rm -f .*

# Clone the Drupal project
git clone https://git.drupalcode.org/project/drupal.git .

# Navigate back to the project root
cd ..

# Update the DDEV configuration
ddev config --update

# Restart the DDEV project
ddev restart

# Require Drush using Composer
ddev composer require drush/drush

# Install the Drupal site using Drush
ddev drush site:install --account-name=admin --account-pass=admin -y

# Generate a one-time login link for the Drupal site
ddev drush uli

# Print the current directory
pwd

# Edit ./web/autoload.php to change '/vendor/autoload.php' to '../../vendor/autoload.php
sed -i '' 's/\/vendor\/autoload.php/..\/..\/vendor\/autoload.php/g' web/autoload.php

# Launch the Drupal site in a web browser
ddev launch

I'm early this week. Normally, I spend Wednesday and Thursdays working on LocalGov Drupal, but this week I spent Monday and Tuesday doing it, in an effort to get as much LocalGov Elections work done as possible.

Update - I also spent Wednesday and Thursday working on elections to try get a beta version ready. Thanks to Big Blue Door for being understanding and sponsoring that extra work.

Meetings and Meet-ups

1. Merge Tuesday. I'm writing this on Thursday, and we've done so much this week with elections, I can't remember exactly what the main focus on Merge Tuesday was this week!
2. Tech Group Drop-in. This was a real deep dive - MySQL queries getting large, using a microsites module on a non-microsites account, entity share module, and more.
3. Community Meet Up. I haven't been at a community meet up in a few months. It was great to get back to it today and demo some of the editor experience work I have been doing recently, in particular the Content Access by Path module.

Code Contributions

1. Reviewed and merged PRs from Lee Millnut to make LocalGov Base and LocalGov Scarfolk Drupal 11-compatible. Thanks Lee.
2. Reviewed and merged a PR from Lee to get LocalGov Sa11y to use the new shared workflows testing system that we now have.
3. Rewrote some of my PR to rename the social post module that is part of the elections suite. The extra part was to leave the original module in place, mark it as deprecated, and uninstall it if the new module is being installed. We can fully remove it at a later date.
4. Reviewed and merged a PR from Lee to get LocalGov Multilingual to use the new shared workflows testing system.
5. It's all about elections this week. I created a PR to rewrite the frontend templates and CSS to bring them more in line with the LGD coding standards.
6. The election module's JavaScript was written with a dependency on jQuery. We've been trying hard to not have any external library dependencies in our frontend systems, so we now have a PR to rewrite the elections JS using vanilla JavaScript.
7. Elections module has a backlog of things that need to be fixed on mobile before we can mark the module as stable. I have a PR open now to try to solve each of these issues. This was nice, complex task to work on.
8. We have a lot of PRs open, now that we have a lot more contributions being created. So there's a push on to review as many as possible before Merge Tuesdays. Mission Accomplished!
9. Will had an idea to add default content to the political parties taxonomy for elections. We now have a submodule to do just that for UK political parties. This will give us consistency between councils for how parties are presented. We can create follow up modules for Irish parties, etc when we expand the module.
10. And after all that ... we decided to rewrite the whole LocalGov Elections Reporting module to use the namespace localgov_elections instead of localgov_elections_reporting to ensure we had consistency between the parent module and the submodules. While doing so, we also rewrote the names of all the fields, entities, views, etc. Cue a very late night for myself and Finn trying to get it all ready for the other developers to be able to work with it the following morning. Check out the monster pull request to rewrite the LocalGov Elections module.
11. And now we are on to clearing the last beta blockers, so we can have a stable release next week in time for the UK elections in early July. Wish us luck!

Time for a celebratory drink, I think.

Here we go, week 1 of being sponsored by Code Enigma to work on Drupal. What did I get up to?

1. Attended the "Recipe Updates & Next Steps" meeting, along with lots of other Drupalistas from across the world. Recipes, Starship, etc are going to make Drupal so much easier for ambitious site builders.
2. Wrote a blog post on how to set up a local development environment for Drupal core contributions using DDEV. This is one of those "messages to future me" posts, but hopefully others will learn from it too and also begin their contributions to Drupal core journey.
3. Attended "Automatic Updates & Next Steps" meeting.
4. It looks like we have an issue in Umami where we add a class to some fields, but we are overriding the whole array of classes those fields already have, instead of adding to the array. I'm not sure how it's taken so long for someone to notice this but thanks to Lillian Bozeman for noticing and taking the time to create an issue. I've an MR created now to fix it.
5. There's a long-standing project to stop using "Text with summary" fields in Drupal. We've had a PR open for quite a while to replace our "Text with summary" body field with a new "Long text (formatted)" field instead. That issue is now RTBC and will hopefully be committed soon.
6. Triaging Umami issues. This is going to take longer than I expected, we're quite a bit behind on issues for this initiative.
7. Triaging Stable issues. Thankfully there was only one relevant one, and it is not outdated since it related to Drupal 9.5 which is no-longer supported, so I have closed that issue.