Apr 17 2019
Apr 17

DrupalCon 2019 was a bit different for me. I have attended previous DrupalCons, usually sitting in the back of the room just taking in all that I could from experts around the world. This year, however, I had the opportunity to be a speaker. Not only was I afforded the opportunity to speak, but I had two separate sessions accepted.

Talking the Talk

Being my first DrupalCon as a speaker, I might have had a few butterflies in my stomach when I arrived. Those quickly faded, and overall, my sessions on Stanford Cantor Arts Center Redesign and A Survey of Emerging Technology were very well received. I had an absolute blast presenting! Special shout-out to my partners in crime, Kristen Pol and Adam Bergstein, for making the transition from attendee to speaker fairly painless.

Stanford Cantor Arts Center Redesign

This talk was a broad review of our work with Stanford Cantor Arts Center that takes a deeper look at a few problems we faced during the build. There were complexities within the content structure and architecture that we needed to be able to accommodate. Flexibility was the most important part of this website. We walked through the solution to leverage UI Patterns module that allowed component based design, making the build process more practical while allowing content editors the ability to adjust as they see fit on certain areas of the site. 

Listen to the full talk on YouTube.

A Survey of Emerging Technology

Together, Adam Bergstein and I highlighted a set of tools that we know integrate well with Drupal and are used to tackle common roadblocks within the environment. I specifically spoke to the value of GraphQL and Gatsby.JS.

GraphQL provides a common interface for API queries. It is specifically notable for the ability to get information in a sole request, versus JSON requests that require multiple attempts before getting all the data. As far as its ability to play nice with Drupal, there is currrently a GraphQL module that is updated and supported by our community. The biggest benefit of using it within Drupal is for standardizing those onboarding into Drupal. Where they may hit roadblocks coming from the outside in, GraphQL makes the Drupal transition easier.

Gatsby.JS is a static site generator that uses static markup, but can still display dynamic information. What is great is you can bring your own backend into Gatsby.JS. Benefit, getting rid of a lot of vulnerabilities by not having any server-side code running. The vulnerability of a CMS is no longer a worry.

Other technologies covered were Hubspot, ElasticSearch, Pattern Lab, and Cypress.io.

You can watch the full video on YouTube.

More Than Presenting

Group of Hook 42 Team Members Working in Sprint Room

Beyond speaking, I had a fantastic time hanging out with the team, as usual. Every time we’re in the same location together I’m reminded of how talented, intelligent, and funny everyone is. It was especially awesome to get a chance to greet our three newest members of the team (Michael, Emanuel, and Lindsey) in person.

We spent a sizable chunk of pre-conference time sprinting on our company website, which was an amazing team-building exercise and really showed how much we can accomplish when we work together. So hopefully you’re reading this on the flashy, fancy new-and-improved hook42.com!

Overall, DrupalCon never ceases to provide an endless amount of opportunity. From spending time with colleagues, to working hard on new efforts, and even having new experiences like being a first-time speaker, I always look forward to what DrupalCon has to offer.

When I began my career at Hook 42, I made it a goal of mine to one day speak at DrupalCon. A long-term goal, but one that I worked very tirelessly to achieve. Getting the opportunity to share my expertise with others on the stage in Seattle felt like the perfect culmination of two years of hard work to get there. It felt amazing to check off my list.

Mar 12 2019
Mar 12

Every year community members from across the globe meet in Orlando for Florida Drupal Camp. This year Adam, Ryan, and Jonathan from Hook 42 attended. It was a fantastic time to connect with people, to learn, and enjoy some warmer weather. Plus, alligators!

Ryan and Adam led a training on connecting Drupal 8 and Gatsby.JS. The training utilized a set of Docker images that help people build everything from end-to-end on their own system. Attendees used the Umami demo, installed JSON API, and configured Gatsby.JS to pull recipes from Drupal. It was well attended and there was a lot of collaboration in the room. Our team appreciated all of those that attended - especially as we worked through technical and wifi issues. 

Ryan and Adam also gave a talk on emerging technology related to Drupal. Some of the topics included Cypress.io, Hubspot, ElasticSearch, GraphQL, Gatsby.JS, and Pattern Lab. It’s important for community members to find and use the right tool for the right job. As Drupal community members, we must be mindful of how these complementary technologies can serve us. You can watch the recording of the session on Drupal TV.

Team Member Reflections


I look forward to this camp each year, and once again this year did not disappoint. Thank you to “the Mikes”, Kyle, and Jordana for volunteering again. The time spent with the community was uplifting and encouraging - even if it was a bit tiring giving both a training and a session. The time spent with my colleagues Jonathan and Ryan, having barbeque, and drinking craft beer with the community all brought a lot of energy. I was able to reconnect with many friends and I always treasure those opportunities. Also, Jonathan and I unintentionally packed the same hoodies and Drupal Camp Asheville shirts. Twinsies!

The session quality was outstanding! Most notably, there were some incredibly great non-technical, people-focused sessions provided by Jordana Fung and Qymana Botts. I strongly recommend seeing both. Thanks, as always, to the amazing Kevin Thull, all sessions are recorded and posted to Drupal TV.
At the end of camp, on the contribution day, I was able to work on the proof-of-concept integrating SimplyTest.me and Tugboat QA. The result of which is a new Tugboat QA contributed module based on a Backdrop CMS module port.


This wasn’t just my first time to Florida Camp, it was my first time in the state of Florida in general! What a great experience. I had a great time at the camp and really enjoyed speaking with a wide array of folks about decoupled Drupal and Gatsby.js, both through the training Adam and I conducted as well as hallway conversations. Brian Perry’s talk comparing various static site generators and their compatibility with Drupal proved really insightful. I was really excited about his demo of the Tome static site generator, which runs within Drupal itself.

Thanks a ton to the organizers - the camp was a lot of fun and I look forward to attending again next year!


My second time at Florida Drupal Camp was as good as, if not better, than my first. As a Drupal Camp organizer myself, I find Florida Drupal Camp to be inspiring. They manage to pull off being extremely well organized while maintaining a very casual air to the whole weekend. 

As an attendee, I had a unique (for me) experience this year. I went to Drupal Camp Florida without a computer and it was great! Without a laptop always in front of me I found myself more attentive to the session and more engaged in the camp in general. I enjoyed it so much that I will likely avoid taking my computer to future camps.

The sessions I attended were all wonderful and there are a few I’m still thinking about today. Here is a quick list, and my takeaways:

  • How to keep Drupal relevant in the Git-based and API-driven CMS era
    The Drupal island appears to be shrinking as the overall landscape for approaches to web development grows. It doesn’t hurt keeping an eye on the new ways to solve old problems.
  • How to Hire and Fire Your Employer
    Always a fan of these “being human” talks. In this one, April encouraged me to continuously evaluate my values as a person and how they match any given employer. “Life is too short to be miserable” is a powerful perspective to maintain.
  • An Introduction to Gulp
    I’ve been using Gulp and similar technologies for a number of years, but have almost always used someone else’s configuration. Tim makes it look easy to get started writing my own tasks, and I’m really looking forward to doing so on my next project.
  • The problem with Paragraphs, a return to rich fields!
    Maybe the only actual Drupal session I attended, it’s always great to see Hawkeye and get his perspective. In this session he opened my eyes to some serious problems with the Drupal community’s go to approach to solving complicated fields, the paragraphs module. By the end of the session, I was ready to start making custom rich/composite/compound fields for future projects.

Another top-notch Drupal Camp Florida in the bag. I’ll definitely be back next year, and if you’ve never been I highly recommend it.

Mar 08 2019
Mar 08

Look out for Hook 42 at DrupalCon 2019 in Seattle!

It’s that time again, another DrupalCon is fast approaching and our team couldn’t be more excited for this year’s Seattle event. We’ve got a lot in store for you this year, from presentations, BOFs, sponsorships, partnership collaborations, and using our listening ears. You’ll find our team distributed all about.

We’re bringing a stacked line-up of knowledge and experiences to drop on 'ya this year. Not only that, we’re looking forward to hearing all the ups and downs you’ve had this past year, and how we’re all growing together within the Drupal community. 

Let’s get to sharing!


Join us at the Performance and Scalability Summit on Monday. Hook 42 and Tandem have worked with the Drupal Association to line up leading speakers to cover scaling performant Drupal websites to scaling efficient Drupal development teams. The Performance and Scalability Summit is the place for developers, DevOps professionals, decision makers, and other technical stakeholders to plan for growth.


To hear from our experts, find us at one of our talks where we’ll review insights our team has experienced first-hand and how we’re adapting to the new and old needs of evolving technology.

Database Query Optimization in Drupal

Kristen talks all things database, and walks through how to put the sluggish operations behind you to optimize your Drupal environment. Covering the basic optimization steps isn’t always enough, exploring options past the basics will help streamline your Drupal environment for both front-end and back-end users.

Accessibility Deep Dive Workshop

Aimee is teaming up with Caroline Boyden, from UC Berkeley, to take a closer look at accessibility. Together, they’ll use real-world examples of how accessibility is best implemented, and how every member of your team can be part of accessibility, from designers to developers to content authors and everything in between.

Which Accessibility Tools are Right for You?

Aimee breaks down the best tools for implementing and testing accessibility, and the benefits and areas of improvement for these tools. Taking a look at what is available today, and how your team can take advantage of these tools to increase your website’s accessibility.

Drupal 8 Case Study – Stanford Cantor Arts Center Redesign

Kristen and Ryan join forces to walk through one of Hook 42’s latest client projects. Focusing on the implementation of good design and development, and how Drupal was the perfect place to house the dynamic technical needs of the team at Stanford.

A Survey of Emerging Technologies That Complement Drupal

Adam and Ryan are teaming together to talk about the latest tech to take advantage of Drupal’s flexibility and ability to interact well with modern advancements on the web.

Considerations of Federated Search and Drupal

Adam shines the light into federated search, its importance, and how you can implement this applications within Drupal. Taking a close look at how to pair the application with Drupal to minimize risk and increase cross-platform communications.


Women in Drupal Luncheon

We’re proud to sponsor the Women in Drupal Luncheon, fostering inclusivity and empowerment within the Drupal community. We’ll gather to enjoy delicious food, talk shop, and relax amongst professionals.



VP of Engineering, Adam Bergstein maintains the SimplyTest.me service leverage by the Drupal community for testing and prototyping community contributions. Join him for a BOF on Wednesday! We want to chat with you all things about our go-to browser testing tool for all our Drupal projects.

Adam is also sorting out the Drupal Coffee Exchange meetup. 


Lingotek Session: Avoiding Trouble Spots When Creating a Multilingual Site

Our partner, Lingotek, has organized a session revolving around the challenges with multilingual websites. Through the session you’ll learn about common challenges with multilingual websites, and how you can get ahead of those issues. We’ll be there to support Lingotek and help answer questions during the session.

We Hope To See You There

If you haven’t already registered for DrupalCon Seattle, get on it! We’re ready for yet another amazing DrupalCon adventure, and we’re looking forward to seeing old and new faces in the crowd.



Dec 13 2018
Dec 13

This is the first of many articles about why and how to give back to the community. The information can be used by individuals, agencies, and companies that want to increase their community contribution efforts. 

'Tis the season for giving. A time of giving thanks for the blessing of the harvest and of the preceding year. A time of light in the dark of winter; a season of reflection and thanks. I’d like to recognize the work and efforts of the Drupal Community and reflect on Hook 42’s historic contributions; additionally, I'd like to share how we contribute and how you can contribute more. 

But why listen to Hook 42? We are not one of the largest Drupal agencies; however, Hook 42 was ranked 18th in the list of the global contributors by Dries. We also strategically shaped and sponsored the community efforts of one of the top 30 contributors to the project. 

Hook 42 has a fairly humble approach when sharing our community contributions data. We usually let our team’s commit numbers, sessions, logos, and event organization speak for our continued dedication to the fostering the Drupal community. 

For full disclosure, Kristen Pol and Aimee Degnan (myself) are co-founders / owners of Hook 42, a full-service web development agency specializing in Drupal. We are based out of San Francisco and we have team members distributed across the United States.

Make a Commitment to Contribution

First of all, you must want to contribute. Everyone has different reasons to contribute and how you personally contribute is your own path. It is a deliberate decision that must be turned into action.

The first steps into contribution may be attending a Drupal users group, camp, or logging into Slack or IRC for support. At this point, you meet the community and learn how to further contribute. Hopefully, the Community has been inviting enough that you want to stay. :)

When Kristen and I started Hook 42, we chose “Contribute to Community” as one of our core values. This decision created the foundation for our culture of contribution. We both personally contributed to the project and community in different ways and found great value from giving back. All of our team members have the desire to contribute to community efforts; the passion and self-starting ability to contribute is vital.

Another one of our values, “Ongoing Education and Improvement”, is a strong motivator for our contribution efforts. The Drupal project, and its supporting events, provide a fantastic opportunity for professional development. Coding, documentation, speaking, organization, and volunteerism; there are so many opportunities for growth that are beyond our client work or formal training classes.

I want to thank those organizations and individuals that have made community contributions a deliberate part of their work and life. We are not the only company to do so. We are not the only individuals to do so.

Invest in Contribution

Once you decide contribution is important, a real investment must be made. Contribution takes time. It takes skill. It takes practice. And it also takes money. 

A patch isn’t going to write itself, test itself, or be committed back into the project itself. Documentation must be written and copy edited. Events need to be sponsored and organized.

Hook 42 sponsors 15% of the team’s overall work hours to community contribution. Doing the math, 15% is roughly 4,000 - 4,500 hours of work per year donated to the Drupal community. That is time Hook 42 is not making a profit and is considered a completely operational cost. The work is performed within a normal 40 hour work week for our team members; another value of ours is "Strive for Work and Life Balance".

Our clients also sponsor contributions through the course of project work, session presentations, and case studies.

The 15% metric of sponsored community time does not include the amount of money spent for sponsorship, travel, or one-off support of community contributions like DUG dinners, code sprint snacks, and other community-focused spend. 

An individual’s personal level of investment will probably be much different from a business. The personal investment may include patches, testing, sessions, and camp attendance but is often constrained by personal budget and time one is wanting to commit.

Personally, Kristen and I contribute differently. Both of us organize events, speak, attend conferences, work on core initiatives, and mentor individuals within the community and the team. I contribute less code because my role is more related to business topics (although I’m highly technical); whereas, Kristen’s contributions are more commit and documentation related. This is just an example of how contribution profiles may differ.

From a business perspective, it is both of our jobs to provide a stable environment and work to provide our team members the opportunity to contribute. Consider us “Community Force Multipliers” that strategically align our team’s work with community efforts while we, personally, do less of the commit-centric work.

Many of our team members, including Kristen and myself, contribute additional personal time on top of work-sponsored hours. Those that do are passionate about the community and are active in event organization, preparing sessions and trainings, and participating in sprints. Plus, Kristen and I have to keep the business running regardless of our personal community efforts. Someone has got to keep the lights on. 

I want to thank those organizations and individuals that have made the investment in the community. We are not the only company to do so. We are not the only individuals to do so.

Ongoing Commitment to Contribution

But why do Kristen and I choose to contribute so much to the community? Why do we keep contributing? The two of us drive Hook 42’s budget and time invested in community efforts. Don’t we want more profit or more money in our pockets?

As business owners, we believe that supporting the Drupal project and community ecosystem is an investment in our ongoing business. All people using Drupal must contribute - at their own ability level - to Drupal to keep the platform viable and supported. That contribution can be as easy as active use of the platform.

Improving Drupal isn’t just about benefits to our company, or benefits to Drupal independent contractors, and other Drupal service providers. Improving Drupal benefits organizations using Drupal, so they can have confidence that their choice is a sound investment over time. Again, contribution as a business is not about us, it is about supporting people building their businesses on Drupal.

As people managers, the community ecosystem and the Drupal and Drupal-adjacent technologies provide a great environment for ongoing learning and professional development for our team. Kristen, myself, and Adam help our team members and others in the community find the best fit of work for their goals.

As individuals, honestly, we love the people and the community environment. One of our other company values is “Be Ethically and Morally Good”. As good members of the community, we understand that our individual choices and actions can benefit the greater good of Drupal. 

But I have to admit, sometimes it is a challenge. For all who choose to contribute, you will also be more visible to a diverse, global group of individuals. You may receive criticism for your work or opinions that may not seem agreeable. Kristen and I have been told that the support we provide, both personally and through the business, is not enough. Perhaps without visibility to the actual data of our total contributions, others may not understand the amount of our personal investment in the project. Thankfully, that was an edge case and not the norm. Overall, most community members have provided positive feedback to our sponsorship efforts.

Why don’t we just give up? How much more are we supposed to do? How much more are we supposed to give?

Honestly, constructive criticism and differing opinions make the product and the people improve. No one improves if they are unaware there is room for change.

We constantly renew our commitment to community because we love the people we work with. It brings us great joy to work with such creative and enthusiastic people.

I want to thank those organizations and individuals that recommit their efforts to the community, even after heavy public criticisms. We are not the only company to do so. We are not the only individuals to do so.

Season of Giving Beyond Drupal

I want to thank those organizations and individuals that provide donations to charities throughout the year at different community events. This type of altruistic approach to charitable donations represents the quality of the people in the Drupal community.

Hook 42 has donated to the following charitable organizations chosen by our team members. Some of the organizations were selected by multiple members:

Learn how you can be a top contributor in our next Community Post: The How-to Guide to Successful Contribution.

Dec 10 2018
Dec 10

Nowadays everyone has an API and it's fairly common to want a website you're working on to fetch data from a 3rd party API. That's because pulling 3rd party data into your website can not only enriches your website's content, but doing so can prevent the need to duplicate commonly needed data.

API provided data could include displaying weather information, going through drupal.org projects, looking through census results, or even displaying Magic the Gathering card data. In fact, every WordPress site comes with an active JSON API out of the box.

There really is an API for almost anything. It's no surprise that you'll eventually want to consume some random API while developing a Drupal website. Enough of the sales pitch, let's get started consuming JSON APIs.

The Plan:

  1. Look at what it takes to fetch and consume JSON data in general.
  2. Explore the popular Guzzle PHP library.
  3. Create a Drupal 8 module that consumes an API and displays the data on your website.

Seems pretty straightforward huh? I think so too, but before we go any further let's define some of the terms that appear throughout this post.

  • API - Application Programming Interface. Literally, "a thing developers can use to interact with another program".
  • Request - An interaction with a web API. Very similar to visiting a website in your browser. When you visit a website in your browser, you are making a "request" to the website's server.
  • Base URI - Part of a URL that is the root of a web API request. This tends to be a domain name such as "api.mywebsite.com", but can also include a path such as "mywebsite.com/api".
  • Endpoint - Part of the URL for an API request that usually defines what type of data you are requesting. For example, one of the most common WordPress API endpoints is "posts", which retrieves Posts from the WordPress website.
  • Query Parameters - Part of the URL for an API request that further describes the specific data you are requesting. Query parameters look like key-value pairs within the URL for the API request.

Here is an example on an API request URL:

And here is how that API request URL breaks down into the terms defined above:

  • Base URI - http://demo.wp-api.org/wp-json/wp/v2/
  • Endpoint - posts
  • Query Parameters - ?per_page=2

Hopefully that helps clarify some of the terminology used throughout the rest of this post.

Getting Started: Fetching JSON in PHP

The first thing we want to look at are the basics of getting data from an API. We need the following things:

  1. A public API that will provide us with data.
  2. A way to visit the API and get its data.
  3. A method of converting the raw data the API gives us into an array so we can easily process and output it as we see fit.

Broken down into their tiniest pieces, each of the above needs are fairly straightforward. Out of the box, PHP provides us with a function that handles both visiting an API and getting its data in file_get_contents(), as well as another function for converting that raw string data into an array in json_decode().

As for the public API… I'd like to introduce you to Cat Facts, a public API that will provide us with all the facts about cats we could ever want!

Let's put all these pieces together and write a simple PHP script that will consume the Cat Facts JSON data.

$data = file_get_contents('https://cat-fact.herokuapp.com/facts/random?amount=2');
$cat_facts = json_decode($data, TRUE);

