When contributing to Drupal contrib, it's quite easy to git clone the module you want to work on into your codebase, do your work, and push it back up for the community to validate.

The set up when contributing to Drupal core is a little bit more complex. I haven't had the space to contribute to Drupal core as much as I'd like recently, but am now in a position to do so again, thanks to very generous sponsorship from Code Enigma.

When I started setting up my environment this morning, I ran into a few issues. Actually, really just one issue, but I couldn't solve it, so I came up with what is either:

1. A workaround, or
2. A better way!

I'm quite new to DDEV, but so far I'm lovin' it! I followed the Drupal.org docs for setting up DDEV for core contributions 

1. Install DDEV
2. Clone core
3. Run ddev config --project-type drupal10 --docroot .
4. Run ddev start
5. Run ddev composer install
6. Run ddev composer require drush/drush

However, this resulted in the following error when ever I tried to install Drush, which meant I couldn't get to the final step ddev drush site:install y.

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires drupal/core 1.0.0 (exact version match: 1.0.0 or 1.0.0.0), found drupal/core[dev-main] but it does not match the constraint.
  Problem 2
    - Root composer.json requires drupal/core-project-message 1.0.0 (exact version match: 1.0.0 or 1.0.0.0), found drupal/core-project-message[dev-main] but it does not match the constraint.
  Problem 3
    - Root composer.json requires drupal/core-vendor-hardening 1.0.0 (exact version match: 1.0.0 or 1.0.0.0), found drupal/core-vendor-hardening[dev-main] but it does not match the constraint.

I'm not exactly sure why, but Drush was not going to be installed. 

I did some Googling, I did some changing this and changing that, but all to no avail. Then I remembered the oh sooo brilliant composer flag --prefer-source. 

So I started over again, and here's my "A Better Way".

