Dries Buytaert: State of Drupal presentation (April 2019)

Last week, many Drupalists gathered in Seattle for DrupalCon North America, for what was the largest DrupalCon in history.

As a matter of tradition, I presented my State of Drupal keynote. You can watch a recording of my keynote (starting at 32 minutes) or download a copy of my slides (153 MB).

Making Drupal more diverse and inclusive

DrupalCon Seattle was not only the largest, but also had the most diverse speakers. Nearly 50% of the DrupalCon speakers were from underrepresented groups. This number has been growing year over year, and is something to be proud of.

I actually started my keynote by talking about how we can make Drupal more diverse and inclusive. As one of the largest and most thriving Open Source communities, I believe that Drupal has an obligation to set a positive example.

Free time to contribute is a privilege

I talked about how Open Source communities often incorrectly believe that everyone can contribute. Unfortunately, not everyone has equal amounts of free time to contribute. In my keynote, I encouraged individuals and organizations in the Drupal community to strongly consider giving time to underrepresented groups.

Improving diversity is not only good for Drupal and its ecosystem, it’s good for people, and it’s the right thing to do. Because this topic is so important, I wrote a dedicated blog post about it.

Drupal 8 innovation update

I dedicated a significant portion of my keynote to Drupal 8. In the past year alone, there have been 35% more sites and 48% more stable modules in Drupal 8. Our pace of innovation is increasing, and we’ve seen important progress in several key areas.

With the release of Drupal 8.7, the Layout Builder will become stable. Drupal’s new Layout Builder makes it much easier to build and change one-off page layouts, templated layouts and layout workflows. Best of all, the Layout Builder will be accessible.

Drupal 8.7 also brings a lot of improvements to the Media Library.

We also continue to innovate on headless or decoupled Drupal. The JSON:API module will ship with Drupal 8.7. I believe this not only advances Drupal’s leadership in API-first, but sets Drupal up for long-term success.

These are just a few of the new capabilities that will ship with Drupal 8.7. For the complete list of new features, keep an eye out for the release announcement in a few weeks.

Drupal 7 end of life

If you’re still on Drupal 7, there is no need to panic. The Drupal community will support Drupal 7 until November 2021 — two years and 10 months from today.

After the community support ends, there will be extended commercial support for a minimum of three additional years. This means that Drupal 7 will be supported for at least five more years, or until 2024.

Upgrading from Drupal 7 to Drupal 8

Upgrading from Drupal 7 to Drupal 8 can be a lot of work, especially for large sites, but the benefits outweigh the challenges.

For my keynote, I featured stories from two end-users who upgraded large sites from Drupal 7 to Drupal 8 — the State of Georgia and Pegasystems.

The keynote also featured quietone, one of the maintainers of the Migrate API. She talked about the readiness of Drupal 8 migration tools.

Preparing for Drupal 9

As announced a few months ago, Drupal 9 is targeted for June 2020. June 2020 is only 14 months away, so I dedicated a significant amount of my keynote to Drupal 9.

Making Drupal updates easier is a huge, ongoing priority for the community. Thanks to those efforts, the upgrade path to Drupal 9 will be radically easier than the upgrade path to Drupal 8.

In my keynote, I talked about how site owners, Drupal developers and Drupal module maintainers can start preparing for Drupal 9 today. I showed several tools that make Drupal 9 preparation easier. Check out my post on how to prepare for Drupal 9 for details.

A timeline with important dates and future milestones

Thank you

I’m grateful to be a part of a community that takes such pride in its work. At each DrupalCon, we get to see the tireless efforts of many volunteers that add up to one amazing event. It makes me proud to showcase the work of so many people and organizations in my presentations.

Thank you to all who have made this year’s DrupalCon North America memorable. I look forward to celebrating our work and friendships at future events!

Sven Decabooter: How to add classes / attributes to Drupal 8 local tasks

How to add classes / attributes to Drupal 8 local tasks

Drupal 8 allows you to define custom tabs (a.k.a. local tasks) in your custom module.
For theming purposes, it might be necessary to add a class, ID, or other HTML attribute to the tab link.

Here is how this can be achieved when defining the local task in your [modulename].links.task.yml:

entity.node.custom:
  route_name: entity.node.custom
  base_route: entity.node.canonical
  title: 'Custom local task / tab'
  options:
    attributes:
      class:
        - 'my-custom-class'

If you want to add an attribute to a local task that is not defined in your custom module, you could use a preprocess function in your theme or module:

/**
 * Implements hook_preprocess_menu_local_task().
 */
function MYTHEME_preprocess_menu_local_task(&$variables) {
  /** @var DrupalCoreUrl $url */
  $url = $variables['link']['#url'];
  if ($url instanceof DrupalCoreUrl && $url->getRouteName() == 'entity.node.custom') {
    $variables['link']['#options']['attributes']['class'][] = 'my-custom-class';
  }
}

Replace the route name in the example above, with the route name of the tab you wish to change the HTML attributes for.

Sven Decabooter
Mon, 04/15/2019 – 11:17

Jeff Geerling’s Blog: Running Drupal in Kubernetes with Docker in production

Since 2014, I’ve been working on various projects which containerized Drupal in a production environment. There have always been a few growing pains—there will for some time, as there are so few places actually using Docker or containers in a production environment (at least in a ‘cloud native’ way, without tons of volume mounts), though this is changing. It was slow at first, but it’s becoming much more rapid.

You might think that Drupal and Docker work together nicely. They definitely can and do, in many cases, as we see with local development environments built around Docker, like Docksal, Ddev, Lando, and even Drupal VM. But local development environments, where the Drupal codebase is basically mounted as a volume into a Docker container that runs the code, differ radically from production, where the goal is to ‘contain’ as much of production into a stateless container image as possible, so you can scale up, deploy, and debug most efficiently.

Drupal blog: The privilege of free time in Open Source

This blog has been re-posted and edited with permission from Dries Buytaert’s blog.

Open Source communities often incorrectly believe that everyone can contribute. Unfortunately, not everyone has equal amounts of free time to contribute.

On this page:

In Open Source, there is a long-held belief in meritocracy, or the idea that the best work rises to the top, regardless of who contributes it. The problem is that a meritocracy assumes an equal distribution of time for everyone in a community.

Open Source is not a meritocracy

I incorrectly made this assumption myself, saying: The only real limitation [to Open Source contribution] is your willingness to learn.

Today, I’ve come to understand that inequality makes it difficult for underrepresented groups to have the “free time” it takes to contribute to Open Source.

For example, research shows that women still spend more than double the time as men doing unpaid domestic work, such as housework or childcare. I’ve heard from some of my colleagues that they need to optimize every minute of time they don’t spend working, which makes it more difficult to contribute to Open Source on an unpaid, volunteer basis.

Or, in other cases, many people’s economic conditions require them to work more hours or several jobs in order to support themselves or their families.

Systemic issues like racial and gender wage gaps continue to plague underrepresented groups, and it’s both unfair and impractical to assume that these groups of people have the same amount of free time to contribute to Open Source projects, if they have any at all.

What this means is that Open Source is not a meritocracy.

Only local images are allowed.

Free time is a mark of privilege, rather than an equal right. Instead of chasing an unrealistic concept of meritocracy, we should be striving for equity. Rather than thinking, “everyone can contribute to open source”, we should be thinking, “everyone deserves the opportunity to contribute”.

Time inequality contributes to a lack of diversity in Open Source

This fallacy of “free time” makes Open Source communities suffer from a lack of diversity. The demographics are even worse than the technology industry overall: while 22.6% of professional computer programmers in the workforce identify as women (Bureau of Labor Statistics), less than 5% of contributors do in Open Source (GitHub). And while 34% of programmers identify as ethnic or national minorities (Bureau of Labor Statistics), only 16% do in Open Source (GitHub).

Only local images are allowed.

It’s important to note that time isn’t the only factor; sometimes a hostile culture or unconscious bias play a part in limiting diversity. According to the same GitHub survey cited above, 21% of people who experienced negative behavior stopped contributing to Open Source projects altogether. Other recent research showed that women’s pull requests were more likely to get accepted if they had a gender-neutral username. Unfortunately, examples like these are common.

Taking action: giving time to underrepresented groups

While it’s impossible to fix decades of gender and racial inequality with any single action, we must do better. Those in a position to help have an obligation to improve the lives of others. We should not only invite underrepresented groups into our Open Source communities, but make sure that they are welcomed, supported and empowered. One way to help is with time:

  • As individuals, by making sure you are intentionally welcoming people from underrepresented groups, through both outreach and actions. If you’re in a community organizing position, encourage and make space for people from underrepresented groups to give talks or lead sprints about the work they’re interested in. Or if you’re asked to, mentor an underrepresented contributor.
  • As organizations in the Open Source ecosystem, by giving people more paid time to contribute.

Taking the extra effort to help onboard new members or provide added detail when reviewing code changes can be invaluable to community members who don’t have an abundance of free time. Overall, being kinder, more patient and more supportive to others could go a long way in welcoming more people to Open Source.

In addition, organizations within the Open Source ecosystem capable of giving back should consider financially sponsoring underrepresented groups to contribute to Open Source. Sponsorship can look like full or part-time employment, an internship or giving to organizations like Girls Who CodeCode2040Resilient Coders or one of the many others that support diversity in technology. Even a few hours of paid time during the workweek for underrepresented employees could help them contribute more to Open Source.

Applying the lessons to Drupal

Over the years, I’ve learned a lot from different people’s perspectives. Learning out in the open is not always easy, but it’s been an important part of my personal journey.

Knowing that Drupal is one of the largest and most influential Open Source projects, I find it important that we lead by example.

I encourage individuals and organizations in the Drupal community to strongly consider giving time and opportunities to underrepresented groups. You can start in places like:

When we have more diverse people contributing to Drupal, it will not only inject a spark of energy, but it will also help us make better, more accessible, inclusive software for everyone in the world.

Each of us needs to decide if and how we can help to create equity for everyone in Drupal. Not only is it good for business, it’s good for people, and it’s the right thing to do.

Special thanks to the Drupal Diversity and Inclusion group for discussing this topic with me.

 April 10, 2019

 3 min read time

 Permalink

Amazee Labs: DrupalCon Seattle Day 4 Recap: Amazee Sessions

DrupalCon Seattle Day 4 Recap: Amazee Sessions

DrupalCon been a very productive conference so far. The first two days of pre-conference sprinting resulted in fixing the testing pipeline of the webpack module, a prototype for using Drupal as a datasource for Gatsby using GraphQL instead of JSON:API and even solved an unexpected issue for the devel module to provide a way to load dump an entity with all its references embedded inside. You can read more about these solutions here.

Blazej Owczarczyk
Fri, 04/12/2019 – 17:45

DrupalCon Seattle Day 4 Recap: Amazee Sessions

After a good Wednesday afternoon, breathing in the calming air of Seattle, Thursday came and it started for me with a breakfast with Victor. He ordered his favourite meal – the Fresh French Croissant and after a short meal, we headed to the venue.

I decided to start the day with the Web components BoF led by Salem Ghoweri. Pega systems use web components a lot and it was interesting to learn about the advantages and pitfalls. IE 11 seems to be the biggest obstacle, especially when it comes to the shadow dom. Polyfilling it is very expensive computationally, so what they did is to actually ditch the shadow dow in browsers that don’t support it natively. In general, looks like web components are getting traction and IE is the main problem, so same as 5 years ago.

The next spot was the GraphQL 101: What, Why, How session by my friend Maria Comas. It started with a brief history of the query language followed by its definition.

Maria Comas

I learned that the reason to build the GraphQL spec at Facebook was because of the need to find a tool that is powerful enough to handle everything Facebook does while staying simple enough so that it’s easy to comprehend by the product developers. The thing Maria likes most about GraphQL is that it is a tool that changes human behaviour.

The session finished on time and there were hardly any questions so we had time to get the best seats for the next Amazee session:  CSS-in-JS and Drupal sitting in a tree… by John Albin Wilkins. On our way there Victor, grave as always decided to make use of his hipster camera and take this photo of me. No comment.

Blazej

John is a natural so his sessions are always entertaining and packed with great content. In this one, he compared 3 different ways of doing CSS-in-js which are:

  • CSS in object literals

  • CSS in template literals and

  • CSS in files (CSS modules)

John Albin

The session summarized the two years of our adventures with the topic while doing both fully and progressively decoupled projects. TLDR; John recommends CSS modules, mostly because it’s the only tool that makes it possible to share the styles between javascript and Drupal. If you’re interested in this topic I would encourage you to check out the recording for the reasoning and lots of interesting details.