foreach ($cat_facts as $cat_fact) {
  print "<h3>".$cat_fact['text']."</h3>";


There we go. Now we can use this technique to get as many random Cat Facts as we want (up to 500 per request). But before we continue, let's break down this script a bit and see what it's doing.

  1. First we use file_get_contents() to request the data from the API.
    (The response data comes back to us in the form of a string.)
  2. Next we convert it into an Array using the json_decode() function.
  3. Now that the data is an array, we can loop through it and output all of our brand new cat facts. Outstanding!

Note: I didn't make up the URL shown in this example, I read the documentation. You can visit that API request URL directly and see what the response data looks like. Go ahead, I'll wait here…

… Welcome back!

Check this out: Most APIs you interact with will have its own documentation that you should use when planning your project. If you find yourself struggling to figure out how to get data from an API, look for more documentation. Documentation is king when dealing with APIs. The better the documentation, the better the API in my opinion.

Object Oriented API Requests with Guzzle

Now that we have a decent understanding of the main points of requesting data from an API, let's take a look at how we might do that in a more practical and modern way. Let's use the very popular PHP HTTP client named Guzzle to do basically the same thing we just did above.

The main differences in using Guzzle are mostly around the abstractions provided by Guzzle's Client library. Rather than trying to describe each difference out of context, let's look at an example:

require 'vendor/autoload.php';

$client = new \GuzzleHttp\Client([
  'base_uri' => 'https://cat-fact.herokuapp.com/',

$response = $client->get('facts/random', [
  'query' => [
    'amount' => 2,

$cat_facts = json_decode($response->getBody(), TRUE);

foreach ($cat_facts as $cat_fact) {
  print "<h3>".$cat_fact['text']."</h3>";

Let's paws for a moment and review what has changed and why:

  1. The first thing to note is that we've created a new instance of Guzzle's Client object and passed in some parameters as an array. Rather than provide the entire URI for the API's endpoint along with query parameters in one string like before ('https://cat-fact.herokuapp.com/facts/random?amount=2'), we will instantiate the client with just the base URI for the API in general. This way we can easily make multiple requests to multiple endpoints with the same Client object.
  2. Next, we use the Client's get() method to request a specific endpoint of 'facts/random'. Internally Guzzle will combine the endpoint with the base_uri we provided during object instantiation.
  3. Additionally, we provide an array of query parameters to the get() method. Internally Guzzle will convert this array into a query string that looks like this '?amount=2' and append it to the URL before submitting the request to the API.
  4. Unlike file_get_contents(), the Guzzle client returns a Response object. This object contains much more information about the reply from the API, as well as the contents of the response.
  5. Finally, we access the contents of the response by using the getBody() method on the Response object.

It may seem like a lot has changed from our first example, but I highly recommend becoming more comfortable with this approach. Not only is it significantly more powerful and flexible than the file_get_contents() approach, but also because Drupal 8 uses the Guzzle library.

Ultimately, both this and the previous example are doing the exact same things. They are both visiting the Cat Facts API and fetching data.

Now that we are comfortable with requesting data from an API (aka, visiting a URL), I think we're ready to do this in Drupal 8.

Guzzle in Drupal 8

The plan is simple; create a Drupal 8 module that fetches cat facts from the Cat Facts API and displays those facts in a Block.

There are a few ways to accomplish this, but we'll start with the most basic. Have a look at this custom Block:


namespace Drupal\cat_facts\Plugin\Block;

use Drupal\Component\Serialization\Json;
use Drupal\Core\Block\BlockBase;

 * Block of Cat Facts... you can't make this stuff up.
 * @Block(
 *   id = "cat_facts_block",
 *   admin_label = @Translation("Cat Facts")
 * )
class CatFacts extends BlockBase {

   * {@inheritdoc}
  public function build() {
    /** @var \GuzzleHttp\Client $client */
    $client = \Drupal::service('http_client_factory')->fromOptions([
      'base_uri' => 'https://cat-fact.herokuapp.com/',

    $response = $client->get('facts/random', [
      'query' => [
        'amount' => 2,

    $cat_facts = Json::decode($response->getBody());
    $items = [];

    foreach ($cat_facts as $cat_fact) {
      $items[] = $cat_fact['text'];

    return [
      '#theme' => 'item_list',
      '#items' => $items,


Block Output:

At first this looks like a lot more code, but most of the new stuff is the code necessary to create a Drupal 8 block. Rather than focus on that, let's look at the important difference between this and the previous example.

  1. Drupal core provides a service designed to create HTTP clients: 'http_client_factory'. This service has a method named fromOptions() which accepts an array, just like the Guzzle Client constructor did before. We even passed in the exact same parameter.
  2. Instead of calling json_decode() function, we use the Drupal provided Json::decode() method.

Note: We could have instantiated our own Guzzle Client object, but the above approach has the following added benefits:

  • First, Drupal is going to merge our options array into a set of its own options that provide some HTTP request best practices.
  • Second, using this method (somewhat) future proofs us from major changes in the Guzzle library. For example, if Drupal improves its http_client_factory service, or even decides to switch libraries all together, we'd like to believe that the core developers will take on the burden of ensuring the http_client_factory service still works the way we expect.
  • The same reasoning applies to using the Json::decode() method Drupal provides as opposed to the json_decode() function.

Generally, whenever Drupal provides a way to do something, you should use the Drupal way.

Now this is all very good, we're making API requests the "Drupal Way" and we can place it almost anywhere on our site with this handy block.

But, I know what you're thinking. You're thinking, "Jonathan, Cat Facts shouldn't be contained to just a block. What if I want to use cat facts somewhere else on the site? Or what if another contributed module wants to make use of these awesome Cat Facts in their own module?"

And you're totally right to be thinking that. Hence...

Cat Facts as a Service (CFaaS)

There is no better way to make Cat Facts available to other non-block parts of your site and other contributed modules than to provide a Cat Fact service in our own module. I can see it now, with such a powerful feature our Cat Facts module will soon be a dependency of almost every other popular Drupal 8 module.

First thing we need to do is define our new Cat Facts service in our module's services file.


    class: Drupal\cat_facts\CatFactsClient
      - '@http_client_factory'


Next, we need to write this new CatFactsClient class. It will look relatively similar to the work we've done already; but, this time instead of calling the Drupal::service() method, we'll use dependency injection to provide our CatFactsClient class with the http_client_factory core service automatically.



namespace Drupal\cat_facts;

use Drupal\Component\Serialization\Json;

class CatFactsClient {

   * @var \GuzzleHttp\Client
  protected $client;

   * CatFactsClient constructor.
   * @param $http_client_factory \Drupal\Core\Http\ClientFactory
  public function __construct($http_client_factory) {
    $this->client = $http_client_factory->fromOptions([
      'base_uri' => 'https://cat-fact.herokuapp.com/',

   * Get some random cat facts.
   * @param int $amount
   * @return array
  public function random($amount = 1) {
    $response = $this->client->get('facts/random', [
      'query' => [
        'amount' => $amount

    return Json::decode($response->getBody());


What we've done here is create a simple class that focuses solely on the Cat Facts API. It abstracts most of the work you would normally have to do when you need to request data from the API by providing a method named random(). This method performs the HTTP request and return a decoded array of data back to the caller.

Finally, all we need to do is update our Cat Facts block to allow our new service to be injected into it as a dependency.



namespace Drupal\cat_facts\Plugin\Block;

use Drupal\Core\Block\BlockBase;
use Drupal\Core\Plugin\ContainerFactoryPluginInterface;
use Symfony\Component\DependencyInjection\ContainerInterface;

 * Block of Cat Facts... you can't make this stuff up.
 * @Block(
 *   id = "cat_facts_block",
 *   admin_label = @Translation("Cat Facts")
 * )
class CatFacts extends BlockBase implements ContainerFactoryPluginInterface {

   * @var \Drupal\cat_facts\CatFactsClient
  protected $catFactsClient;

   * CatFacts constructor.
   * @param array $configuration
   * @param $plugin_id
   * @param $plugin_definition
   * @param $cat_facts_client \Drupal\cat_facts\CatFactsClient
  public function __construct(array $configuration, $plugin_id, $plugin_definition, $cat_facts_client) {
    parent::__construct($configuration, $plugin_id, $plugin_definition);
    $this->catFactsClient = $cat_facts_client;

   * {@inheritdoc}
  public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition) {
    return new static(

   * {@inheritdoc}
  public function build() {
    $cat_facts = $this->catFactsClient->random(2);
    $items = [];

    foreach ($cat_facts as $cat_fact) {
      $items[] = $cat_fact['text'];

    return [
      '#theme' => 'item_list',
      '#items' => $items,


And there we have it! Now our block has the cat_facts_client service injected into it during creation. And rather than the block making its own Guzzle Client and API calls, it uses our shiny new service.

Ya feline it?

View module code on GitHub.

Nov 08 2018
Nov 08

Now that I’ve settled back down in Alaska after a fun trip to Berkeley for BADCamp, I’m finally digesting all of the info I gathered throughout the week. As always, it was cool to look over the schedule and see what topics were getting a lot of attention; and, without a doubt, it seemed like GatsbyJS was the hot-ticket item this year. So here’s a primer on what GatsbyJS is and why the Drupal community seems so head-over-heels for this up and coming site generator.

What is GatsbyJS?

For the uninitiated, GatsbyJS is a static site generator for React which allows you to compose a website using React components and JSX. Then, with a “Gatsby build” command, the entire React app gets compiled into a set of static HTML, JavaScript, and CSS files.

However, this is nothing new. Static site generators like Jekyll or Hugo have been doing this for years. So, what makes Gatsby so popular, especially within the Drupal community? Judging by the sentiments I heard from the four sessions on Gatsby I attended at BADCamp, I noticed that folks tended to gravitate toward a few essential features that made Gatsby appealing, not only as an integration with a Drupal backend but also more broadly.

Gatsby’s Drupal Source Plugin

The feature most commonly cited in BADCamp talks about Gatsby was the source plugin ecosystem, which allows a developer to define a backend “source” from which Gatsby will build pages. There is a robust and well-developed plugin for Drupal 8 (gatsby-source-drupal), which allows Gatsby to programmatically create content from Drupal’s content types, taxonomies, as well as blocks and menus.

The plugin works like this: first, you must enable the JSON API module, which exposes routes and schemas that help Gatsby import your content into your Gatsby application. Then, on the Gatsby side, you are able to query the data from your Drupal site using GraphQL and render the query results to various React components, such as page templates.

Build/Deploy Workflow

Secondly, the architecture around deploying/building a Gatsby site lends itself well to working with Drupal - using something like the Webhooks module, you can have your Gatsby site rebuild (and thus, pull new content) on every node create, update, or delete operation, and so forth.

This is very important, considering that most static sites are perceived as being labor intensive (in the sense that every time content is updated, someone needs to recompile the site); but, to hear Gatsby co-founder Sam Bhagwat talk about it, the ready availability of on-demand build triggers and integrations makes your static site actually perform much more like a cache. However, it’s the sort of cache that doesn’t require maintaining a highly technical caching stack like Varnish or Memcache. After the minute or two it takes for the build step to complete, your changes have completely propagated and site visitors are being served the new content.


Love it or hate it, React is here to stay. It is rapidly becoming the most common front-end stack in web development. Although it may not be for everyone, most developers who have spent the time to learn React tend to fall hard for it. Heck, this year’s Stack Overflow Annual Developer Survey puts React as one of the most “loved” frameworks by developers this last year, with 69.4% of respondents reporting that they enjoy working with React. Obviously, something is working for React in terms of developer experience. Being able to implement a React front-end without the architectural concerns of a complete decoupled solution certainly seems to be one of the bigger motivating factors behind Gatsby’s adoption among Drupal developers.


Last, but certainly not least, Gatsby’s appeal comes largely from speed. As mentioned above, since everything is served from static files, Gatsby sites load really fast. Without any server-side code to execute, the only limitations on performance are in the size of HTML/CSS/JS bundles being served over the network. When folks in a traditional Drupal site (or any other monolithic CMS) concoct solutions for better performance there are a few usual suspects:

  • better caching
  • reducing bundle sizes (minifying JS and CSS, for example)
  • optimizing images
  • serving non-dynamic site files (such as images) from a CDN

Out of the gate, a Gatsby site effectively implements all of these features by default. Since the entire site is a set of static files, your content is effectively ‘cached’ to the state of your website as of the last executed build, and the flat files that are generated from the build perform similarly to cache catch. Likewise, because Gatsby runs a build step, our entire HTML/CSS/JS bundle is minified from source using Webpack. No configuration required! Gatsby also comes pre-wired with a bunch of image optimization, including using the Sharp image processing library and progressive image loading to get a contentful, interactive page rendered as quickly as possible. And lastly, with a completely static site the most common way of hosting the site is through a CDN - some popular ones among Drupalers who use Gatsby include Netlify and Amazon S3. On top of all of that, Gatsby also has some other nifty built-in features like prefetching, which means that after the initial page load you’ll get lightning-quick performance between internal pages on your site.


Of course, most folks discussing Gatsby + Drupal implementations at BADCamp were quick to acknowledge Gatsby’s limitations. First, and most notable among the limitations, is the inability to use conventional user-submitted data. If you wanted to define a webform and render those results into a views-generated table, that would be pretty straightforward in a conventional Drupal 8 site. In a Gatsby site, however, it would be much more complicated. Likewise, for many of the ‘nice to have’ out of the box things that Drupal gives us - authentication, custom user roles, and access restriction, etc. – they all need to be effectively re-engineered if we want to implement them on our Gatsby front-end. That said, we could certainly continue to do many of those things in Drupal, but in the emerging conventional patterns of using Gatsby and Drupal together, it is unclear what the ‘best practices’ method is for handling those use cases.

All in all...

I think it’s really interesting to see this attention and centralization on Gatsby as a defacto solution for decoupled Drupal sites. While there are plenty of limitations, Gatsby seems like an interesting solution for some of the characteristic decoupled problems that many decoupled Drupal devs are very familiar with by now.

And, as always, this year’s BADCamp was really great to get a chance to see the Hook 42 team – it’s amazing that we “see” each other so often online, but once we’re all together I’m reminded of what a smart, funny, and fun group of people we are. Can’t wait to see everyone again!

Oct 17 2018
Oct 17

Keyboard accessibility is vital, as many assistive devices emulate the keyboard. Using semantic HTML one can achieve an accessible User Interface (UI) with less code than non-semantic markup.

By managing and guiding focus with semantic HTML, developing an accessible UI is rather easy. Semantic HTML plays an important role in not only accessibility but SEO (Search Engine Optimization) as well. Although we are aware of it, it's often overlooked.

In September’s accessibility talk, Sarbbottam Bandyopadhyay shared the trade-offs of using semantic vs non-semantic markup with an everyday example. He also shared how to manage and guide focus. It was a brief presentation emphasizing the various aspects of keyboard accessibility. He concluded with a brief introduction to WAI-ARIA.

Sarbbottam is a frontend engineer, with more than 14 years experience. He currently works at LinkedIn. He is part of LinkedIn's core accessibility team, focusing primarily on web accessibility. He’s been involved with web accessibility since his Yahoo days.


Keyboard Accessibility is addressed in the “Operable” principle of the WCAG: Web Content Accessibility Guidelines.

Many users with motor disabilities rely on keyboard navigation. Using a mouse or trackpad can be difficult because it takes a lot of fine motor skills.

WCAG: Web Content Accessibility Guidelines 2.0 - P-O-U-R:

P - Perceivable: Information and user interface components must be presentable to users in ways they can perceive.

O - Operable: User interface components and navigation must be operable.

U - Understandable: Information and the operation of user interface must be understandable.

R - Robust: Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

The WCAG 2 Quick reference guide has done an excellent job organizing and categorizing the POUR guidelines.

Many assistive devices emulate the keyboard

To be keyboard accessible, the website’s user interface must be navigable and operable via the keyboard. Arrows are used for widgets and groups; for example, radio groups or dropdowns.

Tab and arrow keys are used primarily to navigate. 

Enter and space are the primary keys used to operate.

Most common issues:

Mouse only interaction:

This an interaction that can only be accessed using a mouse or pointing device. There is no way a keyboard user can access this functionality.

No focus indicator:

Focus indicators visually identify the current active element on the screen. The focus indicator is often suppressed using CSS. As a result, keyboard-only users are not being able to access content or know where they are on the screen.

Sarbottom has developed a Chrome extension, called Focus Indicator, which forces focus on active highlighted elements.

Focus indicator is the equivalent to mouse pointer, so, 'focus outline: none' is equivalent to 'cursor: none'. We wouldn’t use 'cursor: none', so we shouldn’t use 'focus outline: none'.

Non-deterministic navigation:

It is expected that a tab press will focus on the next visible element in a logical order. The tab order must be in sync with the visual order. When the tab order does not match a user’s expectations, it creates a cognitive overhead.

To have deterministic tab order, avoid using positive tab indexes and CSS to change the visual order. Rely on the DOM (Document Object Model) order for for visual and tab order.

Efficient navigation:

A keyboard user expects the actionable elements in a dynamic apps UI to be navigated by a subsequent tab press.

We can avoid these common issues and pitfalls

Use Semantic HTML

  • It is not only important for accessibility, it is important for SEO
  • Semantic HTML allows the markup to be system, software, or machine interpretable.
  • Using semantic HTML results in less code.


ARIA or WAI+ARIA (Accessible Rich Internet Application) is a set of additional HTML elements that enhance the accessibility of web content by providing extra information.

There are three areas of ARIA attributes:

  • Role - defines what an element is or what it does.
  • State - conveys the current state of the element.
  • Property - adds additional information to an element, like relationship.

Note: The semantic information provided by ARIA attributes supersedes the native HTML semantics.

The first rule of ARIA is to not use ARIA.

Focus management:

By managing focus, we can ensure that the dynamic interaction and UI transitions are accessible. On UI updates, focus the corresponding HTML node programmatically. An HTML element can be focused by JavaScript invoking the focus method upon it. Focusing a container programmatically serves as a guided context switch.

Any subsequent tab press will focus the next focusable element, which enhances the keyboard user’s experience.

Guided Focus Management:

Guided focus management enhances the keyboard user’s experience. It allows the screen reader to read out the textual content of the focused container letting a visually challenged user be aware of UI updates. There are situations when the focus cannot be shifted from the context.

WAI-ARIA can be used to provide spoken feedback.

To wrap it up...

Get romantic with semantic and focus on focusing.

YouTube Video

Accessibility Talks September 2018 - Sarbbottam Bandyopadhyay - Love Thy Keyboard

Links mentioned in the talk:

Drupal Accessibility Group

Join the Accessibility group on Drupal.org for hints, tips, discussions, and patch proposals to help make Drupal more inclusive.

A11yTalks on Twitter

Follow us on Twitter and use the hashtag #a11ytalks to follow the conversation.

Sep 23 2018
Sep 23

HubSpot provides a powerful combination of customer relationship management (CRM) features and insights that can help organize and maintain business processes tied to customers. Drupal is a key digital platform for businesses, especially for inbound customer engagement, marketing initiatives, and 3rd party integrations. The two systems are highly complementary and deserve consideration for logically separating the responsibilities of digital engagement and customer relationship management. Additionally, both HubSpot and Drupal are very flexible and customizable. As an example, both systems support extensible data structures through custom fields in HubSpot and through the entity system in Drupal that allow for implementation-specific data to be stored and maintained.

Federated Drupal + HubSpot Approach

So you like the idea of using a CRM, but is it really worth all the trouble to integrate it tightly with your Drupal site? Are you afraid of commitment? There’s an interim step you can take before getting married to using HubSpot as your CRM.

If your data isn’t updated multiple times a day, you can work with HubSpot without tightly coupling your data integration. This approach involves using HubSpot’s batch update API. For example, with a regularly scheduled job to grab your active records and upload the relevant fields, you can keep HubSpot aware of your more recent data such as contact information. You get all of the HubSpot goodness without having to change your Drupal code since you get the data directly from your database.

We applied this approach for a Drupal system that isn't really a standard "website" but, instead, a very complex web application with a regularly-updated, separate data warehouse. Users are selected for data inclusion after a series of prior steps involving the end user, customer relations, and third parties. There are hundreds of these records a day which is only a very tiny subset of the site's daily data.

This approach leveraged the data warehouse in AWS, but you could do it against your production database as long as you keep an eye on query efficiency and server load. A CRON job to retrieve updated data was implemented in AWS Lambda, their serverless code platform, but it could also be implemented with a CRON hook in Drupal. While Lambda offers lots of coding choices, PHP isn’t one of them. Fortunately Python is. This approach also allowed us to rapidly prototype and implement our solution without impacting the production system.

Lambda jobs automatically log their output with AWS CloudWatch. After becoming familiar with HubSpot API errors, we built CloudWatch alarms which report to Simple Notification Service (SNS) for notification.

Unified Drupal + HubSpot Approach

While it's more advanced and complex, Drupal’s APIs allow for a much more refined, tighter integration if it is desirable. HubSpot maintains web service APIs for all of its various data objects. Developers can leverage these APIs and the various hooks/events within Drupal to synchronize data bidirectionally.

One common use case is a form in Drupal that end users engage with. The HubSpot module offers Webform integration specifically to HubSpot’s Leads feature. This is a concise, but relevant, single-direction use case in which Drupal can send Webform submissions to HubSpot. This allows for capturing inbound leads within a Drupal system and synchronizing that data to HubSpot.

Drupal’s development framework also supports more nuanced and implementation-specific approaches beyond just the Drupal Webform and HubSpot Leads integration. The HubSpot API module leverages a Composer dependency and Drupal service to integrate a PHP SDK within the Drupal application. This service can be programmatically invoked in any Drupal hook or event. Most CRUD-related runtime hooks programmed into a module allow for any data or transaction to be sent to a corresponding HubSpot entity. For instance, having a user-related hook to synchronize specific Drupal users with HubSpot customers can allow for interactive Drupal applications (commerce, collaboration platforms, etc.) to automatically send customer-related information from Drupal user profiles.

Drupal offers other advanced integration options with HubSpot. Drupal’s CRON system can be used to routinely pull data from HubSpot. This is helpful for creating advanced dashboards and data visualization within Drupal that is potentially tied to a single user-based experience. For instance, a user in Drupal could have a unified experience in which their HubSpot campaign data can be shown in a single dashboard in Drupal without potentially having to log into multiple systems.

The user-based example can be extended with some other key features of Drupal’s provided framework:

  1. Drupal’s Entity API can be used to create a custom entity to track unprocessed users and the state of HubSpot-related operations within Drupal.
  2. Reports can be generated in Views to easily list the tracked entities, like when they were created, when they were processed, their state, and more.
  3. Drupal’s log subsystem can maintain the set of activities tied to the user tracking entities and store HubSpot-generated responses from the API. This helps with failures, which is common for large scale sites with HubSpot’s API rate limiting.
  4. Drupal’s queue subsystem can offer opportunities to leverage CRON in staggering user requests instead of at runtime. This is advantageous should the HubSpot API go down or have slow performance, as there is a built-in failure state. Additionally, operations can be batched which helps avoid hitting API rate limits.


Drupal and HubSpot have a lot to offer each other as complementary solutions. Whether you want a more lightweight, federated approach or a tightly-coupled integrated approach, both Drupal and HubSpot offer enough extensibility through their frameworks and APIs to make even the most complex of use cases happen.

Sep 21 2018
Sep 21

The BADCamp Circus is coming to town for 4 whole days! From cities near and far, Drupalists are converging in Berkeley very soon for this year’s circus-themed BADCamp!

Join Hook 42 under the bigtop for 3 unique sessions. We’ll be sharing our thoughts on redesigning the Stanford Cantor Arts Center website, accessibility tooling, and creating custom Drupal 8 modules. Of course, the whole team will be there too, collaborating with new and old friends alike.

Join us as we flex our Drupal muscles, perform daring acts of development, and add to the general merriment of the Drupal community. BADCamp 2018 is sure to not disappoint!


Drupal 8 Case Study – Stanford Cantor Arts Center Redesign

Ryan Bateman and Kristen Pol | Friday, October 26, 2:30 - 3:15 PM | Sibley

In the Spring of 2017, Stanford’s Cantor Arts Center came to Hook 42 with a project to redesign their aging website with a shiny new Drupal 8 website that would allow the museum’s exemplary visual arts exhibits and photographic assets take center stage. What followed was a development cycle full of rigorous content strategy, front-end design, and back-end development that culminated in the newly-launched Cantor Arts Center website.

This session will expand upon our methodology and thought process in arriving at each aspect of the site’s development, including:

Intended Audience:

Anyone interested in content strategy, migrations, and flexible components will benefit from this session.

Which Accessibility Tools Are Right For You?

Aimee Degnan | Saturday, October 26, 11:15 AM-12:00 PM | Tilden

As an organization who needs to step up their accessibility (a11y) compliance, accessibility testing and remediation is a big deal.

Accessibility testing has a lot of moving parts! There are so many tools. So many! Plugins, suites, crawlers, dashboards, CI tests, and more.

  • Which one is right for you?
  • Will only one fit all of your needs? ;)
  • Build vs. buy some vs. buy vs. free? Is "free" free?

This is not a session about "what tools did our team use". This is a broader overview of the a11y testing tool types, challenges and benefits of the different types, rough costs (when applicable), and the best use cases for them.

When searching for tools, you can find lists of tools, but not comprehensive comparisons of tools to make the decision of which one(s) to use and buy for your need.

We compared a vast amount of tools to analyze and choose the best for our need as a digital agency specializing in accessible design and development and for our clients' needs as public entities requiring multiple levels of compliance.

A developer's tool needs (and budget) may be much different than a larger organizations need for multi-site dashboards and reporting experiences.

All levels of experience can get value out of this session.

Target audiences:

  • Tool procurement teams 
  • Developers (get a list of tools for a11y testing)
  • Website "Owners" / Stakeholders responsible for compliance
  • Project Managers
  • Dev Team Managers

Drupal 8 Custom Module Architecture: What’s Going On?

Lindsay Gaudinier | Friday, October 26, 4:45 PM-5:30 PM | Sibley

It is all fun and games modifying existing code, but what about when you have to venture out to unknown waters and create your own custom module? Don’t worry! We can get through this together!

This talk is a deep dive into creating custom modules from scratch, and the role of each component in the final product.

Let’s consider when it is appropriate to leverage custom development, explore the anatomy of a custom module, the types of expected files in a custom module, and the wonderful world of what you can do with a custom module (spoiler - it is a lot!).

This talk will include: Composer uses, forms, theming within a module, custom pages, Drupal namespacing, object oriented conventions, plugins, controllers, routes and more!

Web Accessibility 101 Training - This training course is a crash-course in web accessibility concepts targeted towards both content managers and developers working in Drupal tasked to create an "accessible website".

Navigating the Issue Queue - A beginner's guide to contribution (half day training) - Most Drupalers dream of being a contributor to the Drupal project. But where do you begin? And more importantly, what are some of the tools to help navigate the adventure successfully?

We look forward to seeing you all there!

Stop by our booth in the expo hall to say hi and pick up some newly-designed stickers!

Sep 17 2018
Sep 17

We recently returned from Drupal GovCon and have some standout items we want to share. Overall, the experience was a lot of fun. It was exciting to get to watch Adam give the keynote on how to make an impact in the community. At Hook 42 we love giving back to the community, and it was a great reminder of how everyone who wants to give back, can contribute.

Session / BoF / Training / Track / Summit

Adam: I was honored to be able to give the keynote for the first day of the event. I have been attending Drupal GovCon for years and have always aspired to do this. On top of the keynote, I had a session on Components with Brian Perry (this was super fun) and participated in the governance and coffee BoFs. As such, I was not able to attend the full set of sessions I had wanted to. I often prefer to watch recordings anyway (thank you, Kevin Thull). I tend to learn more when it’s quiet and I prioritize spending time with people when I am at events. 

However, there are a lot of thought provoking sessions I have queued up to watch. There was some great technical content: David Hernandez Demystified Composer, Todd Nienkirk and Gerardo Maldonado both explored a future decoupled perspective on the web (in their respective sessions), and Jakob Perry dove into complexities between data structures and relationships.

There were many non-technical talks that I plan to watch as well: 

It was very clear from discussions and the energy at the conference that people spent a lot of time bringing relevant and thought-provoking topics to share at the conference. I was super impressed with both Lindsay’s and Aimee’s sessions. Overall, I was really pleased with the schedule at the event and know I’ll learn a lot.

[[{"fid":"884","view_mode":"full","fields":{"format":"full","field_file_image_alt_text[und][0][value]":"Adam Bergstein delivering the Drupal GovCon keynote","field_file_image_title_text[und][0][value]":"Drupal GovCon 2018 - Adam Bergstein's keynote"},"link_text":null,"type":"media","field_deltas":{"1":{"format":"full","field_file_image_alt_text[und][0][value]":"Adam Bergstein delivering the Drupal GovCon keynote","field_file_image_title_text[und][0][value]":"Drupal GovCon 2018 - Adam Bergstein's keynote"}},"attributes":{"alt":"Adam Bergstein delivering the Drupal GovCon keynote","title":"Drupal GovCon 2018 - Adam Bergstein's keynote","class":"media-element file-full","data-delta":"1"}}]]

Aimee: I had booth duty, so I didn’t go to many sessions. The caliber of speakers across the board provided a fantastic exploration on a wide breadth of topics. If you didn’t get to go to a session in person, speaking with the presenters in the “hallway track” and at social events was a learning experience not to miss. Thanks to Kevin Thull, the sessions are recorded and posted to each session page quickly. I’m still catching up on sessions! 

I’m not supposed to just talk about our team, but here we go: Adam’s keynote was inspirational and had a lot of very practical attainable improvements for helping folks navigate the Drupal Community. Lindsay did a great job covering Drupal 8 Custom Module development. She provided a clear path of how Drupal 8 module files communicate with and depend on each other. Mind blown. 

Joe from Aten presented about how to write a clear RFP. It was a time for responders and writers to discuss what works and what doesn’t when wrangling legalease to get project work done. It also had Van Halen references (David Lee Roth era) - win win! 

Dwayne from Pantheon is always a great speaker and rallies the folks, even when he closes out the camp with the last session slot. You must discover his session on Discovery!! You are a champ, Dwayne!

Lindsay: My biggest take away from GovCon is that we are a community - and that developers need to focus on accessibility. Websites are for people, so it makes sense that we want to create a platform that can reach as many people as possible. As a community, we also need to make it easier for people to contribute to Drupal.

[[{"fid":"885","view_mode":"full","fields":{"format":"full","field_file_image_alt_text[und][0][value]":"An attendee at DrupalGovCon displaying personal pronoun sticker on their badge","field_file_image_title_text[und][0][value]":"Drupal GovCon 2018 - Pronoun sticker badge"},"link_text":null,"type":"media","field_deltas":{"2":{"format":"full","field_file_image_alt_text[und][0][value]":"An attendee at DrupalGovCon displaying personal pronoun sticker on their badge","field_file_image_title_text[und][0][value]":"Drupal GovCon 2018 - Pronoun sticker badge"}},"attributes":{"alt":"An attendee at DrupalGovCon displaying personal pronoun sticker on their badge","title":"Drupal GovCon 2018 - Pronoun sticker badge","class":"media-element file-full","data-delta":"2"}}]]

Adam had a lot of great suggestions in his keynote that could help the community grow stronger. A great example of community contribution in action is Kevin Thull. Kevin gets his steps in at every conference he goes to by rushing from room to room getting every session recorded. In case you couldn’t make the trip to DC, all the recordings are available on YouTube.

While I didn’t get the chance to go to a lot of sessions, I did attend a great accessibility talk by Tearyne Glover. She gave a real-life example of how inaccessible websites hurt real users and how to fix these problems. 


Adam: One of the points I raised in the keynote was the importance of the human connection within our community. There was a vibrant energy around this event that exemplifies this connection. Between the “hallway track” and the BoFs, much of my GovCon experience was conversation. And, that’s probably my favorite part. Since we are a distributed company, connecting with Aimee and Lindsay on our team was one of my highlights. It’s a great chance to connect with my community friends and make new ones. 

There were so many special people that attended (to name a few…): Kevin Thull, Brian Perry, Becca Goodman, Chris Urban, Dwayne McDaniel, David Hernandez, Tim Erickson, Danita Bowman, Brian Hirsh, Mike Herchel, Iris Ibekwe, Gerardo Gonzalez, Kev Walsh, Joe Shindelar, Elli Ludwigson, several of my previous co-workers at CivicActions and Acquia, and many more (by no means intentionally leaving someone out). This time together reaffirms how great our community is. Many people connected with me about my keynote. It’s these relationships that build trust and open up conversations to new and innovative things our community can accomplish.

[[{"fid":"886","view_mode":"full","fields":{"format":"full","field_file_image_alt_text[und][0][value]":"Aimee at a Drupal GovCon session ","field_file_image_title_text[und][0][value]":"Drupal GovCon 2018 - Session audience"},"link_text":null,"type":"media","field_deltas":{"3":{"format":"full","field_file_image_alt_text[und][0][value]":"Aimee at a Drupal GovCon session ","field_file_image_title_text[und][0][value]":"Drupal GovCon 2018 - Session audience"}},"attributes":{"alt":"Aimee at a Drupal GovCon session ","title":"Drupal GovCon 2018 - Session audience","class":"media-element file-full","data-delta":"3"}}]]

Aimee: It was really great to connect with people who work within the government and public service space. I don’t often get to talk with folks working in those environments at camps. Working in the government, and supporting organizations, comes with challenges and strengths that take on a different tone than the private sector. It is beneficial and informative to hear about the technical and organizational needs of our public servants. 

Lindsay: It’s very hard to single out one conversation, so I’ll just say it was great to be at a Drupal event with Drupalers. Someone mentioned that the Drupal community was such a strange unique thing, because he had never heard of another group of people that voluntarily go to conferences on Saturdays. Overall, I am also just happy when I get to hang out with a great group of Drupalers. I met a lot of new people and had a great time!

Social Events

Adam: The Brickside event is one of the highlights of GovCon for me, as I often do not participate in game nights or events too far from the venue. The food, drinks, and good company at the GovCon happy hour always lift the experience. Often people continue onto karaoke, dinner, or other fun evening plans.

Aimee: The GovCon team really does a nice job putting together mixers for attendees to chat in a social venue. Filled with nachos, wings, and beer, the attendees hung out and got to chat at Brickside. Many camp organizers come to the event and it provides a great opportunity to hear how other camps across the US are being run and how they are responding to the community’s needs. There was a nice game night in the camp hotel that had a good attendance, although I only peeked through the window on the way back home.

Lindsay: Every night there was a dinner... and lots of talking... and lots of laughing. From the World of Beer, to Brickside, to Rock Bottom, to the tapas, and back to Brickside - I had a great time with great people.

Overall GovCon Experience

Adam: GovCon continues to be a great event on my schedule each year. The combination of connections, schedule quality, social events, and, honestly, the size of the event just make it special. I really appreciate all of the work done by the organizers; and, how much people invest in their sessions and booths to make the event special. 

[[{"fid":"888","view_mode":"full","fields":{"format":"full","field_file_image_alt_text[und][0][value]":"Aimee, Adam, and Lindsay enjoying a session at Drupal GovCon","field_file_image_title_text[und][0][value]":"Drupal GovCon 2018 - Hook 42 team"},"link_text":null,"type":"media","field_deltas":{"4":{"format":"full","field_file_image_alt_text[und][0][value]":"Aimee, Adam, and Lindsay enjoying a session at Drupal GovCon","field_file_image_title_text[und][0][value]":"Drupal GovCon 2018 - Hook 42 team"}},"attributes":{"alt":"Aimee, Adam, and Lindsay enjoying a session at Drupal GovCon","title":"Drupal GovCon 2018 - Hook 42 team","class":"media-element file-full","data-delta":"4"}}]]

Aimee: GovCon is a wonderful event - the way it is managed, the people that attend, the relevant and timely topics, and the excellent location at the NIH. It is one of my favorite camps to attend and I look forward to returning next year. Thank you for hosting us, Drupal GovCon team!

Lindsay: This was my first GovCon and it was amazing! I met so many wonderful people, took my first trip to DC, presented at the NIH, and got to attend a very well-run camp filled with Drupalers. Awesome!

We hope to see you all at BADCamp!!

Sep 05 2018
Sep 05

AmyJune is venturing to the Great Plains of DrupalCorn Camp to spread her love of giving back to Drupal! Not only will she be training folks on how to navigate the issue queue, she will be leading Contribution Day, and teaming up with Lisa McCray to promote diversity and inclusion.

DrupalCorn Camp is four corn-filled days in September, the 27th through 30th in Des Moines, Iowa.


Getting Started with Drupal Contribution

AmyJune Hineline | Thursday, September 27 from 9am to 5pm

Many Drupallers dream of contributing to the Drupal project. But where do you begin? And more importantly, what are some of the tools you use to navigate the adventure successfully?

This training is intended for ANYONE who wants to learn how to contribute, not just those who are new to tech. No coding knowledge is required - there are plenty of ways to give back to Drupal without having to code.

In this training, we will discuss why contribution to open source is important and look at some of the tools necessary for working in the Drupal issue queue as a new contributor.

Tools of the trade:

There will also be a hands-on workshop demonstrating the process of finding a bug, creating an issue, writing a patch, uploading the fix to Drupal.org, and then reviewing the patch for RTBC (Reviewed and Tested By the Community).


  • A positive attitude about contributing back to open source software.
  • A willingness to learn.
  • A basic understanding of Drupal.
  • A laptop - preferably with a working local Drupal environment (but not necessary as we will go over some of the steps for setup).


Demystifying Diversity and Inclusion

AmyJune Hineline and Lisa McCray | Friday, September 28th at 3:30pm

What do we mean when we talk about diversity & inclusion, and why is it important?

Diverse communities are strong communities. Drupal has the potential to be more inclusive, but sometimes confusion about what being a diverse and inclusive community means holds us back. In this session we’ll talk about definitions, examples, and actions we can take to help the Drupal project become stronger. By ensuring that the Drupal community is a place where a wider range of people can participate, everyone contribute their knowledge, skills, and personal perspectives.

Topics covered:

  • What is Diversity & Inclusion? Including: definitions, clarifications, and real-life examples.
  • Why is diversity is important?
  • Why we should embrace accessibility for those with disabilities.
  • Ways to get involved.

Sunday, September 30th 9:00am to 4:00pm

Ready to start giving back to the Drupal Project? Whether you attended AmyJune’s training or not, come the Contribution Day on Sunday to put your skills (new or old) to use!! AmyJune and others will be there to help you select an issue you can tackle and provide you with mentorship. There are plenty of smaller tasks that can be completed by those new to contributing to Drupal, so feel confident that you can help out. When everyone pitches in, the Drupal community grows!

Stop by her training, sessions, or Contribution Day and AmyJune will give you a smile and some pretty rad sticker SWAG. 

Aug 26 2018
Aug 26

Dennis Deacon has been involved in digital accessibility for the past four years, most recently as an Accessibility Engineer with The Paciello Group. He’s led the Chicago Digital Accessibility & Inclusive Design Meetup since December 2014. He is organizing Chicago's first Accessibility Camp later this year. And, he leads the curation of the 24 Accessibility article series.

Dennis Deacon spoke about starting the Chicago Digital Accessibility and Inclusive Design Meetup. He spoke about digital accessibility but focused on delivering the most accessible events possible.


What is a Meetup?

A meetup is an informal meeting or gathering. Meetup.com and Eventbrite are popular platforms to organize gatherings; and, LinkedIn has also added the feature. It doesn’t matter which platform you use, it’s all about using the tool to help organize and advertise your event.

Why create an accessibility meetup?

If there is no meetup in your area, create one! It’s the perfect place to connect and learn from others who are passionate about accessibility. Use the space to promote accessibility to a wider audience.

How to start and grow an accessibility meetup

Just do it.
If the event is free, Eventbrite is free to use. Meetup.com has a monthly fee, and you can use the platform to create awareness of your meetup. Meetup.com handles membership activities, and it’s perfect for communicating with the community.

Get help.
Don't try to do it alone. Your job, your activities, and other external circumstances can take you away from the meetup responsibilities. Invested co-organizers or assistants help sustain the meetup, and can really save you some headaches.

Tell everyone.
Use Twitter, Slack, Facebook, and/or LinkedIn - anywhere where people will listen. Use the meetup’s handles and your personal account to spread the word.

Share information with complementary meetups and consider co-hosting. This increases collaboration between groups.

Finding Venues

This can be tricky in the beginning. Be aware of environmental noises and other distractions. Ask the guests if they need any special accommodations.

There are spaces available for hire, like co-working spaces. But, you should be able to find a free space. Ask other members for ideas, they often know about resources you are not aware of.

Make sure the venue is ADA compliant. Stairs, bathrooms, hallways, and seating should be accessible. Be sure the AV equipment can handle all the needs of the guests. Check the projector’s brightness to be sure there is enough contrast.

Wi-Fi is important not only for guests, but also for speakers. Speakers often have their presentation on a web server or want to perform a live demo so internet speed can be an issue.

Consider switching up the venues. This provides options to people who can’t attend some locations due to traffic, parking, mass transit, etc.

Finding Speakers

When you are just starting, this may be hard.

Colleagues who do accessibility work and meetup members are good resources. Encourage members to speak at the events. You can also reach out to other meetups to recruit speakers.

Post a call for speakers on all of your social media platforms. People in the accessibility field are some of the most accommodating and nicest people. You never know who will respond.

Lightning talks tend to be shorter and can take less preparation. The meetup can have 3 or 4 shorter talks instead of the traditional presentations. New speakers who are nervous or feel they don’t have enough content sometimes feel more empowered to lead short sessions.

Meetup formats

Mix it up, keep it fun. Some people don’t respond to presentations; but, they might respond to more interactive or engaging activities.

Some meetup formats:

  • Standard presentation - Slides can be made more engaging with demos, this is the closest to a standard lecture format.
  • Panels and roundtable discussions - Moderated panels or open roundtable discussions allow for a diversity of opinions on target topics.
  • Speed dating style format - Similar to the panel discussion or roundtable, have the guests rotate through “stations” on certain topics.
  • Social events - Educational events are good, but it is great to just have fun sometimes.

Accessible Presentation

Be sure the presentations about accessibility are as accessible as possible. Providing guidelines can be helpful.


  • Presentation foreground/background colors - Check for a high enough contrast. Be mindful of possible projector issues.
  • Font size and weight - Think big for the people in the back, those with limited vision, or guests taking pictures.
  • Consider the amount of content per slide - Limit the amount of content. Be concise.
  • Content positioning on slide - Keep the content to the upper two thirds. Think about the folks in back of the room. More space at the bottom of the slides means more space for captions.
  • Slide effects, transitions, and switching into demos - Be aware of any fast motion; this can make some viewers ill.


  • Volume - Be sure everyone can hear you, ask the audience about the volume. Use a microphone, this is extra helpful if the session is recorded. Speak clearly. Project your voice.
  • Describe visual content - Low-vision or blind users can benefit from descriptions of any visual content including images, charts, graphs, etc.
  • Switching between screens - If done quickly and repeatedly, this can make some viewers experience motion sickness.
  • Repeat audience questions - Repeat questions even when there's a mic, this ensures the question is heard when recorded. Also, repeated questions can be paraphrased. This can make the questions more succinct and understandable.
  • Be aware of your time - Allow time for questions. Be sensitive to remote captioning. It is helpful to have a clock nearby.


Don’t feel intimidated or bad about asking organizations for money. Provide them with benefits for the money you receive. You can offer to promote something your sponsor does or simply get their brand name out.

Act early. Don’t wait until you need them. Create relationships before you need them, already having a rapport helps. Cold calls are not effective. Provide opportunities for partnerships and meaningful relationships.

Many events don't need sponsors. Sponsorships provide revenue that helps provide extras like snacks and drinks, or added accessibility features like an ASL interpreter or captioning.

Live Streaming

It’s not complicated, you can use YouTube to live stream. Have the speaker wear a lapel mic to be sure the audio stream is clear. Bandwidth and background noise are things to consider.

Live streaming can help promote the meetup and bring new potential sponsors.

Live Captioning / ASL

If you live stream, you should provide live captions, so some viewers aren’t left behind. If you can’t provide live captions, be sure to record the presentation and add captions later.

You need to determine whether you want onsite or remote captioning. Some considerations are the audio source and Wi-Fi availability.

ASL interpreters must be onsite. You may need multiple interpreters depending on the length of presentation. They typically break after about 15 - 20 minutes of signing.


NO SHOWS are common. People don’t show up for any number of reasons such as weather, timing, etc. Expect an average of 50% turnout; life happens.

Make sure you have realistic expectations, and you book the venue appropriately.

A couple of tips for better turnout: reduce the time between announcing the event and the actual event and, if food will be provided, mention it!

What's the next step after meetups?

Camps and conferences are the next step.

A camp is basically an un-conference. Generally, they’re 1-3 days and may be free or low cost. This is the natural progression from a meetup.

Conferences can be 1-3 days or a week long. They have a more professional feel, and perhaps presenters are paid for travel, time, and efforts.

As the size of the event grows, so do costs in both time and money. That isn’t to say you shouldn’t grow, but be aware of those changes along the way.

To wrap it up...

Just do it. But, make sure you can dedicate time and effort.

Remember to ask for feedback, so you can make the next meetup even more accessible.

YouTube Video

Accessibility Talks August 2018 - Dennis Deacon - A11Y Meetups, Camps, & Beyond

Links mentioned in the talk:

• Slides - http://bit.ly/2KQG6Tq
• A11YChi Meetup Twitter - https://twitter.com/a11ychi
• A11YChi Meetup Meetup - meetup.com/a11ychi
• A11YChi Meetup YouTube - youtube.com/c/ChicagoDigitalAccessibilityInclusiveDesign
• Deborah Edwards-Onoro’s List of A11y Meetups - https://www.lireo.com/accessibility-inclusive-design-in-person-groups/
• Accessible Presentations - https://github.com/A11YChi/A11Y-Presentations

Drupal Accessibility Group

Join the Accessibility group on Drupal.org for hints, tips, discussions, and patch proposals to help make Drupal more inclusive.

A11yTalks on Twitter

Follow us on Twitter and use the hashtag #a11ytalks to follow the conversation.

Aug 20 2018
Aug 20

Andrew Dunkle is the CTO of Go Overseas. Go Overseas is a platform that strives to help people find meaningful travel experiences abroad. They often describe themselves as the Yelp or Airbnb of study abroad programs. Volunteers, recent high school graduates, or anyone who is looking to travel in a more impactful way can use the site to find opportunities. Andrew and his business partner, Mitch, co-founded the company in 2008, while teaching together in Taiwan. They recognized the need for a platform to provide information and encouragement about taking the opportunity to go overseas and give back at the same time.

How long have you been working with Drupal and what version did you start with?

When we first started thinking about how to create this platform and what tools to use, I did a lot of research. What was out there already? Should we use WordPress? I somehow stumbled upon Drupal. We initially started with Drupal 6, when it was in its early stages. I think Drupal appealed to us - specifically me - because it was really flexible. 

I don't have a tech background, I'm entirely self-taught. You can do lots of interesting and cool things with Drupal; but, at the same time, you could do it all through the UI. You can build out a really powerful website without actually having to really touch the code, if you didn't want to, need to, or know how to.

When did you think about migrating the site from Drupal 6 to Drupal 8 and how long did that take to implement?

We started with Drupal 6 during its early stages and we were pretty happy on that platform for a couple years. But, as we grew, there were certain things we wanted to be able to do that Drupal 6 didn't offer. Drupal 7 was released, and it was a big improvement on the Drupal 6 platform. We had started to hear about how Drupal was really going to flip things on their heads, so to speak, with Drupal 8. It was going to adopt more of an object-oriented approach and integrate with different PHP projects, mainly Symfony. We made the decision to not migrate to Drupal 7 knowing that Drupal 8 was going to be such a big change. 

When Drupal 8 finally did come out, the end of November of 2015, we still wanted to wait and let it stabilize - let the core team work out the bugs before we adopted it. I'd say we started that process in May or June of 2016. That's when I really started to dive into the Drupal 8 platform - really try to learn how it was different and start thinking about what it would take to migrate to that. We kicked it off in August of 2016 and started working with Hook 42 full-time. We launched the site February 4th, 2017. It took about eight month from start to finish.

Why did you choose Drupal 8 over Drupal 7 or some other CMS?

Drupal 7 felt like an extension, and while it had improvements over Drupal 6, it still fell within the functional programming paradigm. Drupal 8 felt more modern and had some long-term stability, so we decided to skip Drupal 7. We did consider other CMSs, but that discussion ended quickly. So much of our data architecture is very Drupal. Migrating it to a different data structure would have been problematic and not really helpful. If we went down the route of using full Symfony (or other PHP frameworks) it would have had certain advantages obviously, but we'd be responsible for building out everything: the UI, the different tools, permissions and routing... Drupal 8 already provides those things and it didn't really make a lot of sense to give up all that for the other advantages.

How was the migration? When you started, Media was still in development and the configuration management and composer workflow wasn't yet defined. When those improved, how did that affect your workflow?

The configuration stuff actually wasn't so bad during the development process. We had waited six or seven months after the launch of Drupal 8. I think we started with Drupal 8.1 or maybe 8.2. The config stuff was alright, the things that were bothersome with config back then, are still bothersome. When more than one person ends up working on the same config at the same time, somebody basically wins and somebody else loses. I think there's no real easy way to merge that stuff.

I think the bigger challenges we faced was the layout management at that time. In Drupal 6, we been using Panels pretty extensively; but, by the time we were working with Drupal 8, Panels was still in alpha and was not stable enough. We made the switch over to Display Suite, it was a little bit of a change. I didn't really like it at first; but, the more I started working with Display Suite the more I liked it. I don't like the UI so much, I think the Panel's UI is better than the Display Suite UI - I think it is really just extending Drupal 8 core. Dealing with the layouts was definitely a challenge for us. I think - for certain content on our site - we just had to do big globs of HTML, just to kind of get things migrated over and pushed.

What were some of the challenges when starting with Drupal 8 and how has the Drupal 8 project evolved since the site launched?

I think the organization of the code of Drupal 8 is a big advantage and something else to get used to. It's obviously different from Drupal 6 or 7. It took me about a month or so. I took some online classes and I went to a DrupalCon LA and took some Symfony classes. Once you get it and think "actually this totally makes sense", it speeds up your development. There's more structure to the projects themselves. So, it's easier for other developers to get involved, because everyone's projects end up looking the same. There's a standardization that makes things a lot easier.

The user stuff is all there; it makes it a lot easier for permissions and authentications. Drupal 8 is little bit harder grasp at first, but it's also incredibly extendable. For example, when you're working with contrib modules and want to change something in the way that module works, or you need to do something with some particular class - you can swap classes out and services out. You don't have to necessarily patch modules to add or alter functionality in core and contrib. I think that is pretty powerful; but, arguably, it can be challenging. You have to know Drupal 8 pretty well to do any of those things.

If you could improve something in Drupal 8 what would it be?

Config management certainly solves a lot of problems. But, it can also generate lots of problems, particularly with Git flows. Most - sometimes all - of my issues with config revolve around Git and just dealing with conflicts.

You used to have the ability, when working with a View, that if you messed up the view, somehow you could revert it back to its prior state in the code. For some reason that seems to be lost in Drupal 8, or at least I don't know how to do it yet. If I mess up a View or I don't like it anymore, I don't know exactly how to revert that particular view back to its original state without messing up all my config at that point.

The whole headless Drupal craze which lots of people talk about... there are competing methodologies about how to best utilize that. We've been experimenting with Vue.js a lot and started to integrate that into our project. It is really neat, but there doesn't really seem to be a consistent way to add Vue.js to the projects. You can do it a variety of ways, which all work, but I'm left wondering, "If they change something then I have to go back and change all these other things."

Or you can also build processes. All these JavaScript frameworks require something pretty heavy - web pack and JavaScript build processes - to generate all of this JavaScript code. There are a lot of build processes that you could figure out on your own, but at the same time, there seems to be competing interests about how to best do it. When a company like us is looking for stability, we want to make a decision that's going be stable for years to come. We can go down this route or the other route, but if we choose the wrong route, it could cause trouble down the line.

What are your favorite things about working with Drupal 8? 

Mostly the code organization, I do really like class structures. I would say they are a big help for me. I would tell this to anyone wanting to learn Drupal 8 - get PhpStorm, or something similar, and get really good at it. It is such a powerful tool and it also allows you to really learn how to Drupal 8 works internally. The tool helps you to bounce around classes and methods, so you can go up the tree and see how it all works. It's also self-documenting, some complaints about Drupal - this is Drupal in general, not just Drupal 8 - are that the documentation isn't the greatest. Finding information can be a challenge if you're just looking through the docs, but I find that I can just bounce around in PhpStorm and look at the code that's there. That has helped me understand how Drupal 8 works, what's possible, and what I need to know to extend a certain class or method.

Do you have any advice for people thinking to migrate to Drupal 8?

Have your data architecture down hard. I think that was the biggest challenge for us. Really nail down your nodes and your fields, have your site building really tuned in, know "this field is going map to this field." We had a huge Google Doc that mapped everything over with all the field names, and the data types. The earlier in the process you do that, the better and faster it will go. We thought we had everything mapped over but we had forgotten about something; at the end the project that caused a lot of headaches. During the migration process, you're just migrating data, there's really nothing more important than that. The actual representation of that data, Drupal 8 can handle all that. Particularly at this point, we're coming up on Drupal 8.6 and it's pretty stable. A lot of the core and contrib modules have been ported over to Drupal 8 and they are pretty stable.

Aug 17 2018
Aug 17

We’re excited to be offering two training sessions at BADCamp this year! Both of them focus on widening the reach of the internet and Drupal. Accessibility and contribution are close to our hearts at Hook 42 as they both are great tools for making the web a more diverse and inclusive place. The best thing about both subjects? You don’t have to know everything to dive in and get started - starting where you are is a great way to move things forward.

Please, join us on Wednesday October 24, 2018 for a half day training about getting started with Drupal contribution and/or on Thursday October 25, 2018 for a full day training on accessibility on the web.

Both sessions are appropriate for beginners or those looking for a refresh of the foundational concepts.


Navigating the Issue Queue - A beginner's guide to contribution

Many Drupallers dream of contributing to the Drupal project. But where do you begin? And more importantly, what are some of the tools you use to navigate the adventure successfully?

This training is intended for ANYONE who wants to learn how to contribute, not just those who are new to tech. No coding knowledge is required - there are plenty of ways to give back to Drupal without having to code.

In this half-day training, we will discuss why contribution to open source is important and look at some of the tools necessary for working in the Drupal issue queue as a new contributor.

Tools of the trade:

There will also be a hands-on workshop demonstrating the process of finding a bug, creating an issue, writing a patch, uploading the fix to Drupal.org, and then reviewing the patch for RTBC (Reviewed and Tested By the Community).


  • A positive attitude about contributing back to open source software.
  • A willingness to learn.
  • A basic understanding of Drupal.
  • A laptop - preferably with a working local Drupal environment (but not necessary as we will go over some of the steps for setup).

About the Trainers:

AmyJune Hineline is an active member and contributor in the Drupal community. As a Community Lead, she believes that giving back to an open source project should be easy and fun.

John Q.T. Nguyen has helped facilitate contribution sprints at multiple Drupal Camps, Global Training Days, and at DrupalCon. He enjoys introducing new and beginning users to Drupal and participating in activities to grow the Drupal Community.

Daniel Rose's passion for Drupal extends beyond the issue queue. When he is not actively working on issues, he is mentoring new contributors and helping empower them by showing them new tools and techniques.

Web Accessibility 101 Training

This training course is a crash-course in web accessibility concepts targeted towards both content managers and developers working in Drupal who are tasked to create an "accessible website".

Accessibility: what and why?

  • Understanding disabilities and challenges
  • Laws, standards, and organizations (beyond the WCAG 2.0/2.1)
  • Conformance Testing
  • Accessible Elements of the Web
  • Media
  • Content
  • Markup
  • Documents

About the Trainers:

Aimee Degnan is an IAAP Certified Professional in Accessibility Core Competencies (CPACC) and a seasoned Drupal and Web Architect who helps audit and architect websites for better accessibility. She believes in eliminating all the barriers that exist for accessibility to help make the web more diverse through inclusivity.

AmyJune Hineline is an active organizer of the Drupal Accessibility meet-up and is passionate about accessible information for all. Her history as a healthcare professional provides her with a rich understanding of the challenges folks may need to overcome and how that may affect their interaction with the web and supporting tools.

We can’t wait to see you all at BADCamp!

Aug 16 2018
Aug 16

Next week we’ll be traveling to the nation's capital to participate in Drupal GovCon! While Aimee and Adam are veterans of GovCon, Lindsay is embarking on her first trip to the Washington, D.C. area. 

Hook 42 will be presenting on a variety of subjects, including project management, module development, and component based development. We’re excited that Adam will also be delivering the keynote Wednesday morning!

GovCon is Wednesday, August 22nd to Friday, August 24th at the National Institutes of Health in Bethesda, Maryland.


Better Together: Impact Through Contribution 

Adam Bergstein | Wednesday, August 22, 11:00am | Auditorium

Drupal is one of the largest and longest-standing Open Source communities; yet, it can feel difficult to make an impact. How do you find your place in such a large and diverse community? Many community members have made contributions to the project outside of code that have had a significant impact. I will share some stories and examples, to provide ideas of how you might be able to contribute to the project. And, using the framing of a “hero’s journey”, we will explore how all the pieces fit together to make a big impact on the greater whole.

The Drupal community has remained sustainable and vibrant compared to other projects because of the opportunity to provide contributions beyond code. Community members are able to provide both technical and non-technical contributions. In this talk we will look at the appeal of participation beyond just technical contribution and explore the interplay between contribution, impact, and alignment of our personal interests with community work.

When we all pitch in, we can change the world; because, every new contribution adds up to our community doing new and bigger things. Together we can all continue to create a vibrant community built upon our creativity, passion, and interests.


Healing a Broken Project

Aimee Hannaford (Degnan) | Wednesday, August 22, 2:00pm | Room: F1/F2

What happens when you encounter a project that seems broken beyond repair, but for whatever reasons, a brand-new fresh start is not possible?

You may run into the following challenges with these "broken projects":

  • No clear scope
  • No requirements documentation
  • Far less remaining budget
  • Far less remaining time
  • "Project fatigue" from the client
  • Massive amounts of technical debt
  • And many, many more challenges…

How do you even start approaching such a broken project and bring chaos to order?

But what does order really mean? How does one measure success or completion in a fog of wrongness?!

Using project management and enterprise process management techniques, you can work through unclear and incomplete deliverables to help define what Done (success) means. This includes unraveling complex business logic, multiple business processes, and a slew of modules and configurations.

At the same time, we were proactively healing the client’s project pain by finally being able to articulate a clear list of what needs to be built versus what has been built.

Learning Outcomes:

  • Starting assumptions may not completely prepare the team for the project.
  • Identify and proactively address stakeholder’s project fatigue and apprehension.
  • Explore practical techniques to unravel and define the half-built and the unknown.
  • Understand that tools and techniques are really applying the “best practice for the situation” and which tool you use will evolve through the project recovery process.
  • Understand how to prepare your project team for the road to recovery with the client.

Can We Figure This Drupal Component Thing Out Already?

Adam Bergstein and Brian Perry | Thursday, August 22, 9:00am | Room: Auditorium

Over the last two years our community has seen the rise of countless solutions to implement design systems and components within Drupal. During the same period across camps, cons and the internet at large Adam and Brian have been having an ongoing conversation about best practices in component-based development.

With Brian focusing on ease of component integration (often with the help of contributed modules), and Adam focusing on a platform agnostic approach favoring functionality in Drupal core, there was initially quite a bit of good natured debate. But as time went on and approaches in the community matured they found their perspectives aligning more and more.

This session will present their (mostly) shared vision of a set of best practices for component-based development. They’ll still disagree on some stuff, but that’s part of the fun. We’ll review:

An overview of current approaches in the community, along with some limitations.
Our goals for a component-based design system.

  • Breaking down your patterns using atomic design principles to represent the ideal state of design system components.
  • Managing your pattern library as an external dependency of your Drupal project.
  • Limiting processing in your pattern library, and handling processing and mapping within your CMS.
  • Common misconceptions about integrating design system patterns in Drupal.
  • A baseline approach to implementation in Drupal using Drupal core and limited contributed modules.
  • The role of popular component-friendly contributed modules
  • Emerging technology for the future of component-based development.

Finally, we’ll go hands on with a brief demo showing our preferred approach in action.

Drupal 8 Custom Module Architecture: What’s Going On?

Lindsay Gaudinier | Thursday August 23, 9:00am | Room: Balcony A

It is all fun and games modifying existing code, but what about when you have to venture out to unknown waters and create your own custom module? Don’t worry! We can get through this together!

This talk is a deep dive into creating custom modules from scratch, and the role of each component in the final product.

Let’s consider when it is appropriate to leverage custom development, explore the anatomy of a custom module, the types of expected files in a custom module, and the wonderful world of what you can do with a custom module (spoiler - it is a lot!).

This talk will include: Composer uses, forms, theming within a module, custom pages, Drupal namespacing, object-oriented conventions, plugins, controllers, routes and more!

See you in our nation's capital!

Look out for some sweet Hook 42 sticker swag at our booth! We hope to see you at GovCon, and meet many new Drupal friends along the way!

Jul 13 2018
Jul 13

The June A11y Talk welcomed back Drupal Core Accessibility Maintainer, Andrew Macpherson. The “What's New with WCAG 2.1” talk discussed the new guidelines that were released in early June.

Web Content Accessibility Guidelines (WCAG 2.1) extends WCAG 2.0 and is intended as an interim until WCAG 3.0 is released. The new guidelines were needed due to advancements in technology and to fix some gaps and shortcomings in the earlier guidelines. Some of the new guidelines cover touch/mobile devices, speech control, and cognitive disability support.

The new extensions are organized in the same manner with priority levels A, AA, AAA. The numbering protocols remain the same: Principles > Guidelines > Success Criteria. There are 17 new success criteria: Level A - 5 new criteria, Level AA - 7 new criteria, and Level AAA - 5 new criteria. There were more proposed, but were not included because they were difficult to describe how to test. It is important that the success criteria be human testable so audits can be performed. Some guidelines changed numbering, priority levels, or were moved to another group.

There are documents in place to help people understand the new guidelines. They provide successful techniques along with known failures.

What's New with WCAG 2.1

New Success Criteria at Level A

Guideline 1.4.11 - Non-text Contrast
Icons, buttons, “focus rings”, and other state indicators now have minimum contrast.

Guideline 2.1.4 - Character Key Shortcuts
Speech control and dictation can trigger character key shortcuts accidentally. The new guideline requires modifier keys, not only single characters.
Example: Instead of just the key K, the command would be ctrl + K. Providing options to re-map or turn off shortcuts eliminates accidental triggers as well.

Guideline 2.5 - Input Modalities
This is a new guideline surrounding different input devices. Icons, buttons, “focus rings”, and other state indicators now have minimum contrast.

Guideline 2.5.1 Pointer Gestures
Multi Touch screens and trackpads are now common and many have the ability to be controlled by gestures. Not all people can gesture. We can’t assume people can move their phone. The new guideline defines that multi-point or path-based gestures must also work with a single pointer. Websites must be able to work with only a mouse

Guideline 2.5.2 Pointer Cancellation
When buttons are close together, it can be easy to push the wrong one. To avoid accidental activation when a mouse button is pressed, a website can avoid using JavaScript “down” events. By avoiding this code and using “up” events, a user that has pressed down on the wrong button can now move the mouse or pointer to the correct button and release it “up”.
Example: mousedown and touchstart.

Guideline 2.5.3 Label in Name
This new guideline helps speech control users activate controls. Mismatching the accessible name with what is visually displayed should be avoided. If a button reads “Sign In”, the label should read the same.
Example: <button aria-label=”Log in”>Sign In <button>, should read <button aria-label=”Sign In”>Sign In <button>

Guideline 2.5.4 Motion Actuation
Hand held devices, like Smartphones, have many sensors in them so they can detect motion which enables specific events to occur.

Success Criteria Links for Level AA and AAA

Because of time limitations, Andrew focused on discussing the new success criteria at the A level. Here are the sections that got extended at the next levels.

New Success Criteria at Level AA

Guideline 1.3.4 - Orientation

Guideline 1.3.5 - Identify Input Purpose

Guideline 1.4.10 - Reflow

Guideline 1.4.11 - Non-text Contrast

Guideline 1.4.12 - Text Spacing

Guideline 1.4.13 - Content on Hover or Focus

Guideline 4.1.3 - Status Messages

New Success Criteria at Level AAA

Guideline 1.3.6 - Identify Purpose

Guideline 2.2.6 - Timeouts

Guideline 2.3.3 - Animation from Interactions

Guideline 2.5.5 - Target Size

Guideline 2.5.6 - Concurrent Input Mechanisms


Link to Youtube:

A11Y Talks June 2018 - Andrew Macpherson - What's New with WCAG 2.1
General resources mentioned in the presentation:

• Drupal WCAG 2.1 ticket - https://www.drupal.org/project/ideas/issues/2864791
• WCAG 2.1 guideline for pointer cancellation - https://www.w3.org/WAI/WCAG21/Understanding/pointer-cancellation.html
• WCAG 2.1 target size - https://www.w3.org/WAI/WCAG21/Understanding/target-size.html
• Docksal - https://docksal.io/
• WCAG 2.1 text spacing - https://www.w3.org/WAI/WCAG21/Understanding/text-spacing.html
• Article by Steve Faulkner on text spacing - https://developer.paciellogroup.com/blog/2018/05/short-note-on-getting-spaced-out-with-sc-1-4-12-text-spacing/

Drupal Resources:

Drupal Accessibility Group

Join the Accessibility group on Drupal.org for hints, tips, discussions, and patch proposals to help make Drupal more inclusive.

Jul 10 2018
Jul 10

If you have been to any of the North American Drupal Camps, chances are you recognize Amber Matz. She is the production manager and a trainer at Drupalize.Me. Drupalize.Me is a site for Drupal tutorials and trainings. Amber, along with Joe Shindelar, travel to the various Drupal Camps and DrupalCons and currently run Drupal 8 Theming workshops.

How long have you been working with Drupal & what version did you start with?

My name on Drupal.org Amber Himes Matz and my account is about ten years old. I started with Drupal 6. I had been working in a non-profit organization in the webmaster’s office. I was doing a lot of PHP in MySQL and I was processing a lot of forms by hand - I was doing a lot of hand coding of forms and processing scripts. After about my 150th form I thought, “Someone must have figured something out by now. I'm sure I'm not the only one processing forms this way and getting sick of it.” That's how I found Drupal. I was completely blown away, and so excited because there was this starting point that was something where I didn't have to worry about user login in and authentication. I didn't have to worry about processing forms in the same way that I had been doing. What got me into Drupal is my disdain for writing PHP scripts to process forms.

How has your role in Drupal sort of evolved over the years?

I discovered Drupal because I was working in web development, and it seemed to be a good direction. Right about the time that I recommended that our organization adopt Drupal, I actually switched careers. I had been working in web development for about six and a half years. I went to massage therapy school in the evenings and worked full-time and moved away to Southern Oregon. I worked as a massage therapist in this little hippie town in Oregon called Ashland. I did freelance web development (WordPress and Drupal) for small sites and some business card design.

I was a massage therapist for about four and a half years and I moved back up to Portland. Basically, I stayed in massage therapy for another couple of years and then I just got tired of being poor. The economy had crashed, things were expensive, and income was really tight, especially in the spa industry. It had experienced the first downturn in 12 years, so that was kind of bad timing.

I decided I wanted to revisit Drupal, but I had been doing it wrong. For example, I wrote a search engine within a template file which is the big no-no, but it's was the only thing I knew how to-do. I discovered a Lullabot module development DVD; this was back when they did DVDs, and that just blew my mind. Drupal 7 had just come out as brand-new and Lullabot was doing the Webchick tour. It was Angie Byron and Joe Shindelar and maybe some other folks. They were doing workshops introducing people to Drupal 7, what changed from Drupal 6, what the new features were, and DBTNG which was the new way to access the database which was for me - as a PHP and MySQL developer - a big deal because it just made my life a lot easier. It just made doing dynamic content easier, so I decided to just bite the bullet. Even though I was feeling pretty poor at the time I thought “I have to get a flight down to LA and go to this workshop”. That kind of put things in motion that whole year.

That year, the Drupal Association moved to Portland. At this point, I had been on my own. I was a freelancer, and I was completely isolated from the community. I had seen the forums and seen the issue queue, but I just assumed those people were some kind of special breed of people. I felt like a total outsider; I had an embarrassing moment in IRC, and I didn't know how to interface with these people. When I found out that the Drupal Association had moved to Portland, I did some Googling for “Drupal in Portland” and I discovered that there was a local user group. This was on a Tuesday and it was the fourth Tuesday of the month which is when they have their informal meet up at a local pub.

I proceeded to have a major anxiety attack about going, showing up to this Meetup, totally new. I talked myself into it, and made it down there. I met a person, Dan Muzyka, who works at Phase2 now. Before that, he was working at this other place and they were hiring. I got an interview, I then subscribed to Drupalize.Me and totally binged on site building, views, and theming videos; you know, Netflix style binging, so that I could be conversant for the job interview. I was honest about what I did and didn't know, but at least I could talk about it. I could say, yeah, I know views to this point, but I don't know beyond this.

Anyway, I got the job. Six weeks later I was making views and working with clients. They put me on the phone with a client right away, because I could talk to people. That's always a great skill for a small agency to have, it’s like “oh you can talk to a client” okay…  here, you’re a project manager, now you’re a developer. That was like two years of intense on-the-job skill building, and I learned everything from site building to really advanced views and theming. Our agency got a gig to theme the 2013 Portland DrupalCon site. My first contribution to Drupal.org was making those commits for the theme for the 2013 DrupalCon.

After two years of that intense job, I saw the opening at Lullabot. A former coworker had gotten a job there and he had been really trying to push me to apply. Of course, I was completely intimidated by that. It took maybe three or four months of convincing, and this job opening for a Drupalize.Me trainer popped up. This was my dream job because they had done so much for me and helped me get a job as a full-time Drupal developer. I loved the platform and I had used it - and I had used it to great success to get a full-time job. It liberated me from the economic situation I had been in, so I was very thankful for it.

That was four and a half years ago. I was focused on creating content and back then we did only videos for Drupal 7. Drupal 8 we do both written and video. I create the content, but I also manage our production pipeline and work with our Video Editor and QA.

2014 was when I really started getting involved with the local community and with event planning. My involvement with Drupal has gone from "desperate to get a better job" to getting involved with the local community. That's really where I’ve thrived. After getting this job with Lullabot, and then Lullabot Education, which is now a sister company, speaking at DrupalCons... That has really helped me emerge as a community at-large leader instead of just in the local community. So, that's kind of how my evolution is taking place. I know it's a long story but I love it, because it really got me out of the these jobs that I really hated to something that I really, really love. I'm still kind of pinching myself. It took 20 years to find a job that I really love, but I'm very thankful for it right now.

When did Drupalize.Me start training others on Drupal 8?

Right when Drupal 8 came out. The year before it came out, in fact, we weren't quite sure when it was going to come out, but we knew it was going to be "soon."

We made a decision to set aside five hours a week to learn Drupal 8, so we had that learning time and, out of that, you needed to come up with a blog post. We were really trying to write a lot of blog posts about Drupal 8. This was, you know, using Drupal 8 in some beta version or even maybe an alpha version, but I think once beta came out we started really hitting the blog posts pretty hard. Three weeks or so after, very soon after a Drupal 8 was officially released, we released our configuration management series. We wanted to be training as soon as possible.

We made a decision to do written tutorials, as well as video, because we wanted to commit to keeping our tutorials up to date. It's really expensive and hard to keep video up to date, so we could produce more content and have the ability to keep it up to date, especially with the semantic versioning and these minor releases coming out every six months, we needed that structure in place. It's a lot easier to copy and paste, it's actually possible to copy and paste, code examples from written tutorial than from video.

What have been YOUR favorite components to teach?

I think theming is a lot of fun. I love using Twig. What I like and what Drupalize.Me likes, it's really tight... I don't even know where the separation is at this point. I really enjoyed learning the Responsive Images module, that was really kind of gnarly, because responsive images are kind of gnarly. That was fun to try and untangle that. I got some help from various people, but that was kind of a fun puzzle to do.

What are some of the advantages of working with Drupal 8 over the versions you've worked with previously? Are there any tools that you find more helpful than others?

Theme development in Drupal 8 is much easier with out-of-the-box configuration than it was with Drupal 7. With Drupal 7, you needed some contributed modules and it did some funky overlays, so you could see what the template suggestions were. The interface was there, but it was really quite overwhelming, and it was really hard - especially as a beginner - to figure out what template to use. It just felt tricky and magical. With Drupal 8 and Twig debug, being able to just view the source of the page and see where this chunk of code is coming from, this is which template is being used, these are the theme hooks suggestions, these are the template names you could use - it's just right there, it's just brilliant to have that. I just think it just makes it so much easier with your setup of your site. You set up your settings, and then you have the information you need. You don't need a contributed module. It just makes it easier to teach and easier to learn it from any level, so I just love that.

If you could improve anything in Drupal 8 what would it be? 

Right now, I am working on project with Jennifer Hodgdon called “Help Topics”. It's a sandbox project that we're trying to get into Drupal core. I’m trying to refactor it. She originally wrote it with config using configuration entities. We got some feedback from the community and I did a talk about it in the core conversation track at Drupalcon. The feedback was that we should be using the plug-in system. So, I decided to take that on. I've read a lot about it, I feel like I'm familiar at a high level with the plug-in system, but I really wanted to write the code. Because I’ve spent all my days now, for the last five years, writing tutorials, I don't do a lot of coding anymore, so I wanted to kind of get my chops back up.

There's a lot of abstractions in Drupal 8, it's a steep hill to climb at first, but once you get over that hill, it becomes easier. It feels like a juggling match and I still miss the hook system. Object-oriented programming is super fancy, and super great, and it definitely has a place in a big enterprise level robust system such as Drupal. But, sometimes you just want to implement a hook and be done with it. But, also, I've seen thousands of module files that are thousands of lines long and that's kind of a huge mess to deal with, so I see both sides.

As a PHP developer who learned on pseudo object-oriented code and had a break from that at a time when it was really emerging and then now has to go back and learn proper object-oriented PHP, it's challenging. It's hard. It's time-consuming. I understand why, but sometimes the abstractions get a little bit tiresome because it’s a hard thing to learn. I understand why it exists, and why it was implemented, and it does make some things easier once you know how to use it. It's just getting to that point that can be challenging; a little brain melting at times.

What advice do you have for those who have not made the jump from Drupal 7 to Drupal 8?

When you're planning a migration, you're trying to see if this is a viable thing, like can we migrate this Drupal 7 site to Drupal 8? Let's list all the modules, and let's find out if there's a Drupal 8 counterpart. You can find out some information that way, but there isn't going to always be a straight replacement for it in contrib. There may be a better way to do it in Drupal core, there might just be a completely different approach, or you don't need to use this contributed module anymore and that requires a lot more digging.

I think that it's probably different depending on what role you're in. If you're a site builder, or administrator type person, you're just trying to figure out what modules have been ported and want to know how to configure the site, so they can run this migration. Whether or not that's viable or not is a different process than if there are PHP developers or module developers on the team who can write custom code, who can see how they might implement it differently without needing a contributed module. I think there's just a different process and there might be a perception that their site isn't ready to migrate to Drupal 8. Maybe they feel Drupal 8 isn't mature enough for them, but it might just be a misperception or there's a gap in skills on their team to be able to do it successfully and that's valid. I think it's complicated.

Any migration is difficult, but there is a really great migrate system now in place and a great API. It's not easy-peasy, but there is a lot of help there and some things are really straightforward. But, with every Drupal site there's always the edge case. It's the mantra, this works for 80% of sites, but there's 20% that's that takes the longest to figure out and you know that's the sticky part.

What’s next for you?

I’ll be at GovCon with Joe in August, and we’ll be presenting our beginning Drupal 8 Theming Workshop. I’m reviewing some new tutorials and updates to our configuration management series which will include tutorials on deployment workflows. Also, Tim Millwood is writing some content moderation tutorials for us this summer. Content moderation is new to the latest version of Drupal so that should be exciting.

Drupal GovCon is August 22-24 at the Natcher Conference Center, National Institutes of Health in Bethesda, MD.

Jul 05 2018
Jul 05

Drupal Camp Asheville is next weekend! Join members of the Drupal community of all different skill levels and career paths for 3 days of science, trainings, sessions, and sprints.

Hook 42’s own Adam Bergstein will be sharing some insights on everybody’s favorite online Drupal testing environment, Simplytest.me. He recently took over ownership of the service, and we are excited to hear about where it is going next!

Along with helping to organize the camp, our newest team member, Jonathan Daggerhart, will be leading an all day training on Drupal 8 Essentials.


Simplytest.me: Past, Present, and Future

Adam Bergstein | Saturday, July 14th, 4:00pm | Room 1
Simplytest.me has been a long-standing tool that has served Drupal community members with an easy-to-use tool for creating Drupal sandboxes. This session walks through how people use SimplyTest and shares the various features of SimplyTest and the current underlying technical architecture, including the distributed computing infrastructure, use of LXC, and the Drupal 7 based provisioning platform. Based on lessons learned and emerging technology, a roadmap has been created to both modernize and evolve SimplyTest. This presentation outlines this future vision and presents opportunities for community members and companies to learn, to contribute, and to participate moving forward. We will review React, Docker, Drupal 8, Digital Ocean, and the new proposed user interface. Simplytest.me will continue to serve the needs of the community in a variety of ways and we’re excited to share the evolution of the service in concert with the needs of community members.


Essential Drupal 8 Developer Training

Jonathan Daggerhart | Friday, July 13th, 9am - 5pm

Intended for developers who have no, or limited, experience with Drupal 8 or Object Oriented Programming (OOP). Familiarity with Drupal 7 will be beneficial, but isn't required. This workshop will help jump start your Drupal 8 coding work by laying the foundation for all the big concepts that have been recently introduced. More than just teaching these ideas, I will attempt to provide understanding behind the potential motivations for these changes and how they relate to the work you're already familiar with from Drupal 7 or other procedural frameworks/CMSs.

We'll discuss and write a custom module together that uses all of these concepts:

Introduction to Object Oriented Programming

  • PSR4: Namespaces and Autoloading
  • What is Symfony?
  • Drupal 8 file structure - What you need to know.
  • YAML files & Annotations
  • Services
  • Hooks vs Events
  • Config Objects & Config Schema
  • Custom Forms
  • Custom Block Types
  • Custom Routing with Access Control
  • Providing Twig templates within your modules

By the end of this workshop you should be significantly more knowledgeable about how Drupal 8 has changed and understand why those changes are considered improvements on Drupal 7's code base.

It will be useful to come to this training with a local development environment where you can write and run PHP. Having a Drupal 8 site to work with would be beneficial, but isn't completely necessary.

We hope to see all of you in Asheville!

Drupal Camp Asheville is July 13-15 in beautiful Asheville, NC at the The Sherrill Center and Kimmel Arena.

Asheville Drupal Camp team picture

Jun 21 2018
Jun 21

Jill Cohen is a Senior Software Application Engineer at Autodesk Inc. Autodesk is a global company that empowers users to design and create just about everything on this planet - and in virtual worlds. She works with the Digital Platform and Experience Organization on the Digital Help team, which manages the Autodesk Knowledge Network and Services Marketplace. She is also on the board for Autodesk Women in Leadership.

How long have you been at Autodesk?

I have been at Autodesk for 4 years; before that I worked at various other startups, web shops, and worked freelance since about 1995. I have been a programmer, project manager, front-end developer, architect, designer, and database administrator. I was doing DevOps before there was DevOps. At my last job before Autodesk, I was hired as a Java engineer for a small nonprofit which evolved into build and release engineering as well as what has become known as DevOps.

I have spent most of my time working in Java.

How long have you been working with Drupal?

My programming background is primarily Java. I have worked a lot in JavaScript. One of my first applications that I wrote was taking MySQL and turning it into server-side JavaScript. That was about 1997 when JavaScript was on the server. It's on the server now in the form of Node.js, but back then it was very different.

I started working with Drupal with a company called SoundVision. They were producing The DNA files and their first website was a static, plain HTML site. They decided they needed a content management system. We started using Drupal 5. I managed to design and architect it without having to build any modules. There was enough out there to put it all together. The Drupal Admin was a hot mess and a disaster to work in, but I trained the team as to what to do. 

After that I designed and architected another site for them, but I didn't implement it since I left the country. Both sites are still going, they are Drupal 7 sites now. Other people came in and upgraded them. I did the two projects on Drupal 5, and skipped Drupal 6 completely.

I stopped working on Drupal after those two experiences and went back to Java after traveling around for a little while. Four years ago, a friend of mine asked me if I wanted to work with him at Autodesk. It was for Autodesk’s new Knowledge website built on Drupal 7, and I said yes. 

I was given a lot of time to get up to speed. It was a heavily customized site. It was managed by an outside vendor, and they had basically built and customized a lot on their own.

I am more of a full-stack engineer, so it was easy for me to get into the workflow and process. Once you figure out how hooks, menus and views work, you pretty much get it down. It's not super complicated.

When did you start working on Drupal 8 sites?

I started in December 2016. In the beginning of 2017, I put a prototype together for Services Marketplace. It took a lot to build the first module; to figure out all the moving pieces and parts and understand the new object-oriented framework, which I really like and prefer in some ways.

It took about 9 months to actually launch our site - which is pretty good, considering people had tried to put up other Drupal 8 sites and were not successful. I think we did a pretty good job in learning everything we needed to learn, while implementing someone else's vision. Other people's visions can be a moving target.

Plus, we implemented React inside of it which made it more complicated. We were learning both Drupal 8 and React at the same time, it was a pretty tall order. I think it's really challenging moving toward to what Dries calls progressively headless. It's in the middle where you’re still supporting a site for administrators and other users in Drupal, and you want to use Drupal headless.

Decoupled and progressively headless... I would recommend if you are going to go headless, go all the way. It's really hard to implement all the business rules you would need in a React app and make sure the administrator side has all the business rules.

Drupal does really well if you want to work headless, if you have engineers that want to work in JavaScript, Node.js, or some other area of the rendering system and go all the way headless.

Why did you decide on Drupal 8 for the Service Marketplace project?

There was really no point in going back to Drupal 7, and then thinking about having to upgrade it in a year or so. Drupal 8 had enough traction, sites were coming out, and there was enough support. Our hosting provider didn't have everything set up; however, they were getting there. We were on the cutting edge for them and we assessed it and decided "now is the time". 

I am lucky enough to work in a place that takes risks, encourages us to try new things, and expand our knowledge and learning. I felt if all else failed, we could have re-built the site in Drupal 7 pretty quickly. It wouldn’t have been fun, but I felt if something critical happened we had a backup plan.

What were some of the challenges you had working with Drupal 8?

There wasn't a lot of documentation beyond the basics. Menu items, routings, tasks... everything I wanted to do had a learning curve. I would write everything by hand or re-read some of the files in core, I had to reverse engineer in order to move forward.

I think some of the issues that were brought up were around using Composer. How to work with more than one person, people adding modules... I really like using Composer, but it did take us awhile to figure out the proper usage of it.

My biggest challenges have to be working with entity references. Drupal doesn't really clean up after itself. Removing a taxonomy term that is referenced on a node, breaks the node completely - you cannot view it until you re-save it. It doesn't work really well in production. I forgot that we had some barriers to removing entities in the Drupal 7 site. We were doing this one-to-one relationship, and we made sure someone had to remove one piece in order to remove another piece. We didn't hard code that in Services Marketplace, and it definitely is a place where we need to make sure we don't blow everything up.

I love entities and the object structure is great. If you don't understand the relationships, it's a huge stumbling point.

What are your favorite things about D8?

I like all the yaml files. I love the configuration setups and how you can export and import. It takes a while to have the trust that the system will do what you want to do when you want to do it.

Composer: I would use patch management, there's a way to do that.

Configuration: there's a new module for splitting the config per environment, but I haven't been able to implement it yet. 

I love the REST API, it’s really clean. It makes so much more sense the way you create web services. And how the packages and the classes are structured. I think if you haven't come from object-oriented programming background, it's a little disarming, especially when you're writing more functional and everything is in a module or include file. It’s nice to separate things out where they logically belong although it takes a little while to get your head around that.

Debugging is little bit easier. I like the controllers, and the way forms and blocks make more logical sense.

If you could improve something in Drupal 8 what would it be?

There is still a dependency on hooks, and I think if we cut the dependencies it would be much better. For instance, you can set behavior and overrides in a controller only to find that later it gets overridden by a hook. It's not immediately apparent what's going on, why you're setting something where it should be set and your interaction is still not working.

Maybe you can't get rid of all hooks, but I think it's time to let controllers own all the work.

Hook init is gone. We used it on our Drupal 7 site to make sure something always happens on every page request. They are now event managers and subscribers, but there wasn't a lot of documentation on how to use them and how to use it the way I needed to use it. I struggled a lot figuring out “do I want one on request”, “do I want one on response”, “what do I want it to do”, “why isn’t it consistent”? But in the end, it makes so much more sense.

How has Drupal 8 improved over Drupal 7?

The cleaner architecture and organization. I really like the use of yaml files and configurations for everything. I haven't had to use Features. I don't know if we can get into a perfect CI/CD where we don't have to do anything after you deploy. It takes far less time to deploy the new site... even when there are lots of changes. We just drop things into configuration and click one button and it's done. Everything is updated, that aspect is very masterful, and they have done a great job on making it work.

Yaml files are great, they're totally readable. Once you understand how they work, which ones you need, and why and where... it just works.

What advice do you have for people new to Drupal 8?

Don't be afraid to roll up your sleeves and dive into it. You don't have to be a master of object-oriented programming. If you want to be a JavaScript engineer, you're already working in objects and modules and it’s not going to be much different than working in PHP and Drupal.

Get a debugger, work in your IDE, look at all the objects, it makes it so much easier what functions to call on the objects. When you have it there, you can evaluate it, you can see how it's structured and it demystifies things. 

We all do console log, but once you actually get into a debugger, the game changes - even if you're not doing anything complicated. 

Be open minded, and remember that the skill set you're using for Drupal will stay with you and be useful in any other environment you want to work in.

Try to be an end-to-end programmer, there will be times when something is wrong in the database and you will need to figure it out. Drush, Drupal Console... they are your friends, don't be afraid to play. It's going to be a lot of trial and error, but totally worth it.

Jun 18 2018
Jun 18

What It Means to be Drupal Adjacent

One of the major objectives of Drupal 8 is the desire to “get off the island.” Drupal opened its doors to using and contributing to a broader ecosystem of projects instead of replicating functionality in Drupal. We now see tools like Twig and various Symfony components in Core. Contributed modules are also able to integrate projects and Software Development Kits (SDKs). For example, Password Strength, Digital Ocean, and Hubspot API integrate through Drupal’s native use of Composer. This philosophy helps those of us that more closely identify as “Drupal Adjacent.”

I consider being Drupal Adjacent as having some degree of experience in Drupal but maintaining expertise in a breadth of other technology. You are capable of leveraging Drupal’s strengths along with the strengths of other tools. Drupal Adjacent architects use “the right tool for the right job.” Drupal can serve as a bi-directional tool or framework in a broader architecture of systems and other tools can serve a discrete purpose.

As I consider myself Drupal Adjacent, I want to share my experience working in the Drupal community.

My Background

I have experience with a wide breadth of technology that includes Drupal. My first encounter with Drupal was in 2004. A friend of mine had a job implementing a CMS for her client. She evaluated many and chose Drupal - which was at version 4.x at the time. This was before the Security Team created issues and published patches. This was back before the mantra: “don’t hack core.” This was the time when that lesson was learned.

I came in as a backend developer with solid database experience. LAMP was all the rage and this was a great project for me to gain experience with a CMS and framework after writing my own basic CRUD (create, read, update, and delete a database record) without a framework. 

Living close to Silicon Valley, once the project ended, I moved on to other opportunities that came along that had different languages, platforms, and storage systems. 

Pareto’s Principle and Drupal projects

Over the next 12 years, I had many opportunities to come back to Drupal as it matured. I found how Pareto’s Principle (or the 80/20 rule) applied to Drupal projects. Some clients already had Drupal systems, but had hit limitations. Others had Drupal projects started but weren’t able to launch due to inability to fully integrate the modules they had in place. More than once I saw a site that was 80 percent complete with contrib modules, but still not ready to launch. I made an intermittent career out of helping those teams complete projects that needed custom code to close the gap and launch. 

Knowing my way around the Drupal API and framework, I knew how to write modules, hooks, and functions to add the final pieces. I knew when in the development lifecycle I should add custom code. I have written many modules, but many only addressed very niche, custom needs my clients had.

Drupal Adjacent

I have never built a site from scratch that has left my local environment. Don’t ask me to evaluate the best out of a dozen modules in the community. 


  • You want to upload data from your Drupal system to Hubspot for communication campaigns? I got your back.
  • Do you have years of data and would like use some of the new Big Data and Machine Learning tools out there?  Hundreds of field_data_field_% tables got you down? Set up a reporting database and create some views to normalize the data.
  • The outcome of several contributed modules has created a less-than-ideal outcome for your users? More than once I was able to write functions to change workflow states and other node properties with one user button click.

When you come to realize that not every solution has to be a Drupal solution, a world of tools open up to you. So many times your problem has already been solved, but perhaps not in a Drupal specific fashion. This is where your Drupal knowledge can help bridge that gap allowing use of best in breed tools.

May 15 2018
May 15

This month’s Accessibility Talk was an encore presentation of the panel’s Core Conversation at DrupalCon Nashville: Core Accessibility: Building Inclusivity into the Drupal Project
Helena McCabeCatherine McNally, and Carie Fisher discussed the fundamentals of accessibility and how they can be injected further into the Drupal project. All three are accessibility specialists in their fields.


What is accessibility and why does Drupal need it?

Web Accessibility is about building websites that accommodate people with disabilities. It is especially important in the Drupal community so people can be as self-sufficient as possible.

What disabilities primarily benefit from Web accessibility?

  • Visual Impairment - People who are blind or have trouble distinguishing between colors and color contrasts.
  • Deaf / Hard of Hearing - Some have trouble understanding content that is not captioned.
  • Motor disabilities - People who have fine or gross motor problems and it makes it difficult to use a mouse.
  • Vestibular issues and seizure disorders - These issues are often overlooked and those users can get motion sickness or have seizures from some of the special effects on sites.
  • Cognitive disabilities - Our aging group and people with autism or Down syndrome need to have an inclusive web and be allowed to be as self-sufficient as possible.

How do people with disabilities use the web differently?

  • Keyboard and Screen reader accessibility - Nothing on a website should need a mouse to interact with it. Descriptive text for images and destination of links are important for screen readers.
  • Captions and Transcripts - Captions happen in time with the audio and video, while transcripts are a full transcription of both the audio and visual information provided by a video. Transcripts are especially helpful to the blind/deaf user who might want to download the text into a braille reader.
  • Color and Contrast - The contrast ratio should be 4.5 to 1 for normal text and 3 to 1 for large text. It is best to stay away from using only colors to relay information.
  • Cognitive accommodations - Users benefit from a predictable, intuitive, and constant layout. That way they don’t have to re-orient themselves on how to use the website. Dyslexic people may need more time to process information especially if it’s complex. Don’t force people through content at a pace that cannot be controlled.

Why does Drupal need accessibility?

It is estimated that 2.2% of ALL websites are run on Drupal. The better Drupal Core is out of the box, the better it is for everyone.

  • End users may have disabilities.
  • Developers may have disabilities.
  • Clients and people within the agencies we build websites for may have disabilities.
  • It’s the law: Section 508, WCAG 2.0, and Title III of the ADA.
  • Drupal is for everyone!!

What are some recent Drupal core accessibility improvements?

  • Inline Form Errors module - This project is now stable in core. IFE alerts the user of a screen reader when there is an error when entering information on a form upon submission. The user does not have to rely on the error to be in focus to receive it.
  • Drupal.announce() and Drupal.tabbingManager - Extended coverage to more dynamic content.
  • Umami Out-of-the-box - This theme/demo illustrates Drupal’s accessibility features such as menu accessibility, primary tab theming updates, heading structures, and alt text for images.
  • Point Release - We no longer have to wait for major releases for continuous improvement.

What are some of the challenges we face in integrating accessibility into Drupal Initiatives?

  • Automated testing - QuailJS and other automated testing has been deprecated in core. It is not a perfect science, it only catches about 20%, but it does help with the more obvious issues.
  • Layout Builder - This is an experimental module that was added without an accessibility review. The “drag and drop” aspect does not have a widely adopted accessibility standard.
  • WCAG 2.1 - These guidelines are coming out later this year and will need to be addressed. We want to be proactive rather than reactive.
  • WAI-ARIA 1.1 - These have been out for a while, but there are still issues to be addressed.
  • Migrate - There needs to be a mechanism in place for tagging accessibility during migrations.
  • Media - Features for accessibility for videos and images would be great for things like transcripts. Clients would get a more robust experience if best practices are already incorporated. ie., alt text could be a required field.
  • Umami - Is in core now, but it still needs plenty of work.

Supporting Strategic Initiatives include: Theme component library, JavaScript modernization, Experimental admin UI, and Outside-In.

How can the community help increase accessibility in Drupal?

First of all, be aware that there are not enough experts in the area of accessibility. Some people feel that automated testing can be used, but in actuality, it only catches 20 - 40% of errors; but, manual testing can be time consuming and difficult. The standards for accessibility are constantly changing and adapting as the landscape evolves.

Why and how can we help?

  • Organizations - Improving accessibility can increase the user base, improve conversions, and save time and money. Organizations can make an effort to increase expertise by allowing contributions, providing resources, and sponsoring events.
  • Agency - Accessibility attracts employees and clients. It fosters inclusivity, which can help sell Drupal. Employees can be given the time to study and improve their knowledge. Client contracts and budgets should have accessibility baked in.
  • Community - The accessibility community provides an easy way to give back while helping others develop their skills and empathy. It helps Drupal stay relevant. Education is key: attend meetups and conventions, join online chats, and find a mentor.
  • Leadership - Taking the lead is easy. Mentoring, writing blogs, encouraging documentation, organizing events, and tagging issues can all help novices learn how to make the web more accessible.

How can you contribute and help?

There are many opportunities beside code that we can give back to the accessibility community to ensure diversity through inclusion. 

  • Code - Search the Drupal and GitHub issue queue for accessibility or a11y tags.
  • Documentation - Accessibility has a lot of documentation, but it could always use more!
  • Meetups - Connect with others in the community and bring your knowledge back to your peers or extended community.
  • Connections - Make positive connections through Twitter, Slack, and try to reach outside your network and beyond your own borders.

The Umami theme has open issues and will have more as content is generated:

  • Color Contrast Ratio updates
  • Redundant Links / Wrapping a card as one line
  • Message / Error Status State(s) indicated with color AND icons
  • Issues with Layout Builder


YouTube Video

A11Y Talks April 2018 - Carie Fisher, Helena McCabe, Catharine McNally - Drupal Accessibility​

General resources mentioned in the presentation:

Drupal Resources:

Drupal Accessibility Group

Join the Accessibility group on Drupal.org for hints, tips, discussions, and patch proposals to help make Drupal more inclusive.

May 15 2018
May 15

Dust off your saddle and get prepared to optimize your workflow. There is a lot packed into 3 days in Austin. Pull on your chaps, fasten your leathers, dig in your spurs and head on over to Texas Drupal Camp. On Thursday, make sure you check out the trainings and sprints. On Friday and Saturday, catch all of the keynotes and sessions.

Our own Ryan Bateman will be at Texas Drupal Camp to share his presentation about visual regression testing.

Texas Drupal Camp is Thursday, May 31st through Saturday, June 2nd at the Norris Conference Center in beautiful Austin, TX.

Deploy without fear – Visual Regression Testing with BackstopJS is here!

Deploying front-end changes can be scary – while you may have set out to make nothing more than a humble CSS change to the footer of a landing page, it’s very easy for that new CSS rule to cascade (excuse the pun) out of control, impacting other regions or pages in ways you never intended. With visual regression testing software like BackstopJS, however, we can rest assured that our changes are precise and contained.

This talk will cover the basic use and configuration of BackstopJS, as well as some Drupal-specific tips for optimizing your visual regression testing workflow on Drupal projects.

To read more about Ryan's session and to find out the location and time, skedaddle over to the session page: Deploy without fear – Visual Regression Testing with BackstopJS is here!

May 08 2018
May 08

For this month’s Drupal 8 Interview we were excited to catch up with Eduardo Garcia. He is the CTO of both WeKnow and anexus. WeKnow is a Drupal and Symfony consulting and training firm. Anexus is a company that supports the development of Drupal Console.

Most people in the open source and Drupal community know him as Enzo. His companies are mostly distributed and he likes to think of himself as a distributed person because of his love for travel. He is a native Colombian who lived in Costa Rica for more than 14 years. He currently resides in Australia with his family.

How long have you been working with Drupal and what version did you start with?

I am coming up on my 10th anniversary. I started with Drupal 5; my first project was for the Japanese car company, Mazda USA. It was a marketing website: public relations, news, and marketing releases for Mazda inside the United States.

I was learning, training, and leading the project. It's a similar process to how many people first get started with Drupal, not in perfect conditions. When I started the project, it was a month behind, but we delivered the project with only a two week delay. It was a good experience considering all the problems we had. I hated the process, but enjoyed the platform... despite all the problems we had; if in better conditions, you can create better products and have better interactions and reuse the knowledge you have and train people at the same time. I enjoyed that and this is why I decided to have my professional life be around Drupal.

How did your role evolve over the years to where you're at now?

The first two or three years I jumped from Drupal developer to a team lead. I was the person charged with providing technical leadership as to how to tackle a problem, provide solutions for the tickets, how to implement solutions for the clients, and was also responsible of training people.

At this same time I decided to try to build a Costa Rica Drupal community. I wanted to fill a void, I was maybe the second person using Drupal in Costa Rica, so I decided to build a community.

It was hard to engage with universities and companies. We created our first camp, this year is our 9th Drupal Camp Costa Rica, and it is the oldest and largest in Latin America. It is very international, we sometimes have 300-400 attendees depending on the location, we always have 25-50% people from USA, Europe, and all over Latin America coming to Costa Rica… because, you know Costa Rica... and Drupal.

When did you first start working on Drupal 8 sites?

It was about two or three years before it was released. Everybody in the community was concerned about the jump in technology. All these new things, I was worried about people being left behind in the process... As my role as a technical lead and a CTO of my own company, I was worried that maybe the move in the community will leave my own company behind.

So I decided to take action. I was very concerned about the whole Drupal ecosystem and joined the Drupal Console team. At the time it was led by Jesus Manuel Olivas and David Flores in Mexico. The Drupal Console project at that moment was in the beginning phase, it was a tool to help you ramp up in the learning curve from the inside out. I had to take unstable code and implement generators to try to accelerate the adoption in Drupal 8. 

When did you start mentoring people and training?

About two years before the Drupal 8 stable version was released. We worked with the idea that we need to reduce the scary moment of change.

Some people choose to contribute to core, which is of course the most important team in terms of development. We chose to tackle the problem from a different perspective. There were a lot of people who needed to become involved in the change and they needed something to try to help them. Learning all the new things can be complicated, but they can use Drupal Console to help them generate code by themselves and learn from there. The minimal tools are provided to create functional code and then the user is in a better position to learn the concepts and code.

What were some of the challenges you had when you first started working with Drupal 8?

That's a tough question, perhaps working with Symfony. Good changes are sometimes the most challenging changes. With Symfony, the whole idea is that we need to leave the island and use the bridges that Symfony console brings to us. Really, more than that, using something, not just in theory, the real implementation is the most difficult part. It’s like swimming, the first time you drop into the water it is scary and difficult. But after a few hours you are used to the water; it’s like a jump of faith.

What are some of your favorite things about working with Drupal 8 as opposed the earlier versions?

The same things. All the things that were scary are all the things I later enjoyed. I can now use more integration with less code. With Drupal 7, I would have to write lots of custom code, using the modern development practices allows me to create more fancy and professional integrations that in Drupal 7 would require more human effort.

If you could improve anything in Drupal 8, what would it be?

The first time user experience, Dries talked about this in his driesnote. For someone with zero Drupal experience, a marketer, CEO, or someone trying to illustrate the platform, it’s really hard for them to get it running by themselves.

Compared with other platforms which might be easier, like Symfony, Laravel, WordPress, or Magento… Getting a site up and running for the non technical person is very hard.

I want to emphasize to the community that Drupal needs to be made more accessible and have relevant content for users in other countries. Localization and multilingual needs to be seriously addressed. As a traveler, it is difficult to sell things to people that is not in their native language.

What advice do you have for people who are new to Drupal 8?

They really need to embrace the concept of using tools outside of Drupal. That will allow people to have an easier path into the code and more enjoyable journey into Drupal.

What is next for you, do you see any evolution?

On the company sides of things, we are working on trying to automate the process, using Drupal itself, using Symfony, and decoupling themes. We have been doing a lot with decoupled stuff and starting to play around with some artificial intelligence ideas. Maybe it sounds crazy, but why not?

What’s next for Eduardo?

Drupal Camp Costa Rica’s 9th anniversary is August 3-4 in Liberia, Guanacaste. The camp takes place just over 30 minutes from one of the most beautiful beaches in Costa Rica. This year promises Drupal (of course), front-end, back-end, business, projects, UX and more!

Eduardo has been asked to keynote at this year’s Drupal Camp Singapore in July. Follow Drupal Singapore on Twitter to keep up to date with their community.

May 03 2018
May 03

In March, A11y Talks welcomed Melanie Sumner, an application architect from JP Morgan Chase. She is an accessibility advocate and is an EmberJS core team member and meetup organizer in Chicago. The tagline for Ember is "the framework for building ambitious applications". Melanie spoke of ways to inject accessibility into not only the Ember project, but into other single-page applications so some users are not left behind.


Why do we ignore Accessibility?

Accessibility is emotional - It is easy to ignore things that are emotional. But, users are important! They need to be able to perform everyday tasks like checking their bank balances or buying items online. Lack of accessible websites can be frustrating and lead to thinking that developers don't care.

It is also emotional for developers. Timelines are a reality and the “ship it now and fix it later” doesn’t always work or happen in the real world.

Accessibility is hard - It is difficult to get accessibility correct when first starting out. There are some difficulties that should be solved no matter what framework is used.

  • Route transitions - Ember handles routes splendidly, but assistive technology doesn’t always pick up link events. 
  • Modals - There’s a difference between visible focus and screen reader focus and when using a modal the focus needs to be trapped. 
  • Aria attribute support - We need to be able to provide easy Aria attribute support, which isn't always done.
  • Click all the things - Attaching actions to all the things can be tricky, especially when events are nested into other events. Keyboard navigation needs to accessible for everyone.
  • Passwords - They need to be safe, but passwords can be difficult for screen readers.

Web standards are important

These give us easy wins by giving us accessibility by default. Easy wins include:

  • Use HTML 5 - Please use semantic HTML, divs are great but we should be using an HTML element.
  • Link vs. Button - If it goes to a route use a link. If it goes with a form or closes a modal, use a button. Focus on what is machine-readable more than what it looks like.
  • Keyboard Navigation - Anything that can be done with the mouse should be able to be done with the keyboard.
  • Color contrast - There are lots of color contrast tools available - USE THEM.
  • Image alt text - Add alt text to an image if it’s relevant to the image. EX- Images used within paragraphs don't need to be as descriptive as images used to sell products.

Pick your battles

There are things we need to do as a whole web community - not just within the Ember community. There are arguments about tabs vs. spaces or the div element vs. the semantic HTML5. HTML, CSS, and JS are all fundamentally important for creating accessible applications.

In the ember community there's the saying, “There’s an ADDON for that”. The following features already exist:

  • Ember - A11y - Relevant focus to views and outlets.
  • Ember - A11y Testing - Built on aXe core and takes the automated testing processor a little further.
  • Ember - A11y - Landmarks - Single page applications usually wrap everything in a div and put the div in the body, but then some of the landmark navigation regions or elements then require extra roles to be added. Ember is pushing to be able to opt out of the wrapping div.
  • A11y - Announcer - Tells which route you’re on when you switch routes.
  • Ember - CLI - Template-Lint - Helps make sure there are some extra accessibility rules written into the linter to help developers before they ship the code.
  • Ember - Component-Attributes - Is a stop-gap while we revisit how to handle attributes in components. This provides the biggest win by being able to add HTML attributes to existing components.

EmberJS list of accessibility addons

Solutions are happening NOW!

  • Sight - Engineers don’t always think of the little things... A new innovation, EnChroma, allows color-blind users to see things such as the red and green MacBook power cord lights.
  • Hear - Auditory brainstem implant surgeries help those with hearing loss know when sound is present or absent.
  • Auto-Generate Text - Microsoft has a project cloud service called Video Indexer. It can provide transcriptions, extract text that appears in the video, live translate to different languages, and it can adjust the language model used for transcription making it market specific.
  • Image Descriptions - Include.ai makes image descriptions more web accessible.

Most importantly

Remember you’re not alone! If you get stuck, ask the community, ask your mentors, and ask others. You just don’t know how to do it YET. “Be magnanimous”. Get involved and be present. Be sure to always have these issues addressed:

  • Keyboard navigation
  • Focus Management
  • Aria attribute support
  • Actively use semantic HTML


YouTube Video

A11Y Talks March 2018 - Melanie Sumner - Ambitious Accessibility

Links to the Slide Deck

Ambitious For All - Slides Only

Links mentioned in the talk:

Drupal Accessibility Group

Join the Accessibility group on Drupal.org for hints, tips, discussions, and patch proposals to help make Drupal more inclusive.

May 03 2018
May 03

Every year at DrupalCon our team has an amazing time. This year was no different. We rounded up everyone who attended and asked them about their favorites this year.

Technical information was being readily exchanged and processed, while the humans who make up the community shared many stories as well. On top of all of the good information there was good food, so much food!

Session / BoF / Training / Track / Summit:

Aimee: The Business Summit had a great turnout and fantastic contribuors. I enjoyed hearing about the state and direction of Drupal in the Driesnote, the Dries Q&A, and Gábor Hojtsy's review on the Drupal core innovation cycles.

AmyJune: I enjoyed participating in the Mentored Sprints... I love contributing to the Drupal project and I enjoy empowering others to do the same even more!

AmyJune helping folks during the Mentored Sprint Workshop
Photo credit: Amazee Labs

Carie: Hot JAMS(tack): Building a Music Discovery App with Drupal and React by Brian Perry was my favorite presentation of the Con due to the integration with components and React.

Chris: Surprisingly, various tools (Devops and otherwise). Along with some of the ancillary technologies and decoupled stuff.

Dan: The theme for me this year was DevOps, as always. Anything I can learn about DevOps is always interesting to me. It’s probably my favorite topic to talk and learn about. I went to a handful of DevOps sessions and learned a lot about how we can incorporate a more consistent DevOps workflow into our projects. Everyone on the team is part of the DevOps team. Communicate communicate communicate! In order for all of us to incorporate a good DevOps system of tools/workflows, etc., we need to communicate what we are doing, plans, etc. Drupal Coffee BoF was nice. I talked with some people who I’ve never met in person but have been interacting with on Twitter for a long time, as well as some people I’ve never met or talked to before. 

Darryl: I took the ReactJS training, and along with that, I took in a couple sessions having to do with decoupling. Actually, much of the React training wasn’t really about decoupling, but rather how to attach React to Drupal’s output, as an introduction. I went to a couple of sessions on the Layout Initiative and Layout Builder, as these seem to be where Drupal is headed. I also went to the I Was Wrong session, which was very interesting, and a very brave thing for the presenters.

Genevieve: I didn't make it to as many sessions this year as I have in the past; I did enjoy the  “I Was Wrong” session though. It was great to hear a variety of stories on ways in which people may have faltered and recovered in the past.

John: The two things that made me the happiest were: 1) seeing entries in the “Being Human” category, and 2) I knew a number of people who were presenting at DrupalCon for the first time and rocked it. With the latter, I am obviously heavily biased in the matter, but, hey… What are you going to do about it?

Kristen: I enjoyed all the Core Conversations and how we are trying to make Drupal easier for content editors, for site builders, and for developers.

Oliver: I was introduced to a couple of new things to put into the accessibility toolbelt, including an audit tool that is a bookmarklet (as opposed to an extension), which creates a pop-up on the page you’re currently on.

Ryan: I’m getting really excited about the movement happening with GraphQL in Drupal – talks like “Push vs. Pull: GraphQL in Twig” are showing off some interesting ways that GraphQL might even be a suitable alternative to conventional render arrays. I think the implications for decoupled Drupal as well as component-driven conventional Drupal sites are really interesting!

Social Events:

Adam: I loved the Pantheon party and the Amazee party. I really liked the restaurants there and small convos had.

Adam having a good time with other Drupallers
Photo credit: Susanne Coates

Aimee: I'm not supposed to say I was super excited to hang out with the Hook 42 team, but since we are all remote, it is a great opportunity to come together. Dancing and yoga-flash-mobbing in the basement room of the Pantheon / Lullabot party was hilarious and entertaining - for us and everyone watching. :D Genevieve, Kristen, and Greg Anderson: thank you for an excellent evening! 

AmyJune: The parties are always fun. I really enjoy reconnecting with folks from previous Cons and building stronger relationships. I enjoyed the game nights more than anything; unlike the parties, they provided a quiet atmosphere, which is much appreciated by mid-week!

Carie: All the social events were fun and the food and music in Nashville were amazing.

Chris: Plenty of good restaurants where it wasn’t too loud to talk, hanging out with new people and not being stuck in some dangerous part of town :)

Dan: Of course, any chance to hang with our team is fun. The Amazee party was great. I loved the tour of the Country Music Hall of Fame, as well as the food at Martin’s BBQ. I’m not a social butterfly but I did enjoy the Pantheon/Lullabot party as well, even though I mostly socialized with the Hook 42 team. I also enjoyed all the board games with John and David Needham from Pantheon.

Darryl: The Pantheon/Lullabot Party was fun, but perhaps too crowded for me. I really enjoyed the Amazee Labs party - a tour through the Country Music Museum and then what is reputed to be some of the best BBQ in Nashville.

Genevieve: I think each social event had its own special moment that made it a lot of fun. I do have to say, leading some yoga on the dance floor at the Pantheon/Lullabot party was pretty great! Thanks to handful of people who joined :) In general it is always fun to catch up with the team and see friends that we only get to see at DrupalCon. 

DrupalCon Nashville Coffee Birds of a Feather drawing pad with drupal drops and cups of coffee
Photo Credit: Daniel Rose

John: I went out three times for Hot Chicken, partook in two Official Board Game Nights, attended a Pantheon Partner Dinner and Women in Drupal both for the first time, and went to a Partridge in a Pear Tree. However, I probably had the most fun doing Impromptu Game Nights with friends and team members. And I’ll forever cherish the memory of scoring a Perfect Victory over Ryan in Street Fighter II and hold it near and dear to my heart, right next to the memory of him completely schooling me in every Pinball Game known to mankind. That kid sure plays a mean pinball!

Kristen: The Country Music Museum was interesting… so many gold records!

Oliver: The bingo cards at the Women in Drupal event were underrated. They got me talking to a lot of people I wouldn’t have otherwise interacted with.

Ryan: The Pantheon/Lullabot party was a great time. Otherwise, I loved all the great food but feel like I’ve progressed my Type-2-Diabetes Doomsday Clock six hours in one week!


Adam: Too many to count. They were all good.

Aimee: Lots of conversations about coffee, food, and music. Great to touch base with the Drupal community and meet new people in addition to connecting with old friends. And talks about layout... lots of layout talks... and security patches...

AmyJune: I found myself discussing compost a lot over the course of the week. Though they weren't necessarily my favorite conversations, they were definitely the most interesting.

Carie: Lots of great convos with old Drupal friends and met a lot of new people as well. Chatting with the accessibility team is always the highlight for me.

Chris: Plenty of great chats about mentoring for next year, simplytest.me and other complexities of the Drupal world with Adam, and the scary world of games with John, amongst many others.

Dan: To echo what Genevieve said, I didn’t have a favorite conversation. I enjoyed the many different conversations with lots of people from wandering in the exhibit hall to mentoring, training, Drupal Coffee BoF, etc.

Darryl: Lots of talk with the team I only ever interact with by typing on Slack. I also had a nice chat with Murray from Australia, while we were waiting to board the flight from SFO to BNA. He came halfway around the world to give a session on the Bricks module, a simpler way to get similar functionality to Paragraphs.

Genevieve: I don’t think I have a favorite conversation, but much conversation was had :) John may have a winner though!

John: If you could qualify an interaction with Genevieve that was an attempt to close a card game and ended with me literally rolling on the floor laughing as a conversation, then that was the best conversation. Also, shenanigans that happen after midnight are much, much funnier and amusing to a brain that is barely operational because it’s after midnight.

Kristen: I had a lot of fun talking with the Lingotek folks at the Acquia party. They are good people.

Oliver: I liked being prompted to converse by the bingo cards at the Women in Drupal event.

2 women discussing  life, the universe, and everything over some bingo cards at the Women In Drupal Party.
Photo Credit: Susanne Coates

Ryan: Maybe I’m just partial to the Hook 42 team, but some of my best conversations of DrupalCon were with folks on our own team. You guys are a riot!

Booth / SWAG:

Adam: The Life Aquatic shirts/hats from Lullabot were amazing. Loved the soft shirts from Linode.

Aimee: Four Chickens, without a doubt. I love me some Four Kittens, Four Chickens, and Four Kitchens. I missed out on the Drupal drop Pink Floyd prism from the DA. I'm on the hunt for one for Lindsay, who didn't attend DrupalCon this year.

AmyJune: I ended up taking mostly notepads from booths. In this digital age, it is always refreshing to go back to the basics by actually writing things down.

Carie: Lullabot shirts and hats were great. I always love the stuffed Digital Echidnas.

Chris: Life robotic shirts were great, also the Acquia one, a nice glass water bottle from FFW, also their combo usb cord, plenty of great stickers, usb power pack, many more things.

Dan: Lets see.. I got shirts from Pantheon, Linode, Hook42 :), Lullabot, Drupal Association. I got some stickers from many booths and as always I made an appearance every day at the Digital Echidna booth to play some hockey. I now own 2 echidnas and 2 Drupal drops. Someday I need to win that Drupal hockey jersey!

Digital Echidna stuffed Echidna in the expo hall
Photo Credit: Susanne Coates

Darryl: I got another yo-yo from JetBrains - the one from last year is still working, but the one from the year before gave up the ghost a while back, so having a spare is probably a good idea. (I gave up on T-shirts and hoodies years ago, I’ve probably donated >500 to Goodwill over the course of my career, and my collection is growing again in spite of not taking any as swag.)

Genevieve: I think the yo-yos from JetBrains win - but mostly because Darryl & Ryan taught me how to finally actually kind of use a yo-yo beyond just the basic skill of getting the yo-yo to return to you. :)

John: I actually have been actively trying to NOT get SWAG at Camps and Cons in an attempt to not clutter up the house, with the exception of the Obligatory T-Shirt from Event Being Attended. That being said, I walked away with two more T-Shirts than I expected: one from being a Sprint Mentor and the other a Drupal 8 Pac-Man shirt that I got in honor of Dan, who wasn’t able to get one in his size for himself.

Kristen: My teenage son really likes the Life Aquatic shirt. Some booths had earbuds which is also a great idea for people with teens.

Oliver: I’m keeping that 3.5” floppy (the Lullabot Party invite) I got until I can pop it into a computer and see what’s actually on it.

Red floppy disk invite for Lullabot party
Photo credit: Jeff Geerling

Ryan: Yo-yos! I had a miniature (okay, maybe not so miniature) nostalgia trip playing with my JetBrains yo-yo for a day (okay, maybe I played with it for several days). I also re-stickered my laptop with some new and cool stickers – the ones from Siteground in particular were really fun.


Adam: I liked that it was walkable and there were many amenities close by. The hotel was great. The area was fun, even though I’m not a country music fan. The venue was good (slightly confusing to navigate).

Aimee: The neon. The sparkles - everything is Bedazzled. The music. The walkability. The food - SO MUCH BBQ. Nom. 

AmyJune: I loved all the music coming from every door we passed. Being a vegetarian was a little challenging at times, but there was plenty of beer to satiate my appetite! 

Carie: I am also not a country music fan, but there was enough to do outside of that to keep you busy...including shopping for cowboy boots ;)

Dan: Nashville was great. Everything that we needed was within walking distance. I wished I could’ve made it to the hockey game which was right next door. The food was fantastic. Favorite restaurants were Puckett’s and Martin’s BBQ. Country Music Hall of Fame was pretty interesting as well. Also bought a nice cowboy hat. Will definitely go back to Nashville again.

The Hook 42 team having BBQ in Nashville
Photo Credit: Carie Fisher

Darryl: Nashville was fun - I regret all those times I drove by on I-40!

Genevieve: It was fun to get to see Nashville in a month other than January. All the past times I’ve been it has been very cold so there has been a bit less walking around. It was also nice that there were a lot of food and entertainment options nearby. 

John: Having so many things within walking distance of the venue was awesome. It was also really fun having those Random “Music Boxes” on what seemed like every other street corner blaring out tunes; it helped to really drive home that Music City feel.

Kristen: Everything seemed really close and easy to get too and I had some good BBQ at Martin's. It was actually a lot more modern than I expected… lots of modern-style buildings.

Oliver: At night, the downtown was like a mini-Vegas, except with boot stores instead of casinos.

Ryan: So. Much. Food. I’d never had an opportunity to go to Nashville, so it was really fun to see the city despite the fact that we brought 40-degree temperatures with us those first few days. The amount of live music in the city was amazing!


Adam: A very great experience that made me feel closer to the community and the team. I really enjoyed it.

Chris and Dan at the Hook 42 booth during DrupalCon Nashville
Photo credit: Carie Fisher

Aimee: Every DCon is a bit different. It was great meeting contrib maintainers that I've seen online for years and just met in person. It is exciting to see where Drupal and the community is heading! 

AmyJune: Of course, the community is my favorite aspect of every Drupal event. I love meeting the maintainers of projects I have contributed to and discussing further collaboration.

Carie: It was a good DCon. Every year seems better and better, but that could be because I know more people each year, so more like visiting with friends instead of just meeting strangers.

Dan: DrupalCons and camps are always a great experience for me. It’s nice to connect with others from around the world in the Drupal community. Of course, it’s always great to see our team members in person as well. This DrupalCon was fun because I felt more connected with others in the community. There were a lot of people that knew me or at least knew my name from my contributions and interactions, etc. That was a neat feeling.

Darryl: Our company is basically all remote, even the Bay Area locals mostly work from home, so getting to see everyone and chat is great!

Genevieve: As with every other year, I think my overall favorite thing usually ends up seeing all the team members we don’t get to see during the rest of the year. We had some newer team members with us this year, so that was also extra enjoyable to have some new perspectives (and lots of board games… thanks to John) with us. 

John: At this point, every DrupalCon for me is more like a Family Reunion, with the greatest pleasure coming from reconnecting with old friends and getting the chance to interact with team members in-person, especially since we’re practically all remote. It’s always fun making new connections as well, and I was pleasantly surprised to talk to so many people who were new to Drupal (as recent as March!) and loving what they’ve been exposed to so far.

Kristen: The people are always the favorite part… both seeing everyone from our remote team to lots of people from the community from all over the world. Also, I think Core Conversations was an awesome track this year. :)

Oliver: It was great getting to meet some team members in person for the first time and see others again for the first time since BADCamp. Getting to interact in person definitely has a different vibe than collaborating remotely. It was a really great experience.

Ryan: This was my first DrupalCon ever, so I was incredibly excited about finally being able to attend, and it was nothing short of my expectations! I learned a ton, had great conversations, and really enjoyed seeing so many Drupalers in one place at the same time :)

Ryan Bateman playing the guitar in the expo hall at DrupalCon Nashville
Photo Credit: Jeff Geerling

See everyone soon!

We're looking forward to seeing everyone again at BADCamp in the fall... Seattle next year... and in Minneapolis in 2020! In the meantime, keep contributing, keep building community, and keep moving the Drupal project forward!

Apr 23 2018
Apr 23

DrupalCon is more than just a conference for networking and learning; it provides an avenue for contributing back to the project during code/contribution sprints. Being a beginner to the issue queue can be daunting and overwhelming. With the help of mentors, novices can get the tools and support they need to jump in and start contributing.

Chris, AmyJune, Daniel, and John took it upon themselves to volunteer as mentors at the DrupalCon Nashville Sprints and we thought we’d share their afterthoughts to empower others to help with mentoring in the future.


Never having mentored before, I signed up for mentoring on a whim... Mostly because I felt it was something everyone should try to do to help out, in as much as their abilities allow, but also for all the glory that would be bestowed upon us mythical beings at the end of the week.

DrupalCon Nashville Sprint mentos meeting in the morning

Photo credit: David Needham

Seeing that I spend most of my professional life in the land of D7, that I was wary about how much I could contribute, and that I was rather worried about messing up and giving the wrong advice, I started off helping people get set up. Having the Sprint Package was incredibly handy for getting people on a standardized setup, one that I was able to test and retest earlier on in the week to find all of the 'issues'. For the few that wanted to do something different, where I wasn't able to help, there was always someone else around to give a hand, so I never felt like I had to resort to spending 20 minutes on Google trying out different solutions!

From there moving to the first time sprint workshop and helping a team work on some issues collaboratively, reminded me that you don't need to be a D8 guru to help out. Most of the issues were not particularly D8 related, and had us looking for answers in accessibility, finding and reporting new bugs, and working on small CSS fixes. I really enjoyed the energy in the room, the fact that people left feeling as inspired as I had on my first sprint workshop various years ago, and that I had been part of that.


I love contributing to the Drupal issue queue. I enjoy the feeling that comes along with knowing I am moving the Drupal project closer to perfection. Even more than that, I love sharing my knowledge with others, so volunteering to mentor at the sprints was a no-brainer. I don't spend the majority of my time coding, but I have been an active participant in the issue queue for over 2 years. Sharing what I know and inspiring others who are either new to tech or who have roles that have traditionally prevented them from contributing is the real reason I chose to mentor.

Early in the week, Dan and I sat at the Mentoring booth in the expo hall and invited all who would listen to the Friday sprints. We encouraged people from all backgrounds to swing by and check it out.

Dan and AmyJune sitting at the DrupalCon Mentoring table talking with a potential sprinter.

Photo credit: Mike Gifford

I started Friday by welcoming sprinters and directing them to either the First Time Sprinter Workshop if they needed help setting up their local, the Mentored Sprint Room, or the General Sprints. From there, I moved to the First Time Workshop and the Mentored Sprint Room to help folks contribute to documentation. Documentation is so important, it removes a huge hurdle to entry. It’s difficult to feel empowered when you’re lost from the beginning, so helping others to improve documentation feels especially good.


Dan helping a sprinter at DrupalCon Nashville First Time Sprinter Workshop

Photo credit: David Needham

I chose to volunteer because I really enjoy working with the Drupal community. It’s a great way for people to meet other developers and non-developers alike. There is a lot we can learn from one another. We all have different perspectives and hearing/seeing how someone else does something could be a great learning experience for both mentor and mentee. The same goes for general collaboration in the community. I enjoy reaching out with questions to the Drupal slack channels and reading feedback on issues in the issue queues. I love learning from others and seeing things from different perspectives.

Of course, being a mentor is also rewarding. I enjoy the feeling of helping someone learn something new that potentially unblocks them at work or breaks down a barrier to the community contrib space. I enjoy helping as a way of paying it forward for those that helped me along the way. I wouldn’t be where I am without their help.


I was raised with the mentality that whenever you can help out, you should help out. Maybe one day that kindness gets returned, or maybe it doesn’t, but you still leave the world in a better place, and that’s never a bad thing. That being the case, I like to give back to the community wherever I can.

I’ve always enjoyed being a mentor and trainer at camps and cons, and in particular working with people who are just getting started out with something. I remember what it was like to be there, and how things would have been so much easier if I had a guide to point me in the right direction and walk me through those first few steps. While you may not know everything about a given topic, any experience you have is more than someone who’s in the early beginning stages, and the knowledge that you might take for granted as obvious can be worth its weight in gold to someone hearing about it for the first time.

John helping a sprinter at the First Time Sprinter Workshop

Photo credit: David Needham

Even if you’re not super technically savvy in mega hyper fighting web development skills, there are still a great many things that you can do to help out. I mean, one of the things that I did was take attendance, and that’s something simple that anyone could do! Don’t be shy, put yourself out there, and lend a hand where you can. Any little thing that you can do will lighten the load for everyone, and that makes every contribution important.

We hope to see all of you next year in Seattle!!

Remember, you don't have to be technical to contribute to the Drupal project. And, you don't have to be a master to help mentor people on how to get started in the issue queue.

Apr 20 2018
Apr 20

As part of Philly Tech Week this year, Drupaldelphia expanded their scope to include topics like Drupal, Agile, JavaScript (Node.js, Angular, React), case studies, and many more!!

Boomeranging back to Pennsylvania from DrupalCon Nashville, Adam Bergstein will be attending and presenting this year at Philadelphia's premier Drupal Camp.

Can we figure this Drupal Component thing out already?

Our community has seen the rise of countless solutions to implement design systems and components within Drupal. What have we learned? 

This talk shares a perspective on one set of best practices our community should strive to achieve. A future vision will be presented that articulates currently known limitations and presents a path forward. To successfully work toward this goal, and to know when we should embark on this journey, we’ll need to review:

  • Currently known limitations and the appropriate use of core and contributed solutions
  • Recent initiatives like Layout and emerging technology like Web Components
  • What we can learn from other CMS systems like Gutenberg  

To read more about Adam's session and to find out the location and time, visit the session page: Can we figure this Drupal Component thing out already?

Apr 09 2018
Apr 09

In February, we welcomed Scott Vinkle as our guest speaker. Scott is an accessibility expert and front-end developer for Shopify who spoke to our meetup group about creating accessible React JS apps. Scott has been active in the accessibility community since 2011. He has worked with many groups including the accessibility project, the a11y tour, CodePen Ottawa, and many, many others.


The React JavaScript library is a great way to create reusable modular components that can be shared among projects. But how do you ensure your React apps are usable by all kinds of people? Scott Vinkle shared his tips on how to build your React apps with accessibility baked-in!

If you are new to the world of JavaScript or Accessibility, or maybe just need a refresher on either subject, please read Scott’s article for more background information: https://svinkle.me/react-a11y

Can React Apps Be Accessible?

Yes! React apps can absolutely be made accessible for people with disabilities. Here are some areas that Scott presented to the group: how to set a page title, how to create a live announcements component, and how to manage keyword focus between components and when loading new pages.

Scott reviewed React's accessibility linter which comes with each new app. He also spotlighted a fairly new feature with React fragments. Scott also shared some thoughts on writing semantic HTML within React components. He finished up the presentation by going through a small demo app that he created to help illustrate each point.

Some Things to Watch for When First Starting to Develop with React

When it comes to writing HTML attributes in React components, they need to be written in camelcase style. This means when an attribute name is made up of two words, the second word in the attribute must start with a capital letter. For example, the attribute "tab index" needs to be written as "tab index" with the capital "I" (tabIndex). The attribute "content editable" needs to be written as "content editable" with capital "E" (contentEditable). And "max length" needs to be written as "max length" with a capital "L" (maxLength). And it's worth noting that the area and data attributes are exempt from this rule.

There are a few reserved words which come into conflict when writing HTML attributes within your React components. For example, the reserved word "for" is used in HTML when pairing a label with an input element. In JavaScript, "for" is used to loop through items using an index until a specified condition evaluates to false. So, the for attribute needs to be written as "htmlFor". Note the capital "F".

Another example is the reserved word "class" which is in the HTML to allow CSS and JavaScript to select and access specific elements via the class selector. In JavaScript, it's used to create a class declaration. So, when adding a class to an element this needs to be written as "className". In HTML5, there are a few elements which no longer require the closing tag, but in React these elements require the self-closing forward slash.

Example Code: How to Set a Page Title in React

Let's take a look at how to set a page title. First of all, why bother setting the page title content? There are a few reasons why you'd want to do this. For one, it updates the content in the browser tab so sighted users have a better understanding of where they are in the app. Two, it helps to increase search engine optimization. So, when something like Google comes along and indexes your app, it'll have that information. The page title content is often the first bit of information announced by screen readers, so users of assistive technology will have a better understanding of their current place in the app.

So, how do I do this in React? The simplest method that Scott found while doing research was to set the title using the JavaScript "document.title" global property. There is a function called "componentDidMount"; this is a React lifecycle method. The code within this function executes when the component is loaded onto the screen and the single line within this function is using "document.title" to study string value of "my page title".

When this component loads, the page title will be set to this value. It's also worth noting that this is not specific to or unique to React, this method can be used in any JavaScript based application or website. For quicker work, there are other pre-existing components that other developers have made; these components can be included in your project via NPM.

For example, there is React "DocumentTitle" and it can be used by wrapping your content with a document title component. Then you would add a title prop and set its value to the desired page title. The other one is called React "Helmet" and it is used by creating a helmet component. Within this, you can set anything you'd like that would normally appear in the head section of the page.

title code for React JS

For more of Scott's accessible React code examples, please watch the video!


YouTube Video

A11Y Talks February 2018 - Scott Vinkle - Creating Accessible React Apps

Full-text transcript of the video

Links mentioned in the talk:

Drupal Accessibility Group

Join the Accessibility group on Drupal.org for hints, tips, discussions, and patch proposals to help make Drupal more inclusive.

Apr 06 2018
Apr 06

Sarah Maple is the Lead Web Designer at National Nurses United (NNU) and has been at the organization for four years. Her training bridges art and web technology in order to better serve clients with both their technological needs as well as their artistic ones. She provides support with Drupal logistics and project management for the NNU website, which is a full website conversion to Drupal 8.

How would you describe your technical capabilities?

My technical prowess is limited, but I'm probably better than most people at operating computers. I dabble with Python and crunch some statistics in R when I have some free time on the weekends. I can fix the odd microwave or toaster too. I am not a developer by any stretch of the imagination though; I mostly tinker. Sometimes I make something quasi-brilliant, and then it breaks, but it least it was brilliant for a moment. Now that I've taken on the mantle of the web lead within the organization, I find myself doing more development, project management, and content administration these days.

What was your previous website like?

Our previous site used ExpressionEngine. The site was quite limited in terms of functionality, and its performance began to suffer over the years. The ExpressionEngine install was managed by the host, as part of a package they offered at the beginning of our relationship. Eventually we outgrew the capabilities of the web host after several years, and the site was no longer receiving updates to its various plugins and modules. As the site continued to age, the host mentioned that it was going to be put out to pasture and the CMS would no longer receive security updates either. That signaled to us that it was time to transition to a new platform.

Was the Drupal ship the first one that happened to sail by, or did you look into other options?

I had worked with Drupal before when I worked in marketing, so I had some experience there, albeit older experience. This was around the time of Drupal 4 and 5. While researching the latest version of Drupal, I thought it had maintained itself quite well, and even worked hard to improve its appeal to the WordPress crowd in terms of ease of install and administration. Drupal certainly stepped up and was working to cater to the needs of its users. It looked like a solid and well-maintained product. WordPress was another option for us, but we didn't know if it would be able to support the feature sets that we had in mind as well as handle all our content needs. I admit I am less familiar with WordPress, but back on Drupal 4 and 5, I remember feeling like the sky was the limit for Drupal. It could be used for a lot of different things and, even though you yourself may not be able to do something, there was help out there and people you could bring on board to help make your dreams come true.

Ultimately, I was not convinced WordPress could do that for us, and I couldn't find much in the way of knowing how I could optimize WordPress for our needs. We have a lot of content and a lot of files to manage, so I wanted to be sure that our CMS could handle all of that, and still have the flexibility to “tinker under the hood,” like doing deep dives into the templates, and not have the whole thing break down.

What features of Drupal were you looking forward to using the most?

I was particularly keen on using Views again. We are a text heavy organization. We like to do a lot of writing, and we tend to segment our content into very discrete buckets, like by Campaign or by topic. We thought we could certainly leverage the power of Views to dynamically push around more our content and reformat it in ways that would be more meaningful and useful to our user base. Similarly, we wanted to extend and reuse various elements, like with Blocks. We wanted to be able to create a call-to-action, and then push it out to multiple pages at once, helping to create a sense of unity across this rather ranging site.

With the previous site, each page had its own custom markup and we couldn't customize many of the page elements. We were looking forward to leveraging reusable elements to create a cohesive network of nurse resources and campaigns under the umbrella of the NNU site.

Besides WordPress and Drupal, did you look into any other content management systems?

We did take a peek at a few others, just to see what their capabilities were. I reviewed some forums to see what people were doing with Joomla! We also looked at the newest version of ExpressionEngine to see where it was at, but we were not suitably impressed, and it wasn't open source. Drupal and WordPress were the only two under serious consideration. We wanted to utilize something that was enterprise-level, and something we could grow into. We wanted something extensible and open source. There are a lot of content management systems out there, but not many with both a large user base and a large community to help answer your questions, like with Drupal.

What are your personal thoughts or philosophies on open source?

I believe in the “free as in speech, not as in beer” attitude toward software. Whatever gets created should be shared back. I balk at organizations and groups that fork open source projects, then fail to share their developments with the rest of the community. I also believe open source projects need resources, and I endeavor to support them in whatever way they need assistance, whether it be monetarily, or supporting those that continue to lead and build the project up.

Practically speaking, if it's free and open source, you can find people who work on it and develop it. Well-managed open source projects tend to attract a dedicated and talented community of developers and supporters, and I can support the project by hiring from that community. Part of Drupal's appeal is that, while it can be kind of a daunting CMS to learn, it's pretty easy to know if someone knows how to use it -- if they’re from the Drupal community. And I feel it’s a lot easier to identify trusted advisors and developers in Drupal than maybe those who work in WordPress.

Day to day, what is your role in working with your Drupal site?

Now that all our content has been migrated into a brand new CMS, it’s time to revisit many of the major sections of our site with an eye for redesign, remaking pages to match the upgraded styles. Also streamlining content, to make use of Views, Blocks, Paragraphs, and other features of Drupal that will have the site running more efficiently.

What has it been like for the team to acclimate into using the new website?

There have been some growing pains with just wrapping our heads around the vocabulary. We’re still getting used to the Drupal nomenclature. We’ve also been using this as an opportunity to revise and update our workflow. Our old site was very outdated. It didn’t have version control or a secure workflow because it didn't require it and, in many cases, it wasn’t capable of it. We’re catching up though, and that process is a little painful, but very educational. We’ve been trying to follow best practices for development and security, so learning Git, using version control, securing PHP files are all internal processes that we’re working towards. Sometimes, it’s hard to distinguish between whether the difficulty is from the Drupal learning curve or from just catching up with technology in general, but acclimating to the new site has forced some very positive changes for us.

What have been some of the other positive points of using Drupal 8?

Drupal 8 has been very fast, out of the box. It’s faster than the Drupal I remember. The backend authoring features for making content seem more efficient than previous Drupal iterations. Reconfiguring and moving content around is an easier process too. We’ve been using Paragraphs on our site, and it has been a boon for us. The flexibility in being able to add accordions, tab systems, columns, and whatever else might be needed - in a modular framework - has allowed us to create a lot of new layouts and change up how we display our content within those layouts. No one is having to hand code any custom layouts inside the content itself anymore. It's definitely added to our design toolbox, and changed how we serve content while helping us stick within the bounds of our style guide.

What are some of the things Drupal 8 could maybe improve?

The biggest pain points have been making updates to core and contributed modules. The Composer workflow isn't always clear for a novice to understand. In Drupal 7, it was fairly straightforward, but Composer in Drupal 8 can be tricky. Making a security update should be one of the easier things to do, but it’s not always as equally accessible and doable as Drupal 7. File management could also be a little easier. Managing files that are orphaned or outdated is not always intuitive.

For people new to Drupal 8 or Drupal entirely, what kind of advice would you have for them?

To those interested in Drupal: It's important to learn as much as you can. Vet the developers you work with, the people you hire, and the advice that you receive. You need to be capable of assessing the quality of what’s being provided. Drupal can do everything, but that means there are no less than 12 different ways to do the thing that you want, and if you're not careful in how you ask, it can be like dealing with a genie; it's going to be exactly what you want, but come with some caveats. It is not an install-and-forget-it kind of system. It's like a puppy; you have to train it if you want it to behave well and fetch the newspaper. I would encourage people going down this path to keep learning so you can do as much of the work yourself. Where you can’t do the work, you’ll at least have the general concepts, language, and knowledge of your system to help others help you.

Basically, stick with it. It's a powerful content management system that will not let you down if you maintain it. Drupal has the capacity to grow with you and your organization’s needs. Look at it as an investment, and invest in yourself for the long haul.

Thanks, Sarah, for your insight!

For those interested in learning more about NNU's migration from ExpressionEngine to Drupal 8, check out the Hook 42 NNU Drupal 8 case study on Drupal.org.

Apr 05 2018
Apr 05

DrupalCon is one of the most exciting Drupal events all year, especially for those of us who enjoy working in the community. We really get to shine.

This year is no different. It’s nice to share knowledge through presentations, but there are many ways to give back to the Drupal Open Source project.

We are proud to help behind the scenes with the making of DrupalCon. For the third year in a row, our CEO Aimee Degnan has helped organize the Business Summit. Our CTO Kristen Pol is the local Track Chair for Core Conversations this year. Core Conversations is an especially important track as they are normally focused on Drupal's future.

Participating in events at DrupalCon is a quintessential part of the whole Drupal project. Summits bring larger groups together for collaboration and thought leadership; Birds of a Feather (BoFs) provide a more intimate atmosphere for deeper conversation; and sprints move the Drupal project closer to perfection. Of course, the myriad of sessions also provide a great place to learn about a variety of subjects related to the whole Drupal ecosystem.

We’re also excited to be part of a couple social events this year! Not only are we sponsoring the Women in Drupal reception again this year, we'll also be providing fun games, snacks, and smiles for the Drupal Diversity & Inclusion Game Night.


Business Summit

Monday, April 9 from 10:00am - 5:00pm - We're excited because this year we organized a really stellar group of business people tackling challenging current topics. The summit will focus on the growth and evolution of Drupal in the overall digital ecosystem and that growth’s impact to Drupal-focused businesses.

Government Summit

Monday, April 9 from 10:00am - 5:00pm - The Government Summit presents a rare opportunity for collaboration between Government staff, vendors, and Drupal community members to share cost-effective and innovative ways to serve citizens. We hope to provide insight, to listen, and to facilitate discussions that raise awareness. We plan to brainstorm solutions for infrastructure, application development, DevOps, security/compliance, and user-centered design.

Community Summit

Monday, April 9 from 10:00am - 5:00pm - Our community is the heart of Drupal. Sure, it’s great to be involved, but taking the next step and sharing with others how we collaborate and grow our own community is empowering! With this information, we can then better contribute not only to the Drupal Project, but with improving diversity, enhancing mentoring, and growing our local community through outreach.


Contribution sprints move the Drupal Project forward. We’re eager to help with core and contributed projects. We always enjoy mentoring folks who might be new to tech or Drupal, including those who don’t traditionally code for their jobs. Code is very important, but so are all the other parts surrounding it. We’ll be ready to help mentor anybody who wants to get onboard!

General Sprints

April 9-12 from 10:00am to 5:00pm in Room 104A-C in the Music City Center

Sprint Day

Friday, April 13th in Room 104A-C in the Music City Center

Includes General Sprints, Mentored Core Sprint, and First-Time Sprinter Workshop


Connecting Women in Drupal

Wednesday, April 11 at 10:45am in Room 203b - Continue the conversation! After enjoying some low-key networking and socialization at Tuesday night's Women in Drupal social event, swing by our BoF on Wednesday morning. We'll chat about what it means to be a minority in our industry, brainstorm and collaborate on opportunities for activism, and make some lasting connections across the community.

This BoF will be a safe space for anyone who identifies as a woman to chat and support each other. Others, we truly appreciate your support but respectfully ask that this space is kept for women only. Allies are encouraged to attend the Women in Drupal reception Tuesday night.

Drupal and Coffee

Thursday, April 12 at 10:45am in Room 102a - Many of us in the Drupal community enjoy coffee, let's get together and talk about the magic elixir that many of us use to fuel our days.

This is also an excellent opportunity to have a retrospective for the Drupal Coffee Exchange that Adam Bergstein organizes every quarter...Don't know about the exchange?? Whelp, now is a good time to start participating. Bring a pound of beans for trade and get to know your coffee community!

Start your Thursday morning at DrupalCon with some coffee and new friends.

Improving Drupal Core's Accessibility

Tuesday, April 10 at 5:00pm in Room 102a - Drupal 8 has seen significant improvements in its accessibility since the 8.0 release. The point release process has given developers room to make considerable advances in things like the Inline Form Errors module.

Following the Core Conversation on accessibility, we will discuss how we can help bring more people onboard with improving the accessibility of Drupal 8.

Social Events:

Women in Drupal Reception

Tuesday, April 10th at 6:00pm at the Tin Roof, 316 Broadway Avenue, Nashville - Each year we are happy to sponsor and attend the Women in Drupal event! As a women-owned company, we love to support other women’s growth. We’ve always been impressed by the number of allies to women in tech who also come out to the event and show their support! 

Drupal Diversity & Inclusion Game Night

Monday, April 9th from 7PM to 10PM at the Holiday Inn Express Nashville Downtown lobby - Join the Drupal Diversity and Inclusion working group as they host a drop-in style Game Night. One of our goals at Nashville is to do what we can to make it feel like a socially safer space for people. We would like to invite people to bring games and have fun playing them! We expanded the time range a bit because we have some folks who will skip the reception and others that will arrive later.

Catch y'all in Music City!

You can catch us at all the above events, but we’ll also be in the halls offering smiles, swag, and conversation. Swing by the Hook 42 booth on Tuesday, or you can catch some of our team at the DD&I and Mentoring booths as well.

In addition to the events above, we have the honor of presenting four sessions this year! For times and locations, read our article: Cowboy Boots, Hot Chicken, and DrupalCon - Hook 42 is heading to Music City!

Mar 30 2018
Mar 30

If DrupalCon is right around the corner, then Stanford Drupal Camp is right in front of us! We’re excited to spend a couple days almost in our own backyard at Stanford before heading to Nashville. 

We have a bunch of sessions lined up on a variety of subjects... from DevOps to decoupled Drupal, technical acronyms to development tips, and even a case study about a Stanford project. We’ve got something for everyone, so we hope to see you there!

We’re excited to have Aimee, Kristen, Genevieve, Lindsay and Ryan all speaking at the camp. We’ll also be presenting the case study alongside Stanford’s own Robert DeArmond


Things everyone assumed I knew, but I did not.

Lindsay Gaudinier | Friday, April 6th, 3:15pm - 4:00pm | Room 180

Even Sherlock Holmes doesn’t know everything. There are simply too many acronyms and technologies to understand. This talk will discuss some of the concepts I’ve touched, but never really understood. Let’s look underneath the hood and see what’s going on. This talk is about why RTFM (read the full manual) is so useful (if time were infinite).

Hopefully you will learn something new, or come to a deeper understanding of a concept you’ve worked with, but haven’t quite fully grasped.

This talk is a bit about fighting imposter syndrome (what if everyone finds out I don’t know this - well, guess what? Now everyone knows!), a bit of general understanding that can hopefully help others, and a whole lot about how there are too many darn acronyms!

Ideas covered in this talk: TCP/IP, ports, WebSocket, HTTP vs HTTPS, SSH, FTP, SFTP, SSL, and more.

Case Study – Cantor Arts Center Drupal 8 Redesign

Robert DeArmond, Ryan Bateman, Kristen Pol | Friday, April 6th, 4:15pm - 5:00pm | Room 290

In the spring of 2017, Stanford’s Cantor Arts Center came to Hook 42 with a project to redesign their aging website with a shiny new Drupal 8 website that would allow the museum’s exemplary visual arts exhibits and photographic assets take center stage. What followed was a development cycle full of rigorous content strategy, front-end design, and back-end development that culminated in the newly-launched Stanford’s Cantor Arts Center website.

This session will expand upon our methodology and thought process in arriving at each aspect of the site’s development, including:

What Do You Want To Do When You Grow Up?

Aimee DegnanGenevieve Parker | Saturday, April 7th, 10:00am - 10:45am | Room 180

"What do you want to do when you grow up?" is a question we use as an ice breaker for interviews, one-on-ones, and learning / growth plan discussions. It always brings a chuckle and a genuine response from everyone - regardless of age, role, or job position.

But figuring out what you want to do can be hard. Reaching and obtaining your goals can be even harder. Not only for yourself, but for managers and leads, for your team members, too. Turning knowledge into action (the "Knowing-Doing Gap") is also a hurdle in reaching your goals. One may know how they want to grow, but may need some help in how to go about it.

This session will cover methods to create and execute individual improvement plans, hopefully without sounding too menacing.

Seriously - the words "improvement plan" sounds like someone is in trouble! And execute. Dang. This is sounding management-y. In that scary way. That is what many employees feel going into a formal growth plan and review process. "Formal." Another trigger word. Now that person may be scared, unsure, in trouble(?), vulnerable, exposed, overwhelmed. Yikes! 

This session will cover how to get past the fears and baggage to create mutual personal and business growth for your team members.

The topics covered:

  • Quantify the worth of personal growth to the business
  • Align personal growth to the company business goals
  • Techniques for team mentorship:
    • Coaching and supporting the goal setting process
    • Identifying actional, obtainable goals
    • Strategic execution plan to achieve goals
    • Measuring / tracking progress
    • Common challenges with mentorship
    • Working through challenges in a positive, supportive method
    • Tools / templates used to capture and track goals (although this is not the focus)

Target audiences and their takeaways:

  • All:
    • Cool. I can see how to level up and help achieve my personal goals!
    • Wow! I now have a way to articulate where am I now and where do I want to go.
    • I hope my manager / lead / coach / partner will mentor me in this way.
    • Oh, could I apply this to growth within the Drupal community?!
  • Employees / Independants :
    • Identify if your environment is providing the mentorship you need.
    • Use the tools to create some self-planning, should you not have the job support for growth.
    • Have terms and concepts to articulate your needs to peers and management.
  • Management / owner / boss-peoples types:
    • Prerequisites to mentorship relationships.
    • Methods to achieve effective results.
    • You don't need a lot of overhead to create an effective growth plan.

Zero to Decoupled in 30 Minutes

Ryan Bateman | Saturday, April 7th, 11:00am - 11:45am | Room 280A

Decoupled Drupal sites are hard, right? Wrong!

In this session, we’ll detail a method for rapidly scaffolding a progressively-decoupled Drupal 8 site with a React-powered custom content area in no more than thirty minutes. Leveraging Lando's lightning-fast local development setup, JSON API's zero-configuration API solution, and Create React App's single-command React app build tool, we'll throw together a rock-solid decoupled Drupal 8 solution in no time flat. Brace yourself, this will be a fast one!

*Note: no prior knowledge of React is required for this session, but a general understanding of modern JS project architecture will help*

The Developer's Toolbox: Tips and tricks for faster development

Kristen Pol | Saturday, April 7th, 1:00pm - 1:45pm | Room 180

Developers always want to go faster. Repetitive tasks are mind-numbing so we figure out how to make them easy or automated. I've learned new methods for making development faster by watching other developers do their work.

This session is a selection of tips and tricks that can help you streamline your development so you have more time to play outside. Some things we'll cover are:

  • drush
  • console
  • bash aliases
  • browser extensions
  • IDEs

This session is suitable for beginners and intermediates. If you are advanced, share your tips and tricks with @kristen_pol on Twitter.

What mix of DevOps "things" is right for my needs?

Aimee Degnan | Saturday, April 7th, 3:00pm - 3:45pm | Room 280A

Navigating all of the DevOps tools and techniques available can be a daunting task, even for the most seasoned DevOps engineers. The DevOps landscape is always evolving - new tools surface, old tools get either out-performed or un-supported, tried and true tools gain new features and new footing. 

The goal of this session is to surface the best mix of DevOps "things" that are a best (or close to best) solution for real-world development team scenarios.

We will cover some basic topics, define some some common use-cases, then apply DevOps approaches that would best fit the technical and business needs in the scenario.


  • Identify common "needs" profiles (e.g., independents, Agencies, single dev teams, enterprise dev teams)
  • Identify common "scope" profiles (e.g., single project, many projects, complex product w/ integrations)
  • Identify common DevOps tool implementation profiles (e.g., self-hosted, SaaS models, hybrid solutions)
  • Define environmental considerations (e.g., dev staff skills, time / budget constraints, legal requirements)
  • Define common Software PM methods (e.g., Agile / Scrum, Kanban, Waterfall, Giddy-up Cowboy, Eyes Wide Shut)

Level of knowledge required:

Some technical knowledge of N-tier web application architecture. 

If I lost you with that sentence (it really dates me), the following roles will find value in this talk:

  • Technical Project Managers 
  • Dev / IT Departmental Leads
  • Agency tech folks
  • Business / Technical Analysts
  • Developers


  • Have a method to articulate different DevOps approaches independent of tool names. Tool examples will be provided.
  • Have terms and terminology that can resonate beyond the DevOps engineers. (i.e., The People With The Money)
  • Have some sense of what "recipe" of tools and DevOps solution is close to your needs as a starting point.

See you soon!

If you don’t catch our sessions, be sure to swing by The Treehouse Friday and Saturday evenings for some after camp chat!

Mar 09 2018
Mar 09

Adam Bergstein is the VP of Engineering at Hook 42. Previously he was Associate Director of Engineering at Civic Actions and worked at Acquia as a Technical Architect. Adam is an active member of the Drupal Community. He recently took over the simplytest.me project, ported many modules to Drupal 8, is involved in Google Summer of Code, serves on the Drupal Governance Committee, and provides mentorship.

He has given multiple talks. Most of his talks focus on Drupal security, working with teams, or technical enablement.

How long have you been working with Drupal?

My Drupal.org profile states 6 1/2 years, but I worked with Drupal before I had a profile, so probably around 7 1/2 years. I've done many different things, I've worked primarily with the backend; I don't consider myself a front end developer. I work a lot with devops; I like wiring different systems together and automating processes. That has always been a passion of mine and something that comes somewhat naturally.

What is your role working with Drupal and how has it evolved over the years?

My role in Drupal has actually evolved a lot over the years. I started out as a developer and did a ton of custom coding with Drupal as a backend developer. After I learned how to use Drupal and did more site building... and development at the same time... and then more theming... I noticed I wasn't doing a lot of contributing. I started prioritizing that I was going to give back to these modules before I custom code. I wanted to make [the existing] modules better, by contributing patches before I start coding something on my own. Then I started maintaining modules, which evolved into me giving presentations on how I maintain those modules or how I develop them make them or make them more secure. My background is in security. I have a Masters degree in Information Systems and Security from Penn State.

I have about 20 modules I maintain. I have also taken over the simplytest.me project. Simplytest.me is a very evolutionary thing for me because it's a service or product. It covers every aspect of Drupal: DevOps, systems, and development.

When did you start working on Drupal 8, and when did you start to recommend Drupal 8 to your consumers or end users?

I started working on Drupal 8 really early, before the first alpha release. That was about two and half years before it was officially released. And that was when I started porting modules, the first module I ported was Password Policy and I used that as an opportunity to learn Drupal 8. I think I re-wrote that module 3 different times as I learned different things.

I started recommending Drupal 8 to my clients about six months before it was released. Most of the APIs were starting to stabilize, many of the developers I trusted we're starting to port their modules, so I knew there was a lot of momentum. A great thing about Drupal 8 is that you really don't need as many modules, Drupal 7 had a lighter weight core. Drupal 8 is adding features all the time; Layout Builder, translation, and Views are in core. There're all these things that conventionally had to be done through contrib, so there was a little bit lower risk moving to Drupal 8, just based on not having to rely so much on the contributed space as much as Drupal 6 and 7.

I know you have some pretty strong views about sticking with Core when creating reusable content in Drupal 8, would you like to share them?

One of the major things that I advocate for is using core whenever you can. Core is always better supported; there are more eyes on it, because every Drupal installation uses it. My default is always trying to solve problems with core. I've seen this philosophy not be adopted, especially in the content structure and the component design space.

Both of those spaces right now have had people adopting contributed solutions before exploring what needs to be done in core and I boiled it down to a couple of primary limitations. There are some usability issues that make it harder for people to learn and adopt things. The second is revisions, and I know that sounds crazy but that's one piece that isn't really clear right now just exclusively using core. There is some missing revisioning that sometime hurts the adoption of core sponsored stuff.

Let me elaborate on my preferences. One thing I don't like to use is paragraphs. I think Paragraphs is basically reinventing the same problem that can be solved using blocks. The block system was totally rewritten in Drupal 8 and it's much better. There are custom block types, you can create reusable components, and those custom block types are handy for, let's say, making a card component or carousel component. You can build really great data structures that are not leveraging the WYSIWYG, they're fully fieldable, and you can render them and have control over them.

I wrote a module called Block Type Templates that allow custom block types to have their own Twig templates, so you can control the markup. That module is only five lines of code. I generally promote Core, but using a module with that limited amount of code isn’t introducing anything too crazy. It’s just extending the Twig naming convention to blocks, and I'm still primarily making use of everything that's in core.

The only other Contrib module that I have been known to use is Components Libraries, which was written by John Albin, it extends Twig name spacing. It is really useful when Pattern Lab is used because you can pull in Twig files to the other libraries.

I wrote a blog post that basically illustrates all the points I had, but to be very clear I didn't make use of anything that has to do with Paragraphs or Beans. There's a bunch of structural modules and approaches now that I don't think are needed to achieve really good structured content and build really great interfaces. But, I think the main barrier for people is that it's not very usable. I think the new Layout Builder that's in core is going to change all of that once that gets polished and is fully integrated with Settings Tray. It's going to really bring it home.

What advice do you have for people new to Drupal or specifically new to Drupal 8?

Learn how to do it right. I think that people instinctually get a little afraid when there’s a new system; there's now object orientation over procedural programming. They feel they have to learn all these new interfaces, and I feel like they are better opportunities to learn things in a more modern and effective way. Those methods are more in line with the broader PHP Community; more in line with the same designs patterns that are being used in the world. More in line with other CMSs, other frameworks, other languages, and other platforms.

I feel like Drupal finally got to a point where it's doing things in a more modern and scalable way. And that's being proven because Drupal 9 is not going to be a wholesale rewrite, there’s going to be an incremental release where certain deprecated functions are removed. They're going to be using the same standards, the same methodologies for Drupal 8, Drupal 9, and probably moving forward.

There's going to be a lot of incremental changes, but having to learn a whole new way of programming is probably not going to happen in the community for quite some time. People need to embrace it and look at it opportunistically, we're giving them better things and we're learning and evolving at the same time. It usually just comes down to people’s comfort level or maybe their own personal preferences.

It's hilarious, I just wrote a blog post. There are three periods of time, the really short-term, the near-term, and the long term. Short term is to make sure that all the features on the site are working. Whatever small patches or incremental improvements  can be made to do that are going to be made. The near term goals are prioritizing working towards a new system that can better serve the community. And working towards that, it's actually a lot smarter, because the sooner that we can get new vision in place, the better we can serve the community by doing that. I think it not only provides a better service, but it provides greater opportunities for contribution for the community.

Let me give you some examples. We’re creating a brand-new React front-end for simplytest.me. That React front end would give someone the opportunity to learn React or contribute to a tool that's using React, and give people training; submit a patch and look through the code. These are things you might get experience doing if you're doing agency work, but if you're front end developer and don't have the opportunity to learn something like that, Simplytest.me can provide that opportunity. The same thing goes for Docker, we’re replacing the entire provisioning of Simplytest.me instances when you spin up a sandbox, and replacing that with a Docker driven process. It's going to be running Docker commands, spinning up instances based on Docker images, and then tearing them down through standard Docker commands. But, if you want to learn Docker, it gives people a great opportunity.

We’re trying to get into the new space as soon as we can, because it will simplify the simplytest.me architecture and give it a better service. There are some longer term blockers to launching that service, we definitely need to align recurring sponsors, because the cloud systems that were looking to build are not free. These things become a lot easier when everybody pitches in money occasionally. We’re going to be looking at how we create that. And, how we support that to make sure that there's not a financial burden on someone like me or other people specifically interested in keeping this service running.

The future for Simplytest.me is very bright. I think it's going to be a really great framework, and it currently is. But, it hasn't currently kept up with some of the newer technologies. It hasn't caught up with some of the newer things adopted by Drupal 8.

It's a little difficult to maintain right now, but once we get into the new implementation it’s going to be smooth sailing.

What's Adam up to next?

He’ll be speaking at the upcoming Midwest Drupal Camp (MidCamp) in Chicago about his journey from engineer to technical leader in his session My Journey to Understanding Technical Leadership. MidCamp is March 8th - 11th, 2018 at DePaul University Lincoln Park Campus, Chicago.

Adam will also be on a panel discussion with the rest of the Drupal Governance Committee at DrupalCon Nashville. Community Convos: Governance Retrospective is going to open the floor up to the community and be a talk for people to share their voice about what direction Drupal will head. It will be an open dialogue. DrupalCon North America will be April 8-13 in Nashville, Tennessee at the Music City Center.

Mar 01 2018
Mar 01

We are excited to have Adam Bergstein joining our team as Vice President of Engineering! Better yet? He’ll be speaking at the upcoming Midwest Drupal Camp in Chicago about his journey from engineer to technical leader.

MidCamp is March 8th - 11th, 2018 at DePaul University Lincoln Park Campus, Chicago.


My Journey to Understanding Technical Leadership
Adam Bergstein | Saturday, March 10th, 2:45pm to 3:45pm | Room 314A

Great technologists often rise through the ranks, assuming responsibilities that go beyond just delivering technical work. This talk reflects on my journey from an engineer to leading teams. I’ll talk about what I’ve learned, how I learned it, and share my evolving thoughts on technical leadership. I share my perspective on topics like business awareness, servant leadership, failing fast, taking calculated risks, data-driven decision making, promoting pragmatism, and sharing a vision. I discuss my opinions on pragmatism and the balance between technical innovation and practical problem solving in daily work. And, lastly, I share pro tips for leaders I’ve learned from experience, including empathy, listening, limiting ego, and teaching. Attendees can expect to hear my findings on empowering technical teams that strive to better meet the needs of people they serve.


Sunday Sprints will take place in Room 314B, with room for 60 people. Free tickets are available, but be sure to register, so they know how much food and fun to provide.

Sprints are a great place to connect with other members of the Drupal community and give something back to the project. You may even find yourself working alongside some of the module maintainers.

Feb 28 2018
Feb 28

Drupal thrives with love and care from the community. We help move the Drupal project forward by mentoring, sharing knowledge, helping with drupal.org (d.o) issues, and more. If you want to help in the d.o issue queues, you are very welcome! While there are many ways to help, one important piece is reviewing and testing code patches.

Finding a Drupal Core Issue Patch

You do not need to know how to code to test patches. That is important to understand. As long as you reproduce the problem in the issue summary, then you can test a patch when it's ready to be tested. You will know when an issue's patch can be tested when it's been marked "Needs review". If you are not able to review the patch code itself, but can reproduce the issue, please test the patch. Someone else can always do the code review part.

Prior to testing the patch, check to see if anyone else has already tested it. If so, it's best to move on and find another patch that "Needs review" and has not been tested yet. When you find a good issue, you'll need to reproduce the issue without the patch. Then, with the patch applied, go through the steps again to see if the patch did indeed fix the issue.

If you are new to working in the d.o issue queue (or have a limited time to review), a good way to find a patch is to look for the "Novice" tag in the advanced search. But, if you are new to Drupal contributions and go to the drupal.org home page, it's not easy to see how to even find issues.

Drupal Home Page

Here's how you navigate to the Drupal core issue queue search manually:

  1. Go to drupal.org
  2. Login or create an account if you don't have one
  3. From the home page, click "Get the code"
  4. Click "Drupal's project page"
  5. Click "Advanced search" under the "Issues for Drupal core" title

Drupal issue queue

Now you can search for "Novice" or other tags that are of interest to you. For example, if you'd like to help with accessibility or multilingual issues, there are tags for that. When you are first starting though, I recommend finding a "Novice" issue. In addition, you'll want to find one that is in the "Needs review" state.

Read through the issue summaries until you find one that you understand and want to test. Keep in mind, in some cases, the issue may not be easy to test manually. Try to find one that is. If there were older patches, you might find that they were tested so that will give you an idea what needs to be tested for the new patch.

Drupal issue queue novice issue

Example Patch

I went through and found an issue with a patch that was in "Needs review" state and tagged "Novice" and seemed relatively straightforward to test. Here's my issue:


Drupal issue

I found that no one had code reviewed or tested the most recent patch so it was a good candidate to test. I assigned the ticket to myself so that I can test it and let others know I'm working on it. Note that I could test this patch with simplytest.me easily enough. If I were going to do that, I'd click the "SIMPLYTEST.ME" button next to the patch which launches the Drupal site installation process on simplytest.me. I have that "SIMPLYTEST.ME" button when viewing d.o issues because I have dreditor installed for Chrome.

Drupal Issue queue with dreditor installed

Remote vs Local Testing

When testing issue patches on drupal.org, you can test using simplytest.me as mentioned above or via your local development environment. Simplytest.me is good when you don't need the site later (simplytest.me sites only exist for 12 hours) and there are a limited number of patches to apply (no more than 3). It is an awesome tool so use it when you can.

Simplytest.me logo

When simplytest.me does not make sense for patch testing, then you should use your local environment. This could be LAMP, MAMP, WAMP, LEMP, etc. depending on your machine and whether you want to run the Drupal site in a container or not. I'm on a Mac and previously only used MAMP Pro for local development but have been switching over to Lando in recent months.

Lando logo

Installing Lando

Before you use Lando, you need to install it. Rather than bore you with the details here, check out Lando's awesome documentation for installation instructions. One important note is that Lando will install Docker. And, if you are on Mac, you'll need to be on a "not too old" OS version in order to get a more recent version of Docker.

You can use Lando for lots of projects in addition to Drupal (e.g. WordPress and Laravel). On the Lando documentation site, look at the left side for all of the Lando "recipes". One of my favorite recipes is the Pantheon one because it makes working with Pantheon sites even better. For example, it sets up Solr by default so that you can easily do local Drupal Solr development without any extra configuration. Nice!

Some Lando Goodies

Lando bakes in a lot of nice things for you. If you use drush, there is "lando drush <command>" which is essential. If you want to install new modules, composer is already set up so you can do "lando composer <command>". At first it takes a some time to remember to prefix things with "lando" but after awhile it's pretty automatic. Or, you can create some bash aliases like ldrush or ldr to lessen the typing. Running "lando -h" will list the commands but here are a few favorites:

  • lando start
  • lando drush cr
  • lando drush cim
  • lando drush cex
  • lando drush updb
  • lando drush uli
  • lando composer update
  • lando logs

Testing with Lando

At this point, you are probably wondering if we are ever going to test the patch. So... let's do it!

Remember, you need to have Lando (and Docker) installed first. You will also need git installed.

Step 1: Create Vanilla Drupal Site

I picked a Drupal 8 patch to test so I will need to install Drupal 8. But, I want to install it from the Drupal core repository so the steps are a bit different than the Lando Drupal 8 documentation page. Here's a summary of what I would do on my Mac:

  1. Create a directory (on the command line)

    1. cd <directory where I want to put the site>, e.g. cd ~/Sites
    2. mkdir <new directory>, e.g. mkdir drupal8test
    3. cd <new directory>, e.g. cd drupal8test
  2. Find the Drupal core code (in the browser)

    1. Go to https://www.drupal.org/project/drupal/git-instructions
    2. Choose the version you want (important: this should match the issue you will test, e.g. 8.6.x)
    3. Click "Show" button
    4. This will show you the git clone command to use
    5. After you understand this step, you can skip it in the future by manually putting in the branch you need for the patch (see next step)
  3. Get the core code and initialize Lando (on the command line)

    1. Run the git clone from above but add a " ." (space and period) at the end so it ends up in your new directory and not a subdirectory
      1. git clone --branch <branch> https://git.drupal.org/project/drupal.git .
      2. e.g. git clone --branch 8.6.x https://git.drupal.org/project/drupal.git .
    2. lando init
      1. recipe = drupal8
      2. webroot = .
      3. name = Drupal 8 Test
    3. lando start
    4. lando composer install
      1. Note that if this does not work, run "lando restart" and then try again
    5. lando info
      1. This will provide the URL for your site, e.g. https://drupal-8-test.lndo.site
  4. Install the Drupal site (in the browser)

    1. Go to the site, e.g. https://drupal-8-test.lndo.site
      • Because this is https, on Chrome, you might see a "Your connection is not private" page
      • You can click to open the ADVANCED section and then click the "Proceed to drupal-8-test.lndo.site (unsafe)" link 
    2. This should redirect you to the install page, e.g. https://drupal-8-test.lndo.site/core/install.php
    3. Go through the regular installation process
      1. Important: database info can be found using "lando info"
        1. Database name, username, and password, e.g. drupal8, drupal8, drupal8
        2. Host and port should be the internal host and port, e.g. database, 3306
        3. Note your username, password, email address

If all goes well, you'll have a brand new vanilla Drupal 8 site.

New Drupal 8 site

Step 2: Run Drupal-y Things

Let's save our config in case it changes later. We'll run these with drush so make sure drush is working:

  1. lando drush status
  2. If it's not working, run: lando composer require drush/drush

Terminal example

Now run "lando drush cex" and it will save the config into the sync directory.

Step 3: Reproduce the Issue

Now you have a vanilla Drupal site to test on so it's time to reproduce the issue.

  1. Read the issue summary
  2. Follow instructions for reproducing the issue
    • Note that sometimes the steps to reproduce will be in the comments instead of the issue summary. If you find this to be the case, copy/paste the instructions into the issue summary so they are easier to find
  3. If you cannot reproduce the issue, then you should add a comment to the issue saying so and put the steps you followed
    • Screenshots of the discrepancy are good to include in this case
  4. If you can reproduce the issue, that's great
    • If no one has created screenshots of the issue, create them so they can be uploaded to the issue

For my issue, I need to test the message shown when trying to reset password so I went to a new browser where I was not logged in and tried it. I was able to reproduce the problem.

Issue has been reproduced

Step 4: Apply the Patch

Now we need to apply the patch from the issue. Drupal.org has git patch documentation with more instructions but here is one approach on a Mac.

  1. In the browser
    1. Go to the issue
    2. For the most recent patch, right click on the link and click "Copy Link Address"
  2. On the command line
    1. cd <your directory>, e.g. cd ~/Sites/drupal8test
    2. wget <patch url>, e.g. wget https://www.drupal.org/files/issues/1521996-120.patch
      1. You'll obviously need wget installed for this to work
      2. Alternatively you can use curl
    3. patch -p1 < <patch file>, e.g. patch -p1 < 1521996-120.patch
      1. You can use git commands as well (documented in the Drupal.org patch documentation)
    4. If the patch "applies cleanly", then you won't see any errors
    5. If the patch does not "apply cleanly", you may be in the wrong directory (make sure you are in the top level web root)

In my case, the patch applied cleanly.

Patch applied clean

Step 5: Run Drupal-y Things

Some patches require that we run config imports or database updates so it's best practice to run these just in case. Run these drush commands to make sure the site is updated:

  1. lando drush updb
  2. lando drush cim
  3. lando drush cr

Step 6: Test Again

Now it's time to see if the patch did what we expected. Run through the steps to reproduce the problem and take screenshots where appropriate.

The first time I ran through testing, it didn't do what I expected. If that happens to you, that's ok. That is still useful information and should be reported. I tested again (with the patch applied when installing the site) and then it did work.

Testing a Drupal 8 patch (step 1)

Testing results of a Drupal 8 patch

Step 7: Report your Findings

Add a new comment including:

  1. How you tested
  2. Did it work or not
  3. Screenshots (just enough to be useful)
  4. Unassign the issue from yourself, if necessary
  5. Change the state
    1. If it passed manual testing but still needs a code review, leave the state as "Needs review"
    2. If it did not pass manual testing, change the state to "Needs work"
    3. If it passed manual testing and you did a code review and it passed that, add all your notes and mark "Reviewed & tested by the community" (aka RTBC)

Step 8: Keep your Lando Environment (optional)

Now that you have a Lando environment, if you want to do more patch testing, you can keep the one you created already. You will need to get rid of any old patches and update the git repo from before testing new patches. You might also need to reinstall the site with a fresh db if you are testing similar things and old patches affected the database.

  1. Revert your code and get latest (on the command line or via your favorite git tool), e.g.
    1. git reset --hard HEAD
    2. git pull
  2. Wipe out database to reinstall (on command line)
    1. lando mysql
    2. drop database <database name>;
      1. e.g. drop database drupal8;
    3. quit
    4. Reinstall the site with the process above (starting at "Install the Drupal site")

Hope to see you in the issue queue!

Epilogue: While the above steps are focused on Drupal core issue patch testing, the steps are pretty similar if you are doing Drupal "contrib" (module, theme, or distribution) issue patch testing. And, Lando can certainly help if you want to review code patches and maintain code in contributed modules, themes, and distributions. Looks like some follow-up blog posts are in order. :)

Feb 22 2018
Feb 22

In January, we were happy to have Ashley Bischoff as our guest speaker. Ashley talked about embracing plain language for better accessibility. Ashley is an accessibility expert and copy editor for The Paciello Group. She has a knack for taming technical and business writing. She is a heartfelt advocate for plain language. She relishes any chance to comb corporate speak into everyday language. Ashley lives in Dallas, she likes listening to metal and drinking tea.


Writing reports and documentation is nothing new for many of us — we write them all the time. But even though we may do our best to write clearly, those who receive our reports and documentation might not be as familiar with accessibility as we are.

At the end of the day, no matter how technically correct a document may be, our words won't do much good if those who are reading them can't understand what we're trying to say. But writing isn't a black box — there are straightforward techniques that we can use to help ensure that our writing remains accessible.

Plain Language Can Improve Accessibility

Now, for many of us within the field of accessibility, it's common for us to write things like reports, analyses, and documentation specifications. Those are all good things, but you know what, our documentation, reports, and analysis are only as good as what people can get out of them. If people find the writing to be too complicated or hard to understand, then they won't be able to make use of our advice no matter how good it is.

So, what makes some writing more complicated than others? You might even be asking yourself: well how do I know if my writing is complicated? Well, it turns out that people who study language complexity have narrowed it down to two factors. It primarily comes down to sentence length and syllables.

The more complex the material, the shorter the sentences should be. In fact, experts recommend keeping sentences to between 20 to 25 words. The reason that experts recommend this is because when we're presented with a sentence that we're reading, our brain has to ingest that sentence. Our brain has to sort through the words, piece them together, and basically put that puzzle back together to figure out what that sentence means.

Small changes like breaking larger sentences into smaller ones can really make a difference. Sentence length is half the battle. Cutting syllables out is the other half.

Imagine Words as Being a Bit like Tetris Pieces

Tetris pieces come in different shapes and sizes; some are bigger, some are smaller. Some are easier to work with than others. You can think of syllables as the building blocks of words. So, for instance, you can think of one syllable words like being a bit like two block Tetris pieces. You can think of two syllable words, like perhaps "update", as being a bit like a three-block Tetris piece. You can think of three syllable words as about a five-block Tetris piece. This is where things start to get a bit tricky.

When you can, use words with fewer syllables. But sometimes, you have to use a long word. There are instances where long words might be unavoidable. To give one example, the word accessibility has six syllables. It's conceivable that if you were to be writing a report about accessibility, you may well have to use the word accessibility. That's okay. If you are going to be saddled with one or two of these weird shape Tetris pieces, you might be able to get by. So, using long words occasionally is all right. With that being said, the game just wouldn't be fun anymore if you are only handed huge pieces like these over and over and over.

Use Contractions to Avoid Sounding Like a Robot

A copy editor named Tom Freeman analyzed contemporary American English for patterns around how contractions are being used today. He studied a database of words that covered about two decades and four hundred and fifty million words. It covered sources including newspapers, magazines, and TV transcripts. It included sources such as the New York Times, San Francisco Chronicle, NPR, CBS, etc.

Here's what Tom discovered.

He concentrated on newspapers and magazines because these represent how contractions would be used in published writing today. He discovered that "don't" was used almost seven times more often than "do not" and "can't" is used almost three times more often than "cannot". With those findings, he showed that the tide has turned. What was once avoided, is now commonplace.

Other people who study linguistics, like Wayne Danielson and Dominic Larosa, also found that contractions also improve readability. Writing style guides have also been on board the contraction train for years. For instance, the Chicago Manual of Style says that most types of writing benefit from the use of contractions. If you thoughtfully use contractions in prose, it makes reading more enjoyable.

You might still be a little bit skeptical about this. But think back to any sci-fi robot movie, think about the way that the robot talked in those at movies. Invariably, movie robots end up saying stuff like "I will be glad to see them if they do not get mad," rather than saying "I'll be glad to see them if they don't get mad." The reason that movie robots do that is that screenwriters know that the easiest way to make anyone sound like a robot is to take away all their contractions. While that may sound like a cheap trick, it works every time. So, then the next time that you're writing up something at work, or the next time that you're writing up a blog post, ask yourself this: Do I want to sound like an automaton or do I want to sound like a person?


When you're writing

  • Try to aim for an average sentence length of 20 some words.
  • Keep an eye out for any three and four syllable words.
  • Use shorter words when you can, because any little bit helps.
  • Use contractions early and often.
  • Ashley also recommends double-checking what you've written. If you are using a readability analyzer, you can check the reading grade level. You want to aim for a grade level of 9 at the highest. Checking that level is a good way to see whether your writing is suitable for your audience.


YouTube Video

Full-text transcript of the video

Links mentioned in the talk:
PlainLanguage.gov’s list of simpler words: https://plainlanguage.gov/guidelines/words/use-simple-words-phrases
Wikipedia’s list of simpler words: http://bit.ly/wikiplain
Readability analyzer: https://datayze.com/readability-analyzer.php

Drupal Accessibility Group

Join the Accessibility group on Drupal.org for hints, tips, discussions, and patch proposals to help make Drupal more inclusive.

Feb 09 2018
Feb 09

It's said that the adoption of Drupal 8 has been slower than any other Drupal version. The Hook 42 team embraces Drupal 8 and are curious about how others in the community feel. In this inaugural edition of Drupal 8 Interviews, we are spotlighting my mentor and former instructor Mike Anello from DrupalEasy.

Mike is a Drupal developer, trainer, and the co-owner of Drupal Career Online. You might recognize him from his Drupal.org profile name, ultimike, or know his voice from the DrupalEasy Podcast. He has been a part of the Drupal community for almost 12 years. He has contributed back in many ways: code contribution, documentation, mentoring, and event planning. He also volunteers for the Drupal Association as part of the Community Working Group.

What version of Drupal did you start with?

When I started, Drupal 4.6 was the official version, but I didn't actually use it. I had done a little bit of research, Drupal 4.7 was in beta and it had a brand-new form API. I figured I might as well learn Drupal 4.7, that way I wouldn’t have to relearn the form API.

How long have you been working with Drupal 8?

That's a great question. I would say a little over three years. And by working with Drupal 8, I mean code contributions... And that was probably two years before it was officially released.

I know that when I went through the Drupal Career Online in the spring of 2016, you were teaching both Drupal 7 and Drupal 8. Do you teach Drupal 8 exclusively now?

Yes, we been making the transition, every time I teach I would teach a little less of Drupal 7 and more of Drupal 8. The last class I taught, in the Fall of 2017, was all Drupal 8.

And what types of Drupal 8 sites have you worked on?

I've worked with libraries and universities. I have a couple of long term clients, I have one client that I've been working with since before I got into Drupal. They had a static site and I moved them to Drupal 5, then Drupal 7. I'm working on some smaller, I don't want to say "brochure sites" - legal organizations, nonprofits, etc. I'm not doing any media sites right now, but I've worked on them in the past in group projects.

What have some of the challenges been when starting with Drupal 8?

I think if you come from a Drupal 7 background, the biggest challenge is changing your workflow. Once you're in the UI, I don't think it's terribly different. There are some new things, but, the concepts haven't changed all that much. It really has to do with the workflow. With Drupal 8 we should all be using Composer to manage the code base, and that's a big change for some people who have 'drush dl' and 'drush en' tattooed on their forearm. Making the switch from using Drush to Composer is kind of a big deal. And, if you’re a theme or module developer there's a lot of big changes, but I think they're all for the good. I much prefer coding in Drupal 8 than I did in Drupal 7. Site building? I don't think there's too much of a difference.

What are your some of your favorite things about working with Drupal 8?

I think the theming system is fantastic. It's simpler to use than D7. One of the things I teach is module development with Drupal Console. Using Drupal console to scaffold modules is just a stroke of genius; it saves so much time. When I have to write custom modules for clients, it's such a big time saver and it removes a pretty big barrier to entry. If I have to create some big plug-in that I've never created before, I know that I can run a Drupal Console command and get the scaffolding and all the methods I need to populate. It takes a lot of the fear out of module development.

Sounds like you really like Drupal 8, what areas do you think need improvement?

As far as theming is concerned, I think the one pain point that I still have is getting access to variables in Twig. When you're overwriting a template file and you have dive down into an array, or a class, and call some methods in order to get the data. I don't know what the solution is, I have a feeling it's just better documentation or better tools. It might be some better-improved Twig functions.

What advice do you have for those who are just getting started with Drupal and Drupal 8?

Embrace the workflow. If you're just getting started with Drupal, just know that they're so much more to Drupal than what you see in the user interface. If I were to teach just what you see in the Drupal interface I would only be teaching half the story. Understanding how to get your code base, add modules the correct way, how to keep track of everything in GIT, and move things between various environments is crucial. If you want to learn to be a professional Drupal developer, or site builder for that matter, things outside of the user interface are just as important as what you have to learn inside the UI.

What do we have to look forward from you in the Drupal community?

What am I working on now? In the past when I've taught, I standardized my students using Acquia Dev Desktop and I'm looking to move away from that now. I'm looking to make the switch to a Docker based solution. It's difficult to figure out which is best, because I have students from various skill levels and backgrounds, along with various operating systems. What I have to teach has to work on Windows, Mac OS, and Linux. I don't want to teach a separate lesson to Windows users than Mac users. I'm looking for the secret sauce, or secret combination of tools to recommend to our students that results in a professional Drupal development environment that has all of the tools that they'll need, or at least 95% of what they'll want, with a minimum hurdle to install. I don't want people to have to install a bunch of stuff and then spend 30 minutes having to do extra configuration. I like for things to be clean, and for the lessons to be very simple and repeatable.

What’s Mike up to next?

Florida Drupal Camp

You can catch Mike at Florida Drupal Camp Feb 16-18 leading the Drupal 8 Configuration System Basics training on Friday and presenting a follow-up Drupal 8 Configuration System Basics session on Saturday.

Drupal Career Online

The Mastering Professional Drupal Developer Workflows with Pantheon starts February 27th. This is an intermediate training to teach developers how to work with teams on multi-environment based projects on the Pantheon (link) platform. The course runs three half days a week for six weeks.

The Drupal Career Online spring program begins soon. The course is a comprehensive Drupal training program designed to provide the skills it takes for the best possible start in Drupal. Classes start March 26th and runs three half days a week for six weeks. 

Feb 04 2018
Feb 04

We’re stretching our legs, shaking off the snow, and heading to our first camp of 2018! AmyJune and Carie are on their way to Florida Drupal Camp to share their knowledge in "The Theme Park Capital of the World". They’re thrilled to have the opportunity to collaborate and learn with their peers.

Florida Drupal Camp is February 16-18 at Florida Technical College in sunny Orlando.

Along with their sessions, they'll be helping with the Sunday Contribution Sprints!

Carie Fisher and Helena McCabe | Saturday, February 17, 3:15pm to 4:00pm | Auditorium

In this interactive experience, we will start off by talking about how people with disabilities use the internet and how we can make websites more inclusive. Once you’re briefed on the ABC’s of a11y, we’ll delve a little deeper into different personas within the disability community and how web accessibility relates to the specific needs within. You may even get a chance to join in!

Whether you’re a seasoned accessibility pro or you’ve never heard of it before, technical or non-technical, you’ll be able to follow along, participate, and gain valuable new knowledge and insight about how to make your websites more inclusive. 

AmyJune Hineline | Saturday, February 17, 11:00am to 11:45 am | Room 178

Every newbie dreams of being a contributor to the Drupal project. But where do you begin? And more importantly, what are some of the tools to help navigate the adventure successfully? In her session, AmyJune will go over a couple of the tools of the trade that will help you while you work in the Drupal issue queue as a novice.

The session includes a live lightning round demonstration of the process that includes: creating an issue, writing a patch, uploading the fix to Drupal.org, and reviewing the patch for RTBC (Reviewed & tested by the community).

AmyJune Hineline | Sunday, February 18, 1:15pm to 5:00pm | Lobby

After attending AmyJune’s session, stay for the Contribution Sprints on Sunday to put what you’ve learned into action!! She and our long time friend, Cathy Theys will help with Drupal core issue triage and provide mentorship. There are plenty of smaller tasks that can be completed by those new to contributing to Drupal. When everyone pitches in, the Drupal community grows!

Come see us in Florida

We’re excited to share our knowledge and thoughts on Accessibility and Community among the ‘gators, crabs, and Drupalists alike.

If you see one of us out and about, be sure to grab some sticker SWAG.

Jan 19 2018
Jan 19

As an early holiday present, for December's meet-up we had a very special accessibility guest, Heydon Pickering who chatted about "Prioritizing Accessibility.” For those of you who are veterans of the world of website accessibility, you probably already know a lot about what Heydon has contributed to our field. But for those of you new to this field, let me take a quick minute to give you some more background on our speaker.

Heydon is essentially one of the grandfathers of accessibility design and development. He has written and coded a ton of useful things including his Inclusive Design Patterns book (that I highly recommend) and the blog series Inclusive Components as well as his latest GitHub repo inclusive design checklist. If that was not enough, Heydon writes and edits for one of the most popular web design blogs in the world, Smashing Magazine. And works with The Paciello Group, focusing on accessible User Experience Design.


We can't do it all, so we need to prioritize

We can't do everything that we want to do in terms of design and development because we all have certain constraints. We have project budgets, so we don't have an infinite money. We have project time frames, so we don't have an infinite amount of time. And we have limited resources in general staffing and technology and endorsements, plus we have personal obligations, so we can only do so much each day. But the problem is not really with any of that. The problem is the things that we seem to have chosen to do are not the important things. According to Heydon, we have gotten our priorities wrong.

Things we should NOT prioritize in web design and development

  • Nuances of one shade of color vs. another very similar color (beyond if the color passes WCAG 2.0 AA requirements).
  • Integrating latest flavor of tech "hotness" for the sake of using something new, not because it is actually needed.
  • Spending time on small performance gains, such as optimizing CSS selector performance.
  • Optimizing images, when we should just be using less images on our websites.
  • Pixel perfection is not going to happen on websites, so stop wasting so much time on it.

Prioritize the real things

  • Think outside yourself when designing and coding. Get in touch with the reality of the world and its varied users and do actual user testing when possible.
  • What you prioritize says a lot about you and about what you've experienced and about about the kind of problems that you've encountered. Because if you think that you've got the space and you've got the time to worry about these tiny little refinements (like drop-shadow) then you've probably not had a life of crisis.
  • Review the inclusive design checklist for more concrete examples of things you should prioritize when designing and building a website.

When you prioritize you have to compromise. You have to weigh things up. You have to decide what's important and the important thing in the web is to make sure that most people get a decent experience. That's more important than a few people getting an excellent experience.

- Heydon Pickering


YouTube Video

A11Y Talks December 2017 - Heydon Pickering - Prioritizing Accessibility

Full text transcript of the video

Drupal Accessibility Group

Join the Accessibility group on Drupal.org for hints, tips, discussions, and patch proposals to help make Drupal more inclusive.

Next Month

Date: January 24th, 2018 (12pm ET)
Topic: Embracing Plain Language for Better Accessibility
Speaker: Ashley Bischoff (https://twitter.com/handcoding)

Jan 16 2018
Jan 16

There's no such thing as "just a typo."

In Drupal, clients and prospective users see the user interface and documentation first. When we give them demos or when they evaluate the Drupal project, they aren’t just evaluating the code. Grammar, punctuation, readability, and spelling all matter. They give the project credibility. It is just as important to maintain the same high standards with the front facing side of Drupal as we do with the code.

I have been working with Drupal for about three years, and contributing back to the project for a little less than two.

I have learned quite a bit, but, most importantly, I have come to the conclusion that there is no such thing as “just” a typo, “just” a grammar issue, or “just” a documentation patch; not all patches have to fix code to be important.

Ways to get involved:

Getting involved is easy. You don’t have to be a senior developer to give back. There are multiple ways to contribute to the issue queue. Whether you are a Project Manager, Customer Success Engineer, a novice, or hold a non-technical role - there is something you can do to contribute back to the community. 

"It’s really the Drupal community and not so much the software that makes the Drupal project what it is. So fostering the Drupal community is actually more important than just managing the code base." - Dries Buytaert

Report an issue:

If you come across an issue when using the project or evaluating a module make note of it (or them). In your notes include how to replicate the problem(s). If you have a dedicated community lead on your team, pass on the info; if not, you can report the issue in the project's issue queue. The problem can only be remedied if the community knows about it.

Create a patch:

If you’ve found an issue to work on, the next step is to create a patch. This can be the most difficult step, and there are a few ways to make a patch, but there is plenty of documentation on Drupal.org. Remember there is no such thing as “just” a small patch. Every patch moves the Drupal project closer to perfection!

Help test patches and provide useful feedback:

Testing patches and providing feedback is also a great way to contribute, and it is an important part of the process. You can use the Drupal issue queue, Dreditor, and Simplytest.me to review and test patches. Carefully read the issue summary, spin up a site applying the patch, and test the functionality. Be sure to follow the steps for replication and make notes of any ambiguity.

When testing patches, first and foremost, be polite and give USEFUL constructive feedback. It is really helpful to supply screenshots from before and after the patch was applied.

Ask Questions:

Ask questions. All the time. Every Drupaler was once a beginner, but sometimes they forget the steps it takes to learn the process. Asking for clarification of the issue and steps for replication can help make the testing a little easier.

Attend code sprints and allow yourself to be mentored:

Does any (or all) of this sound like something you’d love to do but need a little help to get started? If so, DrupalCon and many Drupal camps have full day code sprints which provide mentoring for people who want to get involved. Mentors can help set up local testing environments, walk through the patching process, and give insights to basic issue triage. If you are interested in helping others get started, you can also sign up to be a mentor.

It takes a village:

Not everyone who works on open source projects is a coder. Smaller tasks help the less experienced gain confidence and experience, which, in turn, leads to more contributions. A more polished Drupal leads to more job security.

The User Interface and functionality of the project are often the first things that potential users of the project see. If they don’t code themselves, the forward facing project is all that they may ever see. Code is very important, but so are all the other parts. With that in mind, typos, grammar issues, or lack of documentation might “just” turn out to be a problem. Remember, the small patches are just as important as those that address code.

It takes a village!

Additional resources:

At the upcoming Florida Drupal Camp, February 16th - 18th, I will be presenting my session: Dred(itor) the Issue Queue? Don't - It's Simple(lytest) to Git in! I have also been helping to organize and lead the Sunday Code Sprints. Come to the Sunshine State to get a complete rundown of the issue queue process and start collaborating with the Drupal project!

Dec 27 2017
Dec 27

When it comes to Atomic Design systems in Drupal 8, there’s hardly a shortage of solutions to choose from. Pattern Lab and KSS Node are certainly among the most popular and the recently released Mannequin looks incredibly exciting. However, in all these aforementioned solutions, exposing that component data to Drupal has never been particularly straightforward.

Additional PHP libraries like Pattern Lab’s Twig PatternEngine, for example, provide robust systems for integration; however, many of these require a bevy of complex build steps and configuration before you can take advantage of their powerful and extensible integration. Even then, the integration made available in these systems typically ends at the template level. There is very little possibility to interact with or implement components through Drupal’s administrative UI.

This lack-of-integration issue is what the UI Patterns module looks to solve. While much of the pattern definition is very similar to the other platforms (in fact, you can even import Pattern Lab definitions directly into UI Patterns), when it comes to integrations with Drupal the process is vastly simplified. By providing plugins that make your custom components available in the Drupal administrative UI, UI Patterns tries to simplify and streamline component implementation.

Here at Hook 42, we’ve just finished developing a brand-new Drupal 8 site for a client that utilizes UI Patterns, Paragraphs, and Display Suite to allow content users to construct complex but consistent user interfaces. What follows is our “field notes” from implementing UI Patterns in a production site.

Drupal as a First-Class Citizen:

The Admin interface for installing UI patterns

Installing UI Patterns and getting off the ground couldn’t be easier. Whereas many other component library solutions require some pretty exhaustive setup, UI Patterns is bundled into an easy-to-install Drupal module that enables all of the functionality of the platform right out of the gate.

This is really notable when compared to the installation process for other component systems. Most component systems are intentionally designed to be platform-agnostic. While this is fantastic for developers who work across multiple platforms (Drupal, Wordpress, Jekyll, etc.), it causes a lot of additional work for developers who work in a single platform (like Drupal), to set up all of the “glue” that migrates the components into your platform of choice.

In the case of UI Patterns, however, all that needs to be done is for the module to be installed – no middleman software required, no Gulp or Grunt tasks to run. Independent contributed groups of components, too, can be easily distributed in the form of either a Drupal module or portion of a Drupal theme. For a great example of this in practice, take a look at the Foundation Patterns module, which exposes components from the popular Zurb Foundation CSS framework by way of UI Patterns. Modules like this highlight a lot of the promise UI Patterns has as a platform for developing turnkey contrib component libraries for Drupal. That’s a huge deal!

Defining Patterns:

Similarly, defining a custom component in UI Patterns is incredibly simple. As mentioned above, patterns can be defined either at the theme-level or in a custom module. Regardless of whether the patterns are found in a module or theme, the file structure is the same.

First, the pattern definition is stored in a YAML file named by the schema ‘PATTERNAME.ui_patterns.yml’. An example pattern definition for a card component might look something like this:

    label: Card
    description: A card that contains some content, and optionally an image and a link.
            type: text
            label: Heading
            description: Card heading.
            preview: A Card Heading.
            type: text
            label: Body
            description: Card body text.
            preview: This is a great card body – it has a ton of information in it!
            type: text
            label: Image
            description: The card image.
            preview: http://via.placeholder.com/350x350

Here’s a breakdown of what each of these definitions do, according to the UI Patterns docs:

  • ID: The root of a new pattern definition (card in the example above). It must contain only lowercase characters, numbers and underscores (i.e. it should validate against [^a-z0-9_]+).
  • label: Pattern label, used on pattern library page.
  • description: Pattern description, used on pattern library page.
  • fields: Hash defining the pattern fields. Each field must have the following properties defined below.
    • type: Field type, can be text, numeric, etc. at the moment only used for documentation purposes.
    • label: Field label, used on pattern library page.
    • description: Field description, used on pattern library page.
    • preview: Preview content, used on pattern library page. It can be either a string or a Drupal render array, in which case we can use keys like type: processed_text or theme: image.

Each pattern definition has a companion template, called pattern-PATTERNNAME.html.twig. A sample template is included below:

<div class="card">
{% if heading %}
{% endif %}
{% if body %}
{% endif %}
{% if image %}
    <img src="http://www.hook42.com/%7B%7Bimage%7D%7D" />
{% endif %}

Variety of Integrations:

The display options for UI patterns, showing off integrations for various contrib modules

One of the most unique features that UI Patterns brings to the table is a multitude of core and contrib module integrations. Out of the gate there are four sub-modules for integration with Layout Discovery, Display Suite field formatters and layouts, Field Group, and Views.

As you might expect, these modules expose your component library to various display management and aggregation modules. For example, once the “UI Patterns Layouts” submodule has been enabled, it becomes dead simple to make your “Article” content type use a “Card” any place the “Teaser” view mode is used.

An unexpected advantage of this tight integration with Drupal is that it makes it feasible for a developer to expose a set of patterns to a site builder and then allow the site builder to do their own work linking the content types and the patterns. Considering that most other solutions require a developer to dig into the codebase every single time a component needs to be implemented in a different location, this is a huge feature. On that front, UI Patterns definitely provides a lot more autonomy for site builders to apply patterns without calling on the assistance of a developer to link the content type and component together manually.

However, it’s worth noting, that there is an option to use your patterns at the template level rather than using them with Display Suite, Layouts, Field Group, or any of the other supported integrations. This method is somewhat buried in the official documentation, listed under the “developer documentation” section. It would seem that most of the documentation tries to guide users toward the Drupal UI methods for integrating patterns into a site. Rendering a component at the template level is also quite easy. UI Patterns exposes a {{ pattern() }} twig function, which takes two arguments: 1) the pattern name, and 2) an array of key/value pairs for any variables passed into that pattern. For example, {{ pattern('button', {title: 'Link title', url: 'http://example.com'}) }} would render a button element with a custom link title text and URL.

Configuration or Code?

Configuration or code in UI patterns

While our experience with UI Patterns led us to really appreciate the convenience of deep integrations with the Drupal administrative interface, there are also some downsides of that design decision.

The encouraged, standard method (according to the UI Patterns docs) for integrating components is by way of in the admin interface – changes that will ultimately live in configuration. The pattern definitions themselves, however, are all done in the codebase through a combination of YAML files and Twig templates. As mentioned above, having the component integration happen at the configuration-level is a real boon for site builders; but, before long there are some severe limitations on those integrations that can get in the way of seamlessly mapping content to your components.

In one instance, we realized that the some of the fields we had exposed in Display Suite weren’t available when mapping the very same entity type in Views. Similarly, some of the field formatting options that are available in Display Suite aren’t exposed in Views. As a result, we needed to work around those inconsistencies. In many cases, we ended up simply resorting to using the twig function and template logic to call out our components. That meant having a fragmentation in our implementation – some of our components were implemented in code, some in configuration. While the outcome is completely functional and serviceable, switching back and forth from code to configuration can get exhausting.

Furthermore, having the ability to map fields in the Drupal administrative UI tends to encourage doing some amount of data “massaging” at the display level – another kind of fragmentation that can cause problems down the road. For instance, if we have a “Button” component that takes a link, we can adjust the display settings for a “Link” field in Drupal to map the text to whatever variable we assign to the button’s text, and the URL to whatever variable we assign to the button’s URL. If this were being handled in code, those would instead be pulled out of the template variables and mapped into a twig {% include %} block.


All in all, our experience with UI Patterns was positive. Despite any frustrations we might have had with the fragmentation across all these different implementations (and the limitations of each), UI Patterns offers an amazing amount of flexibility. Most of all, it is incredibly promising for large organizations that need a way to package and distribute component libraries across different Drupal sites to site builders and content administrators who may or may not have access to the codebase of the sites they’re building.

The possibilities for site-builders are really amazing here! That said, for a project of the size and scope we dealt with, we were left wondering if a template-level solution would have been more streamlined. Sure, the convenience of mapping content type fields to component fields in the Drupal UI was slick, but the consistency and control provided by a template-level solution often looked really tempting.

For many smaller and simpler sites, the GUI options would likely provide everything necessary, but for a more complex build, it might be worth keeping all of your component mappings handled in twig templates. Luckily, UI Patterns provides a simple twig function that allows you to make use of your custom components in any of Drupal’s theme hook templates.

If you’re looking for more information about UI Patterns (which we should mention was largely developed by the fine folks at Nuvole), you can take a look at their drupal.org project page, official documentation, and github repo. Also, if you haven’t had a chance yet, I’d highly recommend checking out Antonio De Marco’s talk from DrupalCon Vienna for a live demo of the module’s general functionality.


About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web