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:

I put a snippet on a Slack channel recently suggesting that someone should use once() to make sure their code didn't run multiple times. And then I gave them this snippet to show how to use it:

const editFrequencys = once('allEditFrequencies', '.edit-frequency', context);

editFrequencys.forEach(editFrequency => {
  editFrequency.on('change', function() {
    $.ajax({
      method: "POST",
      url: "/frequency-select",
      data: { name: "John", location: "Boston" },
      dataType: "json"
    })
      .done(function( data ) {
        console.log("It's done!");
        console.log(data);
      });
  });
});

Job well done, Mark, you might say. Yes, but then the author asked me:

What are the different arguments about in the first line?
I've seen this code in searching for an answer, but nothing ever explains what/why the arguments for the "once" are for.

And that reminded me of a younger me. Me about 6 months ago, when I first tried to use once(). So here is the explanation I gave them:

const editFrequencys creates a variable for what you want to work on. It’s a plural, because once always returns an array. You could do something like const [editFrequency] to just return one item if you were sure there was only ever going to be one of the thing you are looking for on the page. But I find it better to return the array just in case in the future a second instance of the thing is on the page.

once() is the function that will ensure the code that is acting on your “thing” will only act once.

'allEditFrequencies' is a name that we assign to this item. You can assign anything to it basically, such as 'justSomeStuff'. This is then attached to the property in your DOM via a data attribute, such as data-once="allEditFrequencies" so JS knows which once function this item belongs to.

context is just the method that is going to be used to find your array. You could use document here, but if the page gets updated via ajax, then document will not be updated, so in Drupal terms, context is probably better.

If I got something wrong there, or there's something I should update, let me know.

The LocalGov Drupal Layouts module was created as part of the LGD Microsites platform, but contributed back to the core LGD project. However, it is not turned on by default (todo: propose it gets turned on by default), so I think a lot of people are not aware of it.

Here's a short demo of how to enable it and use it. Then you can extend it to add as many layout options as you want to your LGD layouts.

If you'd like to chat about how you might use this, connect with me on the LGD slack or via the Annertech contact form.

Creating a decision tree is quite easy using the Drupal Webform UI. Here's the outline:

1. Create the form
2. Add all the questions that you want
3. Use the "Conditions" tab in each question to set the conditions for what question shows where
4. On the settings page for the form, under "Email/Handlers" add a handler for the confirmation page settings for each potential response in the decision tree.

Here's a video outlining the steps:

Many (if not all) councils have been asking for a way to do "access control", whereby only certain editors can edit certain parts of the website. I put together the LocalGov Drupal Content Access Control module so we'd have a defined way of doing this and all councils can have a similar approach. 

Here's a short video explaining how it works (which might help people outside of councils who also need to set this up). In short:

1. Create a taxonomy called "Access Control".
2. Add terms to this.
3. Use this taxonomy in a "Workbench Access" scheme.
4. Add editors and/or roles to the site sections.
5. Add a field to content types that references the "Access Control" vocabulary.
6. Enjoy!

Drupal by default sets a pink background on unpublished nodes. We added this as a feature to LocalGov Drupal recently to distinguish between published and unpublished content. 

Editors were not very impressed with this because - especially on new websites - there's lots of whole sections that are unpublished. And when trying to preview a full section to stakeholders and nearly every page has a pink background, including all the items in entity reference fields and other listings, the site starts to not look like what was designed.

To get around this, I've proposed 2 site settings that can be enabled via the theme settings page if your theme uses LocalGov Base as its base theme.

1. Turn off the pink backgrounds (handy if you just want to turn them off temporarily while demoing your content and then back on again once the demo is over)
2. Add the word "Draft" to the title of any node that is unpublished (handy if the pink background is turned off more permanently).

Here's a short video to show it all working:

The code for this can been seen in this pull request on GitHub.