1. Install Drupal via DDEV as you normally would, following the "Drupal Quickstart Guide"
2. Once everything is installed, reinstall all your packages that are within the drupal/* namespace but use the git versions of them instead, using this command ddev composer reinstall --prefer-source "drupal/*"
3. cd to your /web/core/ directory and git checkout 11.x (or whatever branch you want)
4. cd back to your DDEV root and install your site via ddev drush si -y.

I'd be very happy to hear from others how they set up their environments for Drupal core contribution. 

Meetings and Meet-ups

1. Merge Tuesday. Another great day of merging items in to the various codebases, including a very handy patch I wrote for microsites to allow editors to find content based on the content author or the page title.
2. Tech Governance. This is another meeting I haven't been to for a while, and felt quite guilty about since I am the maintainer of many LGD features. One of the major issues that came up during this meeting is that we now have lots of more contributions to LGD, but that means we have a bigger backlog of PRs to test ... and how do we get all that testing done.
3. Tech Group Drop-in. One of my favourite weekly meetings. Today we chatted about upgrading LGD Microsites from version 3 to 4. We also dug into that issue I've been having with a missing schema from the contact paragraph type, which ... we managed to fix!!!

Code Contributions

1. There's been a complex issue about stacked h1 patterns for guides, and by extension other content types. We now have a nice way to have a <h1> with more than one field inside it, the title and an optional subtitle. This week I created a PR to add this variable to localgov_base (which was committed within 20 minutes of being created).
2. You know when you need to upload a bunch of images, but our default set up says "no no no, you can only upload one image at a time"? Now we have a PR to make it happen.
3. How do you know your project is getting noticed? The maintainers of libraries you use create pull requests for you to let you know about the latest version of their library. We are now using 3.2.0 for the sa11y accessibility module in localgov_sa11y.
4. The LocalGov Elections module is looking great. This week I created a PR to start using chart.js charts which is open source instead of highcharts which needs a licence.
5. While working on the elections module, I noticed some discrepancies with dependencies and naming conventions, so created a PR to fix that.
6. The elections module has a submodule for sharing items on social media. The naming conventions used for this module are different to the other submodules. We now have a PR to bring that into line with the others.
7. Still trying to figure out a schema issue with LocalGov Paragraphs contact entity. Arrrghhh! If you can help, please do. Fixed in Tech Group Drop-in meeting, yippee!
8. Elizabeth from Haringey Council mentioned that callouts and alerts should have an icon, and that without them some users were skipping past those items to get to the rest of the content. We now have a PR to add icons to callouts and alerts.
9. We got the PR for last week's "Labelled Icon" accessibility issue merged. Expect that to be available when we do our next release of localgov_base.

I'm happy with that amount of work over 2 days. I managed to work on 12 items (3 meetings and 9 issues). Next week we are going to do a big push on elections to try have it ready before the election in the UK in early July. Wish us luck!

I'm actually away this week on holidays with family, but it's hard to keep me from working on open source, so I managed to get a few things done.

1. There's been some great work by Cumberland and Westmorland & Furness councils on creating an elections module, created by Rohallion. We're now in the process of making this more generic so it will work for all councils. My current task? Figuring out the frontend for this.
2. When you focus on a link in a "Labelled Icon" component, the focus style is only applied to the icon and not the text of the component. Fine, a simple fix ... cue 45 minutes of digging through templates and theories about non-existant CSS until EUREKA! We are rendering a div inside a span. Everything is easy when you figure it out.
3. Adding documents inline via the wysiwyg is not very intuitive at all. We're working on extending LinkIt module to allow linking to documents as well as existing pages. This is an issue that came up at LGD Camp, so it's great to see it getting worked on. Thanks to Duncan Davidson for doing most of the work on this so far.
4. Like all Drupal sites, LGD sites have a lot of image styles. Now there is some confusion emerging about what image styles are applied where, and if we can rationalise things a bit. If you can contribute to the conversation, it's happening on GitHub.
5. How cool would it be if we could see a live preview of our pages as we are editing them? Correct, very cool. Here's a demo of what that might look like and also a demo of what it might look like if you were using it to change the design of a microsite. We'll explore this more with the Same Page Preview module.
6. It's not ready just yet, but we're almost there with the "Add to Calendar" functionality for LocalGov Events. The conversation is now down to very small points, which we'll hopefully get ironed out this week and released next week.
7. We have one component still using Google maps instead of Leaflet/Open Street Maps. We have a PR for it. This works perfectly locally, but our tests are reporting schema issues. I've no idea why, since the config we have was exported from Drupal, so you'd expect it to validate. I'd love to get this merged asap, so if you have any ideas, please chip in on that merge request.
8. My Content Access by Path module does exactly what it says on the tin: allows access to content based on the path of the node you are looking at. George in North Devon council wanted to restrict edit access of the homepage from just one users. Our module does not restrict via just one URL such as "/" (the homepage) as that would allow edit access to every page on the site. So ... wrote him a small module to say "if the user id is 2 and the node id is 66, do not allow the person to edit the node". I'll post the code at the end of this post.

I'm pretty happy with that week's work, especially since I only got to do one day's dev on LGD since I'm no holidays. Next week, we're back to full-steam ahead.

<?php

/**
 * @file
 * Primary module hooks for no_homepage_edit module.
 */

 use Drupal\Core\Access\AccessResult;
 use Drupal\user\Entity\User;


/**
 * Implements hook_node_access().
 */
function no_homepage_edit_node_access($node, $op, $account) {
  $current_user = User::load($account->id());
  $current_user_id = $current_user->id();
  $node_id = $node->id();
  if ($current_user_id == 2 && ($op == 'update' || $op == 'delete') && $node_id == 66) {
    return AccessResult::forbidden();
  }
}

Meetings and Meet-ups

1. Merge Tuesday, we had a great meeting, and merged in some really nice updates from last week's work, most notably the "Media usage" tab so content designers can easily see where individual media items have been used.
2. Tech Group Drop-in, we had a great meeting, though I was a bit embarrassed as an LGD core developer to have to ask my question: "How do you view a microsite if using DDEV?" I guess it shows we all need a little help sometimes, especially if we are new to a project or have changed to new technology (like me changing to use DDEV about 2 weeks ago). Following that, there were very interesting chats about how to get started theming LGD and constructing menus automatically for subsites extras.

