Feed aggregator

BADCamp News: Earn Drupal contribution credit while upping your professional development at BADCamp

Drupal News - 7 hours 33 sec ago
Earn Drupal contribution credit while upping your professional development at BADCamp Fri, 09/18/2020 - 12:00 volkswagenchick Fri, 09/18/2020 - 04:38

BADCamp is understanding that there are many different ways that folks can contribute back to Drupal. Not a coder!? Not a problem! We have plenty of opportunities for people to earn contribution credits while working on their professional development. 

Drupal Planet

Dries Buytaert: How governments can help sustain Open Source

Drupal News - 7 hours 4 min ago

Yesterday I wrote about why software funded with tax dollars should be Open Source. Based on the feedback in email and social media, lots of people seem to agree.

Today, I want to highlight how this could be a game changer for Open Source sustainability.

Using Drupal as an example, let's do some quick math. Imagine if:

  • 1,000 government agencies around the world (federal, state, or local) spend an average of $300,000 a year on their Drupal sites.
  • 5% of that investment results in Open Source contributions.

Even if these numbers are conservative, it would lead to $15 million in annual contributions to Drupal: 1,000 x $300,000 x 0.05 = $15,000,000. That could be 150 full-time contributors each year.

In other words, requiring public code in government could be Open Source's best funding mechanism.

Chapter Three: Drupal Backender Learns Gatsby: Speed up Gatsby Builds With Drupal Image Processing

Drupal News - Wed, 09/16/2020 - 12:49

Gatsby Image, along with gatsby-transformer-sharp and gatsby-plugin-sharp, is a common way to handle images in a Gatsby project.  It gives us the power to process source images at build time to create a 'srcSet' for  '' or '' tags, or create versions in grayscale, duotone, cropped, rotated, etc.

When Gatsby builds from a Drupal source, it downloads the source images and processes them to create these image variations which are stored in the public directory. The ability to optimize and art-direct images at build time is great, but build performance suffers while these assets are generated. As a site grows in images, the time it takes to build grows as well. Image processing can take hours, while the rest of the build takes mere minutes.

myDropWizard.com: Drupal 6 core and CTools security update for SA-CORE-2020-007

Drupal News - Wed, 09/16/2020 - 12:27

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Moderately Critical security release for Drupal core and CTools to fix a Cross-Site Scripting (XSS) vulnerability. You can learn more in the security advisory:

Drupal core - Moderately critical - Cross-site scripting - SA-CORE-2020-007

Here you can download:

If you have a Drupal 6 site, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

FYI, there were other Drupal core security advisories made today, but those don't affect Drupal 6.

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Nonprofit Drupal posts: September Drupal for Nonprofits Chat

Drupal News - Wed, 09/16/2020 - 11:24

Our normally scheduled call to chat about all things Drupal and nonprofits will happen TOMORROW, Thursday, September 16, at 1pm ET / 10am PT. (Convert to your local time zone.)

Alberto Rojas from Manati will be giving an update about Layout Builder. We will also discuss whatever Drupal related thoughts are on your mind. If you would like to contribute to the conversation, please join us.  

All nonprofit Drupal devs and users, regardless of experience level, are always welcome on this call.

Feel free to share your thoughts and discussion points ahead of time in our collaborative Google doc: https://nten.org/drupal/notes

This free call is sponsored by NTEN.org and open to everyone.

View notes of previous months' calls.

Security advisories: Drupal core - Moderately critical - Information disclosure - SA-CORE-2020-011

Drupal News - Wed, 09/16/2020 - 10:45
Project: Drupal coreDate: 2020-September-16Security risk: Moderately critical 12∕25 AC:None/A:User/CI:Some/II:None/E:Theoretical/TD:DefaultVulnerability: Information disclosureCVE IDs: CVE-2020-13670Description: 

A vulnerability exists in the File module which allows an attacker to gain access to the file metadata of a permanent private file that they do not have access to by guessing the ID of the file.


Install the latest version:

Versions of Drupal 8 prior to 8.8.x are end-of-life and do not receive security coverage. Sites on 8.7.x or earlier should update to 8.8.10.

Reported By: Fixed By: 

Security advisories: Drupal core - Moderately critical - Access bypass - SA-CORE-2020-008

Drupal News - Wed, 09/16/2020 - 10:32
Project: Drupal coreDate: 2020-September-16Security risk: Moderately critical 12∕25 AC:Basic/A:None/CI:Some/II:None/E:Theoretical/TD:DefaultVulnerability: Access bypassCVE IDs: CVE-2020-13667Description: 

The experimental Workspaces module allows you to create multiple workspaces on your site in which draft content can be edited before being published to the live workspace.

The Workspaces module doesn't sufficiently check access permissions when switching workspaces, leading to an access bypass vulnerability. An attacker might be able to see content before the site owner intends people to see the content.

This vulnerability is mitigated by the fact that sites are only vulnerable if they have installed the experimental Workspaces module.


Install the latest version:

Versions of Drupal 8 prior to 8.8.x are end-of-life and do not receive security coverage. Sites on 8.7.x or earlier should update to 8.8.10.

Once a site running Workspaces is upgraded, authenticated users may continue to see unauthorized workspace content that they accessed previously until they are logged out.

If it is important for the unintended access to stop immediately, you may wish to end all active user sessions on your site (for example, by truncating the sessions table). Be aware that this will immediately log all users out and can cause side effects like lost user input.

