Drupal News

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

Main Drupal Feed - Wed, 09/16/2020 - 18: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

Main Drupal Feed - Wed, 09/16/2020 - 17: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.

Nonprofit Drupal posts: September Drupal for Nonprofits Chat

Main Drupal Feed - Wed, 09/16/2020 - 17: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

Main Drupal Feed - Wed, 09/16/2020 - 16: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.

Solution: 

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 - Information disclosure - SA-CORE-2020-011

Main Drupal Feed - Wed, 09/16/2020 - 16: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.

Solution: 

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

Main Drupal Feed - Wed, 09/16/2020 - 16: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.

Solution: 

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 - Access bypass - SA-CORE-2020-008

Main Drupal Feed - Wed, 09/16/2020 - 16: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.

Solution: 

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

Main Drupal Feed - Wed, 09/16/2020 - 16: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.

Solution: 

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 - Cross-site scripting - SA-CORE-2020-010

Main Drupal Feed - Wed, 09/16/2020 - 16: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.

Solution: 

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

Main Drupal Feed - Wed, 09/16/2020 - 16: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.

Solution: 

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

Main Drupal Feed - Wed, 09/16/2020 - 15: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.

Solution: 

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: 

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

Main Drupal Feed - Tue, 09/15/2020 - 11: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

Main Drupal Feed - Tue, 09/15/2020 - 10: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.

Implementation:

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.html.twig

   
     
        {{ 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.

style.css

: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.
style.css
.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)

script.js

(($, 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.

global-styling:
  version: 1.x
  css:
    theme:
      css/style.css: {}
  js:
    js/script.js: {}
  dependencies:
    - 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

link

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.

link

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

link

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

Main Drupal Feed - Mon, 09/14/2020 - 16: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

Main Drupal Feed - Mon, 09/14/2020 - 14: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

Main Drupal Feed - Mon, 09/14/2020 - 09:49
Background

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.


cd PATH_TO_DRUSH
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

Wicked!

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...

Troubleshooting
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

Dolphin Theme

Drupal Themes - Mon, 09/14/2020 - 05:15

Dolphin is a fully Responsive, mobile-first multipurpose Drupal 8 theme built on the Bootstrap 3.x Framework.

Main Features
  • Mobile First - Fully responsive
  • Pre-defined sections like banner, promotional cards, about section, number sccollers, footer.
  • Maximum configurations provided for each sections
  • Easy Theme settings for customization
  • Option to enable/disable the pre-defined section
  • Supports one / two / three column page layout
  • Dynamic columns - Adjusts to fit the page width
  • Responsive Drop Down menu
  • Use of Google Font - Exo 2.
  • Customizable social platforms (Facebook, Google+, Twitter, Linkedin, YouTube) icons and links
  • Custom 403(access denied), 404(page not found) pages

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

Main Drupal Feed - Sun, 09/13/2020 - 04: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.

The Russian Lullaby: Books/ Drupal 9 Module Development

Main Drupal Feed - Sat, 09/12/2020 - 00:00

For a long time I was thinking about write or not a review of the Drupal 8 Module Development (the former edition of the current). For me there were two very important keys: on the one hand, it was a very ambitious book in terms of scope and content (so it was an important challenge to make a synthesis on its simple review). On the other hand, Drupal 9 was already on its way and it was possible that it would be deprecated quickly. Luckily, Drupal 9 has already arrived and the transition from 8 to 9 has not only not been at all traumatic (there are still many people trapped in the crack between …

Pages