Code Contributions

1. Removed dependency on redirect module from LocalGov Core, since it's now required by the default profile instead. Thanks to Andy for pointing this one out to me.
2. Thinking about adding masquerade functionality to LGD, so individual users can see the site as if they were other people. This is handy for developers when trying to debug an issue.
3. Everyone wants to add events to their calendars, right? Now you can via the 'Add to Calendar' widget that is available for LocalGov Base (will be available soon, after some more testing).
4. Created a local patch for the 'Add a copy-to-clipboard feature for Preview Link', so we can use that in the meantime, while waiting on the same patch to be reviewed on Drupal.org.
5. Approved a PR to allow review dates and updated dates to be translatable.
6. Approved a PR so layout_paragraphs will work with your frontend theme. Why is this important? In case you wanted to use your frontend theme for content editing, for example if using the Mercury editor.
7. Everyone is excited about the new "Subsites Extras" module so we can theme individual site sections different to other parts of the site. Now we have more sensible defaults for the colours used, which should mean less time for any councils using this feature - perhaps even no development time.
8. We have a very nice linting set up for our CSS for localgov_base and any subthemes of it. However, we don't always remember to run the linter, then our code starts to not follow coding standards. Our code is now linted, but I really must set up an automated task for this.
9. We had a few issues with our default 403 and 404 pages, such as extending from the wrong parent template to duplicating the content on the page. Thanks to Christopher Wales for working on a fix for this.
10. Tables are always a bit tricky to work with. Thanks to ckeditor5 they are a little easier now. But that also brings in the ability to easily set columns as well as rows as your table header. We had no styling for this use case, but now we do. Thanks to Maria from Agile Collective for filing this issue.
11. We made a tweak to last week's PR to add an admin role. We now also have an update hook so all current sites will also get this functionality, and then we'll have consistency for all sites to have the same role working as admin, meaning new features for this role will be easier to roll out.
12. When viewing revisions, usually it's the newer versions (at the top of the list) you want to compare. On a page with a lot of revisions, it can mean a lot of scrolling to get to the "Compare selected revisions" button. We now have a PR open to duplicate that button and place it at the top of the form.

What another great week of making LGD better for everyone I've had. Thanks again to Big Blue Door for sponsoring my time to work on this.

Meetings and Meet-ups

1. Attended the Merge Tuesday session. I haven't been at these for a while since they were conflicting with other work meetings. I'm always amazed at the amount of work being merged each week.
2. Attended the microsites meetup. We're working hard to get a stable release of Microsites, and following that make it even better than it currently is.
3. Attended the the tech drop-in meeting. This is one of my favourite meetings of the week, where anyone can come along and ask a technical question about LGD. Even better, there's usually an expert there who can answer that question!

Code Contributions

1. Reviewing LocalGov Blogs navigation. This is a cool new feature being developed by Alistair Wearing from West Lindsey District Council, to add "Next" and "Previous" links for blogs.
2. Reviewing Revisions Log Block which is being worked on by Anthony Lindsay from Annertech, so we can have a block on any node pages showing all the revisions of that page.
3. X icon added to available icons for LocalGov Base. I held out on creating this PR, presuming X would go back to being called Twitter, but since that doesn't seem to be the case, we now have an X icon in our icons list for LocalGov Base.
4. Created PR to add an admin role by default to LocalGov Drupal.
5. Closed an issue with local task tabs for alert banners not showing for microsites. Thanks to Adnan for his patience with me on this, turns out it's working fine, but only for microsites 3+.
6. Elizabeth from Haringey Council suggested that the preview link module should have a button to quickly copy the preview link to your clipboard, so I created an issue and PR on Drupal.org for it, so all Drupal users can benefit, rather than just LGD users.
7. We've had a long-standing issue to enable redirect module by default. We'll, that's sorted now.
8. Everyone wants to track their usage of media items, right? So they know what pages each image/video/etc is used on. I created an update hook to make that happen.
9. A lot of content editors get confused by the "files" tab on admin/content. They click on it to see where files are used, but what they usually need is the "Usage" tab for media to see where that media item is used. We now have a PR open to remove the "Files" tab from all users unless a specific role requests it.
10. Darn, I was hoping to get to 10 items, but time has caught up with me. See you next week!