Reported By: Fixed By: 

Security advisories: Drupal core - Moderately critical - Cross-site scripting - SA-CORE-2020-010

Drupal News - Wed, 09/16/2020 - 10:31
Project: Drupal coreDate: 2020-September-16Security risk: Moderately critical 13∕25 AC:Basic/A:User/CI:Some/II:Some/E:Theoretical/TD:DefaultVulnerability: Cross-site scriptingCVE IDs: CVE-2020-13669Description: 

Drupal core's built-in CKEditor image caption functionality is vulnerable to XSS.


Install the latest version:

Versions of Drupal 8 prior to 8.8.x are end-of-life and do not receive security coverage. Sites on 8.7.x or earlier should update to 8.8.10.

Reported By: Fixed By: 

Security advisories: Drupal core - Critical - Cross-site scripting - SA-CORE-2020-009

Drupal News - Wed, 09/16/2020 - 10:11
Project: Drupal coreDate: 2020-September-16Security risk: Critical 15∕25 AC:Basic/A:None/CI:Some/II:Some/E:Theoretical/TD:DefaultVulnerability: Cross-site scriptingCVE IDs: CVE-2020-13668Description: 

Drupal 8 and 9 have a reflected cross-site scripting (XSS) vulnerability under certain circumstances.

An attacker could leverage the way that HTML is rendered for affected forms in order to exploit the vulnerability.


Install the latest version:

Versions of Drupal 8 prior to 8.8.x are end-of-life and do not receive security coverage. Sites on 8.7.x or earlier should update to 8.8.10.

In addition to updating Drupal core, sites that override \Drupal\Core\Form\FormBuilder's renderPlaceholderFormAction() and/or buildFormAction() methods in contrib and/or custom code should ensure that appropriate sanitization is applied for URLs.

Reported By: Fixed By: 

Security advisories: Drupal core - Moderately critical - Cross-site scripting - SA-CORE-2020-007

Drupal News - Wed, 09/16/2020 - 09:48
Project: Drupal coreDate: 2020-September-16Security risk: Moderately critical 14∕25 AC:Basic/A:User/CI:Some/II:Some/E:Theoretical/TD:AllVulnerability: Cross-site scriptingCVE IDs: CVE-2020-13666Description: 

The Drupal AJAX API does not disable JSONP by default, which can lead to cross-site scripting.


Install the latest version:

Versions of Drupal 8 prior to 8.8.x are end-of-life and do not receive security coverage. Sites on 8.7.x or earlier should update to 8.8.10.

If you were previously relying on Drupal's AJAX API to perform trusted JSONP requests, you'll either need to override the AJAX options to set "jsonp: true", or you'll need to use the jQuery AJAX API directly.

If you are using jQuery's AJAX API for user-provided URLs in a contrib or custom module, you should review your code and set "jsonp: false" where this is appropriate.

Reported By: Fixed By: 

Lullabot: Designing for Chaos: Finding Order for Olivero

Drupal News - Wed, 09/16/2020 - 08:57

Olivero is a new front-end theme for Drupal 9, meant to be included in Drupal core as the default. Several Lullabots took an initial idea and, on a tight timeline, designed and developed an MVP of the new theme so it could receive feedback from the wider Drupal community.

Drupal Association blog: Time to Vote!

Drupal News - Tue, 09/15/2020 - 11:00

Elections for the next At-Large member of the Drupal Association Board have now reached the voting phase. Voting will take place from now, 15 September, until 30 September at 10 am PDT.

Drupal Association Individual members should check their email inboxes over the next couple of days for their voting slip arriving.

In the meantime, voters should read the candidate’s info pages and watch the “Candidate Chat” videos and consider which of the candidates will help the Drupal Association most effectively fulfill its mission.


As detailed previously, we will be using Helios Voting this year and the voting process looks like this:

  1. Open the voting slip email that was sent to the primary email address defined in your drupal.org profile
    The email will arrive from system@heliosvoting.org -- check your spam folder if you cannot see it, though it will take some hours to send voting slips to each of the 3200+ eligible voters!
  2. Read the instructions there to register your vote
  3. Again, you should receive an email from Helios Voting, confirming the correct registration of your vote
  4. Await the results!

We would like to thank all of our candidates this year for their participation and wish them all the very best of luck!

Have questions? Please contact me: Rachel Lawson.

Evolving Web: Drupal 8/9 Migration: Migrating Media Items and Their Relationships

Drupal News - Tue, 09/15/2020 - 08:40

Since Drupal 8.5, the Media module in core has been a reality and the recommended way to handle media content in Drupal.

If you're migrating from Drupal 7 to Drupal 8 or Drupal 9, this is something you need to take into consideration.

????‍???? Get up to speed on the latest version of Drupal! Join us on September 24 for a free webinar on Drupal 9.

In this blog post, we'll go through a migration example where you'll learn how to migrate media items and their relationships in Drupal.

The Drupal 8/9 Migration Tutorial Series

Before We Start The Problem

We have received a database dump and files backup from our imaginary client.

We need to:

  • Migrate files from articles into Drupal 8 files
  • Create media items for each migrated file
  • Migrate articles to Drupal 8 and add the related media items.
Setting up the Migration Create the migration module

We first need to create a module for our migrations. In this example, we're naming it migrate_example_media. 

We then need to add the following modules as dependencies in the module declaration:

Create a migration group

To group the migrations, we also need to create a migration group. To do so, we’ll create a fairly simple configuration file so that the group gets created when the module is installed. The file’s contents should be as follows:

id: media label: Media Group source_type: Drupal 7 shared_configuration: source: key: migrate_d7Define a new database connection

Next, you need to load the Drupal 7 database into your Drupal 8 installation. To do so, you need to define a new database connection in your settings.php file like this:

$databases['migrate_d7']['default'] = array( 'driver' => 'mysql', 'database' => 'migrate_d7', 'username' => 'user', 'password' => 'password', 'host' => 'db', 'prefix' => '', );

And then you can import the database dump into this new database connection using your preferred method.

Writing the Migrations

Next thing to do is to write the actual migrations. Per our requirements, we need to write three different migrations: one for files, one for media and one for articles.

Since Drupal 8.1.x, migrations are plugins that should be stored in a migrations folder inside any module. You can still make them configuration entities as part of the migrate_plus module, but I personally prefer to follow the core recommendation because it's easier to develop (you can make an edit and just rebuild cache to update it).

Write the file migration

The first migration to write is the file migration. To speed things up, we're placing the files backup into a migratefiles folder in sites/default/files and we'll copy the files from there to the right folder during the migration.

The source section of the migrate plugin looks like this:

source: plugin: d7_file scheme: public constants: migrate_files_path: 'sites/default/files/migratefiles'

We're setting migrate_files_path to be the base path where we put the backup files. This will be used later to copy the files to the right location.

The process section of the migrate file looks like this:

process: filename: filename replaced_filepath: - plugin: str_replace source: filepath search: "sites/default/files/" replace: "" source_full_path: - plugin: concat delimiter: / source: - constants/migrate_files_path - '@replaced_filepath' - plugin: urlencode uri: plugin: file_copy source: - '@source_full_path' - uri filemime: filemime status: status created: timestamp changed: timestamp uid: uid

First, we create a temporary replaced_filepath to remove the path prefix. Then, we'll use the concat plugin to create the source_full_path based on the migrate_files_path constant and the replaced_filepath. Then, for the uri, we use file_copy to copy from this source_full_path to the destination URI. The remaining fields are directly mapped from Drupal 7 values.

You can look at the full migration file in the code samples repo.

Write the media migration

The media migration also uses d7_file as the source. We use the skip_on_value plugin in a temporary temp1 field to skip files that are not images:

temp1: - plugin: skip_on_value method: row not_equals: true value: - image/png - image/jpg - image/jpeg source: filemime

We use migration_lookup plugin to add the actual image files like this:

field_media_image/target_id: - plugin: migration_lookup migration: file source: fid

You can look at the full migration file in the code samples repo.

Write the article migration 

The article migration is pretty similar to any other entity migrations. To set the image, we're using the sub_process and migration_lookup plugins like this:

field_image: plugin: sub_process source: field_image process: target_id: plugin: migration_lookup source: fid migration: media_image

So that it looks for the right items in the media_image migration. You can look at the full migration file in the code samples repo.

Running the Migrations

Since we have set dependencies, we can instruct Drupal to run the migration group and it will run the migrations in the right order.

To do so, execute drush mim --group=media and the output will look like this:

[notice] Processed 3 items (3 created, 0 updated, 0 failed, 0 ignored) - done with 'file' [notice] Processed 3 items (3 created, 0 updated, 0 failed, 0 ignored) - done with 'media_image' [notice] Processed 3 items (3 created, 0 updated, 0 failed, 0 ignored) - done with 'article'

You can also run drush ms to see current migration status:

--------------------- ----------------------------------- -------- ------- ---------- ------------- --------------------- Group Migration ID Status Total Imported Unprocessed Last Imported --------------------- ----------------------------------- -------- ------- ---------- ------------- --------------------- Media Group (media) file Idle 3 3 0 2020-08-24 16:06:10 Media Group (media) media_image Idle 3 3 0 2020-08-24 16:06:10 Media Group (media) article Idle 3 3 0 2020-08-24 16:06:10Next Steps + more awesome articles by Evolving Web

Manifesto: Assessing your Drupal 9 Readiness, Part II: Who is afraid of contrib modules updates?

Drupal News - Tue, 09/15/2020 - 05:04

In this series of blog posts, we want to help tech leads and project managers assess how ready their projects are for Drupal 9. In Part 1, we estimated the possible amount of work it takes to make  custom modules compatible with the new major release. If you’ve already done this, then congratulations! …If you. Continue reading...

The post Assessing your Drupal 9 Readiness, Part II: Who is afraid of contrib modules updates? appeared first on Manifesto.

Specbee: How to toggle between Dark and Light Mode in Drupal 8 (or 9) based on user preference

Drupal News - Tue, 09/15/2020 - 04:12
How to toggle between Dark and Light Mode in Drupal 8 (or 9) based on user preference Varun Rao 15 Sep, 2020 Top 10 best practices for designing a perfect UX for your mobile app

How awesome would it be to give your users the freedom to customize their interface to as per their preference? While many users prefer a light interface (light background with dark text), some users choose a dark interface (dark background with light text). Darker interfaces are perceived as cool and trendy while some also believe it reduces strain on the eyes especially for developers who spend a lot of time in front of the screen. I believe that providing an option to your users is a tremendous win in terms of accessibility and user experience. There are a couple of ways with which one can accomplish this. In this article, we will discuss on how to toggle between dark/light web design modes and implement this in Drupal 8 or Drupal 9.

We will be focusing on two methods to implement this -
1.    Using only CSS.
2.    Implementing the CSS & JS toggle switch

Using only CSS

To achieve Dark mode on any website with only CSS, one must keep in mind some of the system requirements.

One such important requirement is the system-wide dark mode. If a user prefers to use dark mode on his PC, then the user is served with a website which shows a dark-colored background with light text on it.

The prefers-color-scheme (media query) is used to identify if the user has requested the system to use a light or dark color theme.


1.    Declare the CSS variables.
2.    Use the variables wherever it is necessary.

The result:
See the Pen Prefers-color-scheme (Auto dark/light mode) by Varun Rao (@varoonrao) on CodePen.

Note: To emulate the result on some unsupported devices, just enter DevTool by pressing F12. Next, press CTRL+SHIFT+P, then search for prefers-color-scheme: dark and press enter.  

Implementing the CSS and JS toggle switch

If we are going with this approach, then we don’t need to bother about the system requirements. Just write couple of lines of CSS and JS and you should be ready.

Once we have initialized the variables, we can reference these variables in our stylesheets.

This will be the HTML structure to toggle between dark and light mode.

                                                       HTML Structure

And some lines of CSS should result in this switch.

The Switch

The final part is to add a bit of JavaScript to tie it all together.
●    Store the user preference for future visits
●    Check for saved user preference, if any, on load of the website

That's it! Check out the full demo below.

See the Pen DARK/LIGHT with js toggle switch by Varun Rao (@varoonrao) on CodePen.

Or click here to view the demo.

Implementing the Dark / Light Toggle in Drupal 8 (or Drupal 9)

To start with creating a custom Drupal 8 theme, please refer the awesome article here. Let us now start creating a theme to show how to use dark theme/ light theme in Drupal 8 or Drupal 9.
The file structure will look like this: 


Now, update the header section inside the page.html.twig with the following code.

        {{ page.branding }}
        {{ page.navigation }}
The rest of the HTML structure will be dependent on your design or requirements.
Once you are done with the HTML structure, it is time to make them look nice by styling the elements in CSS.
First, you have to create all the default variables which will be responsible for the colors on Light/ Dark mode.


:root {
  --color-background: #f0f0f0;
  --color-header: rgb(14, 33, 141);
  --color-header-text: #aecafa;
  --color-text: #2c0000;
  --color-card-bg: #fff;
  --color-link: rgb(255, 0, 0);
/* Variable decleration for dark mode */
[data-theme="dark"] {
  --color-background: #1a1a1a;
  --color-header: #aecafa;
  --color-header-text: 0e218d;
  --color-text: #d3d3d3;
  --color-card-bg: #435561;
  --color-link: #24ce24;

Now that you are done defining the variables, it is time to add style to the Header section to get the required result.
.header {
  display: flex;
  justify-content: space-between;
  align-items: center;
  padding: 10px;
  border-bottom-right-radius: 10px;
  border-bottom-left-radius: 10px;
  background-color: var(--color-header);

.header a {
  color: var(--color-header-text);
  text-decoration: none;
  font-weight: bold;

.region-navigation {
  display: flex;
  justify-content: center;

ul.menu {
  display: flex;
  justify-content: center;

ul.menu li {
  margin-right: 30px;

.switch-wrapper {
  display: flex;
  align-items: center;

.switch {
  display: inline-block;
  height: 34px;
  position: relative;
  width: 60px;

.switch input {
  display: none;

.slider {
  background-color: white;
  bottom: 0;
  cursor: pointer;
  left: 0;
  position: absolute;
  right: 0;
  top: 0;
  transition: 0.4s;

.slider:before {
  background-color: rgb(255, 196, 0);
  bottom: 4px;
  content: url("../assets/sunny-day.svg");
  height: 26px;
  left: 4px;
  position: absolute;
  transition: 0.4s;
  width: 26px;

input:checked + .slider {
  background-color: rgb(36, 36, 36);

input:checked + .slider:before {
  transform: translateX(26px);
  content: url("../assets/night.svg");
  background-color: rgb(59, 116, 223);

.slider.round {
  border-radius: 34px;

.slider.round:before {
  border-radius: 50%;
Please note that the styling may vary according to your requirements.
After all the styling, it is now time to write some functionality in Jquery code.
The Jquery code will look something like this (script.js in our case)


(($, Drupal) => {
  Drupal.behaviors.mainMenu = {
    attach(context) {
      const toggleSwitch = document.querySelector(
        '.switch input[type="checkbox"]'
      const currentTheme = localStorage.getItem("theme");

      if (currentTheme) {
        document.documentElement.setAttribute("data-theme", currentTheme);

        if (currentTheme === "dark") {
          toggleSwitch.checked = true;

      function switchTheme(e) {
        if (e.target.checked) {
          document.documentElement.setAttribute("data-theme", "dark");
          localStorage.setItem("theme", "dark");
        } else {
          document.documentElement.setAttribute("data-theme", "light");
          localStorage.setItem("theme", "light");

      toggleSwitch.addEventListener("change", switchTheme, false);
})(jQuery, Drupal);

And don’t forget to include your JS and CSS files inside your theme_name.libraries.yml file.

  version: 1.x
      css/style.css: {}
    js/script.js: {}
    - core/jquery
- core/drupal
Now clear the site cache to see the result. Your end result should look like this :



UI/UX developers sometimes prefer creating two separate themes for light and dark themes. However, an easier and more time-saving option would be to design the theme in a way where the user can toggle between light and dark modes easily. I hope you have found this article on implementing the toggle in Drupal 8 (or 9) helpful. Contact us to know more about our Drupal development services and how we can help you.

Drupal Planet Drupal Development Drupal Drupal 9 Shefali ShettyApr 05, 2017 Subscribe For Our Newsletter And Stay Updated Subscribe

Leave us a Comment

  Shefali ShettyApr 05, 2017 Recent Posts Image How to toggle between Dark and Light Mode in Drupal 8 (or 9) based on user preference Image Testing Your Drupal Website just got easier with Behat (A comprehensive tutorial) Image Design VS Code – Why should they go hand-in-hand? Want to extract the maximum out of Drupal? TALK TO US Featured Success Stories

Know more about our technology driven approach to recreate the content management workflow for [24]7.ai


Find out how we transformed the digital image of world’s largest healthcare provider, an attribute that defined their global presence in the medical world.


Discover how a Drupal powered internal portal encouraged the sellers at Flipkart to obtain the latest insights with respect to a particular domain.


Debug Academy: Why you should focus on learning HTML and CSS

Drupal News - Mon, 09/14/2020 - 10:51
Why you should focus on learning HTML and CSS

You’ve probably noticed we have a course called “HTML/CSS Ramp-Up” and are wondering if this is the right place for you to start on your journey to learning how to build websites. You could be looking to do front-end development, you could be looking to do site-building in Drupal or Acquia’s Site Factory, or you could still be wayfinding and trying to figure out if front-end or back-end is the right path for you. No matter the case, the HTML/CSS ramp-up course Debug Academy has put together will give you an introduction to the essential components of every website.

lindsey.gemmil… Mon, 09/14/2020

Tag1 Consulting: Simplifying your workflow: Getting started with DDEV

Drupal News - Mon, 09/14/2020 - 08:24

In his Drupal 4 Gov webinar Using tools and Git workflow best practices to simplify your local development, Tag1 Senior Infrastructure Engineer Greg Lund-Chaix talks about some of the ways that teams struggle when they become successful and need to learn to scale. One of his primary focuses for teams is helping them learn how to improve their development workflow.

Read more lynette@tag1co… Mon, 09/14/2020 - 08:46

Angie "webchick" Byron: Running both Drush 8 (for Drupal 7) and Drush 10 (for Drupal 9) at the same time

Drupal News - Mon, 09/14/2020 - 03:49

These days, my life is all migrations, all the time, which means I often need to run Drupal 7 and Drupal 9 sites side-by-side simultaneously to compare the results.

The problem?

The latest version of Drush, Drush 10, only works on Drupal versions 8.4+. To use Drush on Drupal 7 sites, you need an older version, Drush 8. And both of them use the command drush. Tricksy...

There are various Drupal-knowledgeable local development environments, such as Acquia Dev Desktop, Lando, DDEV, and Drupal VM that handle this complexity for you, which is super handy. However, the rest of my team uses a "from scratch" local development environment on Mac OS X, so I needed to figure out how to do this by hand.

I made a Twitter inquiry if there was an existing tutorial on how to do this, and since I couldn't find one, here it is. :) Hopefully this helps others, as well! (Thanks to those who responded, pointing me in the right direction!)

1. Installing Drush 8 for your Drupal 7 sites

https://docs.drush.org/en/8.x/install/ are the installation docs for Drush 8. While the recommended way to install all versions of Drush is to pull it in as a local Composer dependency (we'll go through that route in a sec), almost 0% of Drupal 7 sites are installed with Composer (and mine certainly weren't :P), since Composer was not even a "thing" back then. This means you typically need to install it instead globally, so it's available to all D7 sites on your computer.

To do this:

1. Go to https://github.com/drush-ops/drush/releases and download the latest Drush 8 release's "drush.phar" file (as of this writing, 8.4.1).

2. Test that it's working by attempting to run it with PHP:

$ php PATH_TO_DRUSH/drush.phar --version
Drush Version : 8.4.1

3. Since it's super annoying to type php PATH_TO_DRUSH/drush.phar all the time, make it executable and move it somewhere in your $PATH.

chmod +x drush.phar
sudo mv drush.phar /usr/local/bin/drush

Now you can execute with just drush [whatever] from within a given Drupal 7 site's docroot. Perfect!

2. Installing Drush 10 for your Drupal 8/9 sites

Well. Perfect except for the not-so-minor detail that despite Drush 8 working surprisingly well for not being supported in Drupal 8.4+, it is nevertheless not supported in Drupal 8.4+. Also, there are newer, useful commands in Drush 10 that are not available in Drush 8, such as drush config:satus.

So! Let's fix this by adding Drush 10 to our Drupal 9 site. https://www.drush.org/install/ has the installation instructions.

The "best practice" way to do this is in Drupal 9, since the code base has already been "Composer-fied" out of the box (thanks, Composer initiative!) is to add Drush in as a dependency:

cd PATH_TO/drupal9
composer require drush/drush

Check to make sure it's working:

drush --version
Drush Commandline Tool 10.3.4

Move back to your Drupal 7 directory and you should see:

drush --version
Drush Version : 8.4.1


3. That's it. Don't do anything else. ;)

I figured I would need Drush Launcher to finish things off, but it appears that Drush 8 has some basic launch-like capabilities in it, because it automatically switches from one to the other seamlessly. Nifty!

And in fact, if you do install Drush launcher, Drush 8 won't work anymore. (Womp, womp.) Which brings us to...

It says "command not found" when I type "drush"
That probably means that the place you moved Drush 8 to is not in your $PATH. Try echo $PATH and move it to somewhere in that list, or add your desired location to $PATH in ~/.bash_profile
It says "mv: rename drush.phar to /usr/local/bin/drush: No such file or directory," but /usr/local/bin exists!
Don't forget to chmod it first.
When I run "drush" from within Drupal 7, it says "The Drush launcher could not find a Drupal site to operate on."
Ah, you skipped the tutorial and installed Drush Launcher. ;) Following those steps will blow away your Drush 8 installation, which also lives at /usr/local/bin/drush. You can either re-do the steps above to use Drush 8, and thus kill your Drush Launcher (Drush 8 seems to have basic Drush Launcher capabilities, which is nice), or you can Composer-ize your Drupal 7 code base and then add Drush 8 as a dependency, just as you did with Drush 10, with:

composer require drush/drush:~8

Tags: drupaldrushdrupal 7drupal 9migratelocalhost

Ryan Szrama: Reflecting on the changes to Drupal Association election voter eligibility

Drupal News - Sat, 09/12/2020 - 22:54

The Drupal Association (D.A.) Board decided in May to update the eligibility criteria for voting in the election of At-Large Directors of the D.A. These are the members of the Board whose purpose is to “reflect and represent the Drupal community at large,” and their election is to be “by the community” and dependent on “[ratification] by the rest of the Board.” We changed the voter eligibility criteria for these elections from requiring community members to have logged in to drupal.org in the year prior to nominations opening to requiring them to have an active D.A. Membership prior to the start of voting.

As we wrote in our statement about this resolution, we believe we failed as a Board to consider how to engage the community and communicate the change proactively. I personally endeavored to answer as many questions as I could in various threads on Twitter, but Twitter is a poor place for long answers, nuance, or organized communication. As such, I solicited specific questions I could answer in this post as a member of the Board who approved the resolution.

A word before I dive in: this post contains my personal recollections of fact and statements of opinion, and I’m not speaking herein on behalf of the full Board. We’re fifteen different individuals with unique perspectives on this discussion and virtually every topic we approach. In places where I’m answering questions of fact, I ask the reader to be gracious - just because I’m stating how something occurred (e.g. “neither the discussion nor the final resolution were controversial to the Board”) doesn’t mean I or the Board don’t understand competing opinions or wouldn’t accept other points of view as legitimate alternatives.

I also wish I could have prepared this post faster, but finding a solid 8 hours to give to the task has proven difficult. My family was gracious to give me most of this Saturday for it, and while I'm sure I won't satisfy every critic, I hope the post is received as my honest attempt to plainly, directly answer your questions.

Ok, diving in!

I’m going to follow Sally Young’s list of questions as a general outline and try to address as many questions or concerns as I can that were raised in the various Twitter threads by other community members.

1. What was the impetus for the change being tabled?

I didn’t write the initial proposal and can’t recall which specific conversation would have birthed it. However, I believe the resolution was generally a byproduct of recurring conversations at Board meetings about continuing to evolve the D.A. and its Board in pursuit of its mission. These conversations include comparative analysis, advice and counsel from outside experts, and books and reference material designed to help organizations like ours mature.

You can see the results of these conversations in who we hire to be Executive Director, who we recruit to serve on the Board, how we work to diversify our staff, programs, and revenue, and how we clarify who our stakeholders are and how we serve them. These conversations have included questions about the meaning and purpose of both individual and organizational supporters of the D.A., and as far as I can recall, our discussions on the topic of the resolution were primarily a matter of alignment - that people who desire a say in who should lead the organization, or who desire to serve as its leaders, ought to be individually committed to the organization through a D.A. Membership.

I understand there are people who conscientiously object to D.A. Membership for a variety of reasons, including its structure, its prior decisions or actions, its current programs, or a sense that contribution “ought to be enough.” While I wish they were able to find common cause and become advocates for the D.A. as the primary organization responsible for the Drupal community’s infrastructure, I don’t begrudge them their abstention. I would likely even agree with them on various critiques of the D.A. - nobody believes it's perfect! I just don’t believe people who intentionally refuse D.A. Membership or who believe the D.A. as it is shouldn’t even exist must be given a say in who leads it.

(Note: lest I be accused of saying such people don’t matter, please understand that I am talking about the leadership specifically of the D.A., which is distinct from but exists to serve the Drupal community at large. You can be a contributor to the project and a leader in the community without believing in or respecting the D.A. While I might disagree with your position, it wouldn’t make me respect you or value your contributions any less, nor would I expect the D.A. not to work hard to serve you. By nature it serves the whole community, and in many areas it solicits guidance and feedback from a wide variety of individuals, working groups, committees, etc. to attempt to do so even better.)

To Sally’s follow-up questions on this point regarding specific expectations for engagement or data-driven analysis, all I can say, even if it’s unsatisfying, is this wasn’t a data-driven decision. We saw it as correcting a misalignment and trust the staff of the D.A. to find new ways to activate and empower individuals who maintain a D.A. Membership, including those who perhaps through this very discussion engage the D.A. for the first time.

2. What was the process of this being proposed?

The resolution was presented to the Board for discussion at our meeting in May. From my memory, we had previously discussed this topic at an earlier strategy meeting, so I don’t believe it was a surprise to anyone or that anyone expressed concerns with respect to the text of the resolution itself. We approved it by the unanimous consent of all those present, including myself (who previously served as an At-Large Director) and our two currently serving At-Large Directors.

3. What percentage of people who voted in the previous election were D.A. members?

Unfortunately, I don’t know the answer to this, and I can’t say off the top of my head what it would take to find out (i.e. do we have the data in the right shape and places to run such a query?). I’m sure a significant percentage of voters were not D.A. members, because only a small fraction of all eligible voters under the prior criteria were D.A. Members. (I do expect D.A. Members were overrepresented in the vote; I'd love to see the actual statistics on this, too.)

That said, I do know that we have significantly more Individual Members of the D.A. than we have had participants in any recent election. I gathered the statistics from the last 4 elections from the D.A. blog, and the numbers aren’t particularly encouraging. (I’ll save my reflections on the trend for another post; trying to stay focused here...) We have over 2,900 Individual Members in our directory, but we have averaged only 1,345 voters over the last four elections with an average turnout of only 1.59% of eligible voters.

I’m very curious to see the numbers from the upcoming election.

4. [With respect to the text of the by-laws stating the corporation has no members,] when an individual signs up for a membership, what status are they within the organization?

(Let me state the obvious here: I am not a lawyer or an expert in nonprofit law. While I consulted a lawyer to understand the meaning of our by-laws on these points, the following still just reflects my personal understanding … i.e. I could be stating something incorrectly, apologies in advance.)

The D.A. is a board driven organization with a self-perpetuating board as opposed to a member driven organization where members directly elect the organization’s leaders. As stated in our by-laws, the Board of Directors “exercise or direct the exercise of all corporate powers,” and with respect to our community elections, the Board must ratify the winners before they become part of the Board.

I wasn’t party to the creation of the D.A. to speak to why this specific structure was chosen, but I’ve read various articles on the advantages and disadvantages of each. I believe our structure gives us room to think more strategically / long term, as our nominations process allows us to ensure continuity of purpose year over year, but it also centralizes decision making in a way that may make some stakeholders unhappy. (This particular debate is a case in point.)

The D.A. doesn’t have members who vote for directors; we have a membership of people from all over the world who have an interest in the success of the Association’s mission, somewhat similar to other nonprofits like NPR. (As one example, you can refer to the membership page of the nonprofit supporting public radio in South Carolina.) I personally think we’ll need to rename the “Drupal Association Membership” to clarify this distinction, finding a term that is not semantically overloaded, in much the same way that we have to be careful about words like “Partner” or “Affiliate”.

In short, a person’s “status in the organization” is unchanged when they sign up for a D.A. Membership, but they do receive a variety of benefits for joining.

5. [With respect to the text of the by-laws describing the nature of At-Large Directors and their election process,] will this be changed?

I’m not sure if Sally means the name, “At-Large Directors”, or the text related to the election process. I’ll answer each one in turn just in case, as other folks have echoed these questions in various Twitter threads.

First, will we rename At-Large Directors?

The answer to that is no, they have and will continue to “reflect and represent the Drupal community at large,” and as such will still be referred to as “At-Large Directors.” Speaking from personal experience, when I served as an At-Large Director, my input was regularly, directly solicited on a variety of community impacting topics. I expect this to continue to be the case.

I see two basic objections to this position:

On the one hand, some people believe every member of the Drupal Association Board ought to be directly elected by members of the nonprofit, and as such “At-Large Director” was a misnomer even before we made this change. I understand this critique, but I personally consider our structure to be a foregone conclusion and theorizing about “how it could have been” to be interesting but impractical. (Speaking of “how it could have been,” imagine if the suggestion to use Certified to Rock for qualification had gained traction…)

On the other hand, some people believe that restricting eligible voters in these elections to people who maintain D.A. Memberships means the Directors cannot be described as representatives of “the Drupal community at large.” I think there’s merit to this point but that there’s room for disagreement, especially in light of historical precedent.

Our by-laws are ambiguous about what constitutes the “community” with respect to elections, and even our earliest discussions about elections demonstrate the debate was about what the criteria ought to be beyond simple self-identification as a member of the Drupal community. Notes from that era specifically ask the question, “Who is the Drupal community we're trying to capture in our voting eligibility criteria?”

In other words, from the very beginning, our debate hasn’t been about how to maximally define “community” but about how to define “community” in a way that is clear, concrete, and ensures that everyone who does vote is inarguably part of the community. After those initial discussions, D.A. Memberships and drupal.org user accounts were the two final criteria being considered for the election, and both were described as “not remotely represent[ing] the ENTIRE community.” No one objected then that that meant the directors could not be called “At-Large Directors” as a result. That same post also reflected an understanding “that this definition could shift over time,” including in a hypothetical future where we provided a “sliding scale cost for membership, or free memberships to certain subsets of the community.”

I revisit this history for a couple reasons. It demonstrates that the decision of the Board in May was very much in line with the earliest thinking of the Drupal community on this topic, and it comes at a point after we’ve long provided a sliding scale for the Individual Membership price and in conjunction with a policy that allows anyone to request a free Membership.

Even more poignant, from a process standpoint, it’s clear that from the very beginning the D.A. Board was leading the process. The election committee tasked with defining election policies was constituted by the Board, populated by the Board, reported to the Board, and produced recommendations that required Board approval prior to the first election. If Board leadership wasn’t illegitimate then, it isn’t today. That said, even if our decision was both within our realm of responsibility and in keeping with the spirit and positions of previous discussions, I still very much agree with the Board statement that we should have discussed and defined a communications strategy at the time we made it.

Going back to the second part of question 5, will we revise the by-laws with respect to the election process?

On this point, my current answer is I’m not sure but probably. I don’t believe the changed criteria conflicts with the by-laws any more than the prior criteria did - in either case, we’re restricting who, among all the people in the world who might consider themselves part of the Drupal community, is actually eligible to vote.

I do think we should consider amending the by-laws to point to a definitive policy document that addresses both how we determine voter eligibility and what it means for the Board to ratify an elected candidate.

6. Do the [new rules] create a different kind of barrier and why?

Yes, the new rules create a different kind of barrier, no bones about it. I know others disagree, but I don’t personally find the new criteria particularly more onerous than the old criteria.

Additionally, the new criteria create more room for people to participate under certain conditions, because eligibility is no longer determined based on when you last logged in to drupal.org. I know that’s a “simple” requirement, but it’s also fairly arbitrary. Even if you’d participated in Drupal events or worked at a Drupal agency, if you hadn’t created an account until after nominations opened or logged in to an existing account in the year prior to that date, you were ineligible to vote and without recourse to become eligible. Under the new criteria, you simply must log in or create an account and then become a D.A. Member at any point before the election in order to participate. These may be freely acquired by those who cannot afford the variable price fee or whose organizations do not already provide them an Individual Membership.

That answers the “what has changed” and as to the “why”, as I stated above, I believe the new criteria better align voter eligibility with the purpose of the vote. You are electing a Director of the D.A., which is a distinct entity within the Drupal community, and as such it’s more relevant whether or not you have a D.A. Membership than whether or not you have logged in to drupal.org in the year prior to nominations opening for a new election.

7. What effect will this [barrier] have on under represented groups?

I think its impact will be negligible but likely impossible to quantify. As I pointed out above, even in 2012, election discussions foresaw a shift in eligibility criteria, especially after the means of acquiring a D.A. Membership expanded and / or became more accessible. I understand some consider having to ask for a free Membership to be an impediment unto itself, but I’m not convinced this will be a practical barrier in the context of our community, which includes many such scholarships, grants, sponsorships, etc. and a no-questions, no-shame based approach to the awarding of these.

Furthermore, what Pedro Cambra writes in his self-nomination is not entirely correct, that “You can still vote even if you’re not a member of the Drupal Association.” I understand the intent of this heading, but the D.A. is literally activating a D.A. Membership upon request, with all the benefits that come with it, not just doling out voting rights. It is not a lesser Membership; there is no asterisk beside the badge on grantees’ user profiles. They are members, and upon becoming members, they are eligible to vote.

(Yes, as Sally points out, one person was directed to the normal registration form after requesting a D.A. Membership; this was an unfortunate mistake that was rectified the next day. I asked about it as soon as it was brought to my attention - a supporting staff member had not immediately understood the nature of the request. It was corrected, the process was amended to prevent further mistakes, and ultimately no one who has requested a membership has been denied one.)

I remain confident that anyone who wants to participate in this election will be able to do so, and I appreciate the efforts of the D.A. staff to communicate the changes in a variety of channels and generally improve the process for helping the community get to know their nominees. Might someone still be surprised come election day? There’s always a chance, but I don’t consider it any greater a chance with the new criteria than with the old.

8. Did the Association consider adding a free option to its regular membership sign up form?

I do not know the answer to this question or the follow-ups. I can only say I wasn’t party to any such conversation, nor have I heard of any taking place.

Personally speaking, I would expect such decisions to be left to the Executive Director and the D.A. staff. The Board passes resolutions and works with the Executive Director at a higher level to prepare budgets, organize priorities, plan the organization’s strategy, etc. but leaves the implementation details up to her and the staff. This goes for any number of areas of the Association's operations, not just the specifics of managing these elections, and the staff are always careful, competent, and eager to do right by the community in their work.

In closing...

I've been a part of the community since 2006 and a part of the D.A. Board since 2017. I first met other members of the Drupal community in person at DrupalCon Barcelona 2007, and I met my partners and many of my team members at Commerce Guys and Centarro through subsequent DrupalCons. I grew my career through contributions on drupal.org. The Drupal Association undergirds these things today, and as such, I strongly believe in the D.A. and its mission, want it to succeed, and want as many people as possible to join me in supporting it.

We do have a strong roster of candidates in the current election, and voting for the next At-Large Director begins on Tuesday, September 15th. I encourage you to learn more about the candidates and secure your D.A. Membership by September 14th in order to join me in this upcoming election.


Subscribe to Radarearth.com aggregator