After that, I headed to the Considerations of Federated Search and Drupal session by Adam Bergstein. The ability to find content that originates from many different websites is a hard topic which is required by the enterprise clients quite often, so I thought it might be interesting.

Nerdstein started with a high level, generic overview of the system. The structure is similar to what we have in Drupal migrations. He recommended using scrapy. It’s a tool from the python ecosystem which is great because there are many great data manipulation and natural language processing packages. Scrapy also has many destination plugins, e.g. for elastic search, so it’s easy to insert data directly into the search index.

Next, there was lunch and an unexpected booth on the way there – a box with cute, fluffy creatures.

Bunny

I’m not really sure how they ended up there but they definitely made lots of people happy. Here are some photos. Hopefully, they will make you happy as well.

Bunny

Angie “webchick” Byron: “Jumpstart” for the Drupal 9 Readiness Sprint @ DrupalCon Seattle!

Helloooooooo #DrupalCon!

If you’re looking for something to work on at the contribution sprints tomorrow, come to the Drupal 9 readiness sprint! 😀

We’ll be spending the day removing deprecated code from Drupal 8 contributed modules to get them ready for Drupal 9.

Here’s how you can participate! (Whether in-person or remotely!)

If you’re a module developer who would like to “opt in” to having your module reviewed / patched by a new contributor, please create (or find an existing) issue with the Drupal 9 compatibility + Seattle2019 tags!

Agaric Collective: How to use behavior-driven development in Drupal with Behat

Test your Drupal site’s functionality in a human-readable format.

Behavior-driven development is a great way to write tests for code because it uses language that real humans can understand. Once you learn about BDD and its benefits, you may want to implement it in your next project. Let’s see how to implement BDD in Drupal using Behat with the Mink extension.

Read more and discuss at agaric.coop.

Dries Buytaert: How to prepare for Drupal 9

With Drupal 9 targeted to be released in June of 2020, many people are wondering what they need to do to prepare.

The good and important news is that upgrading from Drupal 8 to Drupal 9 should be really easy — radically easier than upgrading from Drupal 7 to Drupal 8.

The only caveat is that you need to manage “deprecated code” well.

If your site doesn’t use deprecated code that is scheduled for removal in Drupal 9, your upgrade to Drupal 9 will be easy. In fact, it should be as easy as a minor version upgrade (like upgrading from Drupal 8.6 to Drupal 8.7).

What is deprecated code?

Code in Drupal is marked as “deprecated” when it should no longer be used. Typically, code is deprecated because there is a better alternative that should be used instead.

For example, in Drupal 8.0.0, we deprecated Drupal::l($text, $url). Instead of using Drupal::l(), you should use Link::fromTextAndUrl($text, $url). The Drupal::l() function was marked for removal as part of some clean-up work; Drupal 8 had too many ways to generate links.

Deprecated code will continue to work for some time before it gets removed. For example, Drupal::l() continues to work in Drupal 8.7 despite the fact that it was deprecated in Drupal 8.0.0 more than three years ago. This gives module maintainers ample time to update their code.

When we release Drupal 9, we will “drop” most deprecated code. In our example, this means that Drupal::l() will not be available anymore in Drupal 9.

In other words:

  • Any Drupal 8 module that does not use deprecated code will continue to work with Drupal 9.
  • Any Drupal 8 module that uses deprecated code needs to be updated before Drupal 9 is released, or it will stop working with Drupal 9.

If you’re interested, you can read more about Drupal’s deprecation policy at https://www.drupal.org/core/deprecation.

How do I know if my site uses deprecated code?

There are a few ways to check if your site is using deprecated code.

If you work on a Drupal site as a developer, run drupal-check. Matt Glaman (Centarro) developed a static PHP analysis tool called drupal-check, which you can run against your codebase to check for deprecated code. I recommend running drupal-check in an automated fashion as part of your development workflow.

If you are a site owner, install the Upgrade Status module. This module was built by Acquia. The module provides a graphical user interface on top of drupal-check. The goal is to provide an easy-to-use readiness assessment for your site’s migration to Drupal 9.

If you maintain a project on Drupal.org, enable Drupal.org’s testing infrastructure to detect the use of deprecated code. There are two complementary ways to do so: you can run a static deprecation analysis and/or configure your existing tests to fail when calling deprecated code. Both can be set up in your drupalci.yml configuration file.

If you find deprecated code in a contributed module used on your site, consider filing an issue in the module’s issue queue on Drupal.org (after having checked no issue has been created yet). If you can, provide a patch to fix the deprecation and engage with the maintainer to get it committed.

How hard is it to update my code?

While there are some deprecations that require more detailed refactoring, many are a simple matter of search-and-replace.

You can check the API documentation for instructions on how to remedy the deprecation.

When can I start updating my code?

I encourage you to start today. When you update your Drupal 8 code to use the latest and greatest APIs, you can benefit from those improvements immediately. There is no reason to wait until Drupal 9 is released.

Drupal 8.8.0 will be the last release to deprecate for Drupal 9. Today, we don’t know the full set of deprecations yet.

How much time do I have to update my code?

The current plan is to release Drupal 9 in June of 2020, and to end-of-life Drupal 8 in November of 2021.

Contributed module maintainers are encouraged to remove the use of deprecated code by June of 2020 so everyone can upgrade to Drupal 9 the day it is released.

A timeline with important dates and future milestones

Drupal.org project maintainers should keep the extended security coverage policy in mind, which means that Drupal 8.8 will still be supported until Drupal 9.1 is released. Contributed projects looking to support both Drupal 8.8 and Drupal 9.0 might need to use two branches.

How ready are the contributed modules?

Dwayne McDaniel (Pantheon) analyzed all 7,000 contributed module for Drupal 8 using drupal-check.

As it stands today, 44% of the modules have no deprecation warnings. The remaining 56% of the modules need to be updated, but the majority have less than three deprecation warnings.

Xeno Media: What you should do about Google’s de-indexing bug.

Since April 6th, Google’s index had been suffering from an unfortunate bug. Affected web sites had pages dropped from Google’s index by the issue (the cause of which they have yet to elaborate on). Those sites affected had URLs stop appearing in search results for any keyword, costing their owners very real traffic and lost business opportunity. John Mueller, Google’s Senior Webmaster Trends Analyst confirmed the issue on Twitter:

Sorry — We had a technical issue on our side for a while there — this should be resolved in the meantime, and the affected URLs reprocessed. It’s good to see that the Inspect URL tool is also useful for these kinds of cases though!

— 🍌 John 🍌 (@JohnMu) April 6, 2019

Google announced that they’d resolved it the following day, but that turned out to be premature. More websites were seeing their URLs removed from the index, proving the issue was not fully resolved.

Finally, late Wednesday night, Google’s Search Liaison, Danny Sullivan, reported through his professional account that they’d fixed the issue:

 

The indexing issue has now been fully resolved. We apologize for the inconvenience. We appreciate your patience as we restored normal operation.

— Google SearchLiaison (@searchliaison) April 11, 2019

 
What should you do?

First, check to see if you’ve been affected. While Googlebot will eventually recrawl your site as part of their normal operations, there’s no reason not to get ahead of it. 

  • Run a Google search for site:yoursite.com to get a results page of everything you’ve got in the index. You can narrow this search by adding important terms to the end, like site:yoursite.com “important keyword”. If your pages are missing, you need to verify it and submit for reindexing.
  • Head to your Google Search Console (if you don’t have this free account set up, now’s a great time.)
  • Under ‘Overview’ on the left, you’ll see a link for ‘URL Inspection,’ a new tool that was made available to everyone last July.
  • Verify the status of each of your missing URLs. If they’re not in the index, click ‘Request Indexing’.

Pages should eventually return to their original ranking in results. That being said, remember that Google’s algorithm doesn’t aspire to get every page into the index – only those of useful value.

One thing to add here – we don’t index all URLs on the web, so even once it’s reprocessed here, it would be normal that not every URL on every site is indexed. Awesome sites with minimal duplication help us recognize the value of indexing more of your pages.

— 🍌 John 🍌 (@JohnMu) April 7, 2019

Also, remember that the core algorithm component, called Hummingbird, and the machine learning component, RankBrain, have been working in the meantime. Changes to a page’s rankings for certain keywords don’t necessarily mean that it’s due to this bug.