I honestly feel so privileged to get paid to work on LocalGov Drupal in a dedicated manner like this. Having this time will make LGD better for everyone. Thanks to Big Blue Door for sponsoring my time to work on this.

I mentioned in my last blog post that if agencies and organisations wanted to contribute more to open source but can't because they are busy with client work, then why not sponsor some one else to contribute for them.

If the person contributing is a seasoned contributor and ready to work on a project that you are invested in, it makes perfect sense. It also means that person can hit the ground running and start making an impact straight away. With this being the case, Big Blue Door got in contact with me and instead of offering me sponsorship of one day per week (which is what I was asking for), they offered two days per week.

This is great news and a quadruple win-win situation for:

1. LocalGov Drupal - we'll get to fix lots of issues in the backlog and perhaps work on some new ones
2. UK and Irish Councils - an even better LGD site for you, without you needing to pay anything
3. Big Blue Door - they get to have high quality contributions to the LocalGov Drupal project, showing themselves to be very conscientious community members
4. Me - I get paid for doing something I love

Please join me in thanking Big Blue Door for their very generous support of my open source development.

Having spoken to a lot of Drupal agencies recently, a common theme keeps emerging: we want to contribute more to open source/Drupal but we don't have the time due to client work, or we don't have people who are used to contributing.

That seems like a problem worth solving. It will mean more contributions to Drupal, faster iterations of Drupal features (let's get Starshot launched asap), and ultimately more Drupal credits for your agency.

How do we solve it? Simple, you find someone that is available for work currently, and is also well-used to contributing to Drupal, and perhaps is also a Drupal core maintainer, and you fund them. If you are wondering who, well ... me, for example. 

What will you get for funding a Drupal core developer?

• A mention on each comment on issues I am working on on Drupal.org (something like "Thanks to <agency name> for sponsoring my time to work on this issue").
• A credit for any issues I am working on (add me to your organisation on Drupal.org and I'll tag it as the organisation paying for the work).
• A mention at the top of any blog posts I write to explain an issue I am working on.
• A mention in any videos I create as a demo about any issue I am working on.
• One day per week of Drupal core contributions (or as much as you want to fund).

What initiatives do I want to work on?

• Starshot - the new Drupal CMS initiative launched at DrupalCon Portland last week.
• Umami - I'm currently a Drupal core maintainer for this
• Admin UI and JavaScript Modernisation Initiative
• Easy Out of the Box Initiative
• Others as they arrive
• Something that you want to assign to me

How do we get started?

This is the easy bit.

You send an email to mark@mark.ie and I'll get back to you asap to have a chat about how the engagement will work. Then we start working on it, you start getting Drupal.org credits, and Drupal gets better. 

Everyone's a winner!

This is what open source collaboration looks like. Thanks to:

• Chicken - Justine and Rupert for developing this module
• Will Callaghan for requesting it in a generic manner so all councils can benefit from it
• Essex County Council for funding
• Hammersmith and Fulham Council for managing it and creating the initial prototype
• Annertech (me!) for testing and suggestions

Drupal's content listing at admin/content shows us the creator of a node, but does not allow us to add a field to show us the last person who edited the node. 

I did some Googling for it, and it turns out the ability during the latter stages of Drupal 8 development, but I wasn't aware of it. I'd like to see this added to the default admin/content view so we wouldn't have to figure it out.

So ... here's how to do it:

1. Create a relationship to the The user ID of the author of the current revision.
2. Then use that relationship in the fields you want to show.

Here it is in video format:

Here's a module I created, funded by Essex County Council and based on a spec developed by Will Callaghan, that allows you to create taxonomy terms, then set paths (via a text field) on those taxonomy terms, and then attach those taxonomy terms to users. 

Now, when a user has a taxonomy term attached to them, they can only edit content that is within the range of that path.

I'm surprised this module didn't already exist.

It's available on Drupal.org at the Content Access by Path namespace.

Here it is in action: