Community Working Group posts: Evaluating Drupal's Code of Conduct

Planet Drupal - Mon, 2022/05/23 - 10:25pm

Over the past couple of years, the Drupal Community Working Group has talked about reviewing and possibly updating the existing Drupal Code of Conduct. The process has had several starts, but mainly due to contributor bandwidth hasn't gained much traction to this point.

As reported in 2019, 

The current Drupal Code of Conduct was adopted in 2010 and last revised in 2014. Over the last two years, the CWG has received consistent feedback from the community that the Drupal Code of Conduct should be updated so that it is clearer and more actionable.

In the two years since, the Community Working Group has had several meetings focused on the Code of Conduct. They have identified some tasks, goals, and challenges including:

  • Reviewing Codes of Conduct from other communities.
  • Reviewing the findings from the community discussions led by Whitney Hess in 2017. 
  • How best to gather and utilize community feedback.

Recently, a group of Community Health Team members met to kickstart the process once again in hopes of finding the proper balance of tasks and timeline to determine what, if any, updates to the Code of Conduct are necessary. Community Health Team members at the first meeting include: 

The group, led by George DeMet, is still in the initial planning stages, trying to figure out a rough outline of tasks to achieve the goal. Our first activity was to work with a list of tasks and challenges to refine and organize them into logical groups, such as "project goals", "what are we missing", and "action items".

Snippet of the CoC update jamboard

We are still in the very early part of this effort, but are determined to keep momentum by having bi-weekly meetings, along with a blog post (like this) after each meeting to keep the community informed on the progress that’s being made and share opportunities for community participation.

Questions? Concerns? Let us know in the comments below!


Talking Drupal: Talking Drupal #348 - A Website’s Carbon Footprint

Planet Drupal - Mon, 2022/05/23 - 8:00pm

Today we are talking about A Website’s Carbon Footprint with Gerry McGovern.

  • Earth day
  • What is a carbon footprint
  • How do websites contribute
  • How can you calculate your site’s impact
  • Cloud vs dedicated hosting
  • How do you determine a vendor’s impact
  • Small sites VS FAANG
  • How to improve your site
Resources Guests

Gerry McGovern - @gerrymcgovern


Nic Laflin - @nicxvan John Picozzi - @johnpicozzi Chris Wells - - @chrisfromredfin


Config Pages At some point I was tired of creating custom pages using menu and form API, writing tons of code just to have a page with an ugly form where a client can enter some settings, and as soon as a client wants to add some interactions to the page (drag&drop, ajax etc) things starts to get hairy. The same story was with the creation of dedicated CT just to theme a single page (like homepage) and explaining why you can only have 1 node of this type, or force it programmatically.


DrupalEasy: Replacing Docker with Colima for use with DDEV - first impressions

Planet Drupal - Mon, 2022/05/23 - 6:15pm

Back in March, 2022, the DDEV team announced support for Colima, an open-source Docker Desktop replacement for Mac OS X. Based on the fact that Colima is open-source, Docker Desktop's new license terms, and the apparent performance gains of using Colima it seems like a no-brainer to give it a spin.

First off, it's almost a drop-in replacement for Docker Desktop. I say almost for one reason, as any existing DDEV projects will need to have their databases reimported. In other words, if you have an existing project up-and-running in DDEV, then add Colima, then restart the project, your database won't be found. The easy fix is to first export your database, then start Colima, then import it. Easy.

The reason for this (as I understand it) is because Colima uses the open-source Lima project for managing its containers and volumes (the latter being where DDEV project databases are stored). 

For those of us that are casual Docker users (outside of DDEV), one confusing bit is that we still need the open-source docker client installed - which is installed by default with Docker Desktop for Mac. The docker client is used on the command line to connect to the installed Docker provider (Colima or Docker Desktop for Mac, in this context). If you want to go 100% pure Colima and you uninstall Docker Desktop for Mac, you'll need to install and configure the Docker client independently. Full installation instructions can be found on the DDEV docs site

If you choose to keep using both Colima and Docker Desktop then when issuing docker commands from the command line, you'll need to first specify which containers we want to work with - Docker or Colima. More on this in the next section. 

How I use Colima

I currently have some local projects using Docker and some using Colima. Once I understood the basics, it's not too difficult to switch between. 

Installing Colima alongside Docker Desktop for Mac and starting a fresh Drupal 9 site
  • To get started, I first installed Colima using Homebrew "brew install colima"
  • "ddev powerof"f (just to be safe)
  • Next, I started Colima with "colima start --cpu 4 --memory 4" The --cpu and --memory bits only have to be done once. After the first time, only colima start is necessary. 
  • Next, I spun up a new Drupal 9 site via "ddev config", "ddev start", etc... (It is recommended to enabled DDEV's mutagen functionality to maximize performance). 
Switching between a Colima DDEV project and a Docker Desktop for Mac DDEV project
  • "ddev poweroff"
  • "colima sto"p
  • "docker context use defaul"t - this is the command I alluded to above that tells the Docker client which containers we want to work with. "default" is the traditional Docker Desktop for Mac containers. When colima start is run, it automatically switches docker to the "colima" context.
  • "ddev start" (on an existing project I had previously set up while running Docker Desktop for Mac).

Technically, starting and stopping Colima isn't necessary, but the "ddev poweroff" command when switching between the two contexts is. 

Also - recent versions of Colima revert the Docker context back to "default" when Colima is stopped, so the "docker context use default" command is no longer necessary. Regardless, I use "docker context show" to verify that either the "default" (Docker Desktop for Mac) or "colima" context is in use. Basically, the "context" refers to which Docker provider the Docker client will route commands to. 


Overall, I'm liking what I see so far. I haven't run into any issues, and Colima-based sites seem a bit snappier (especially when DDEV's Mutagen functionality is enabled). I definitely foresee myself migrating project sites to Colima over the next few weeks.

Thanks to Randy Fay for reviewing this blog post. Randy is the lead maintainer of the DDEV project. If you use DDEV, then you should support the DDEV project!


Drupal Association blog: Imre Gmelig Meijling joining the Board of Directors

Planet Drupal - Mon, 2022/05/23 - 3:53pm

The Drupal Association is proud to announce our newest Board of Directors member, Imre Gmelig Meijling. Imre will serve out the remainder of the term for Pedro Cambra, who resigned from the board in March 2022 after serving 1.5 years of a 2-year term. We're happy Imre is willing to step up and contribute to the Board this year.

Involvement with Drupal

Imre has been involved with the Drupal community since 2005 and was the Chair of the Board of the Dutch Drupal Association. He is a co-organizer of the Dutch Drupal camp Drupaljam and started the Splash Awards in 2014. He has also been an active contributor to DrupalCon Europe for the past few years as a member of the DrupalCon Europe Advisory Committee. Imre has worked for various agencies in Europe, creating Drupal adoption and raising awareness for Drupal within regional and international brands and communities. Besides being a Drupal volunteer, Imre is co-owner of Drupal agency React Online in The Netherlands. 

During the most recent at-large community elections, Imre came in second place, which makes him a natural fill-in for the at-large community elected position. Imre is excited to share his experience and join the Board, where he will help amplify Drupal's position and message across the global community and organizations.  

You can read more about Imre on his candidate page.  

The Drupal Association is a non-profit organization focused on accelerating Drupal, fostering the growth of the Drupal community, and supporting the project’s vision to create a safe, secure, and open web for everyone. Are you using Drupal or are you a Drupal community? Feel free to connect.


Danny Englander: Implementing a React App and Connecting it to a Custom Drupal Block to Pull in Remote API Data

Planet Drupal - Mon, 2022/05/23 - 7:00am

These days, Drupal core out of the box is sufficient for many website use cases and with the advent of Drupal 8 and 9, one can build a highly functional site with minimal contrib module add-ons. In the past few years, decoupled sites have also become quite popular which usually means a separate front-end framework such as Gatsby / React that queries data from a Drupal data endpoint, typically using something like GraphQL as middleware.

But there are also points in between where you might do something like "progressive decoupling", such as a custom block that is built with React and integrated right inside Drupal. At my current job, I was recently tasked with needing to pull in data from a remote API and have it render as a custom Drupal block. I decided upon using React for this task utilizing the Axios library, a promise based HTTP client for the browser and node.js, which is superb at pulling data from remote APIs.

Basic recipe

Here is an outline of the basic "ingredients" I used for this project.

  1. A custom Drupal module, react_jobs_teaser that will contain our React app, a custom block, and a Twig template for the block
  2. The React app pulls in data from the remote API via Axios
  3. Create a custom Drupal block in react_jobs_teaser/src/Plugin/Block/ReactJobsTeaserBlock.php
  4. Create a Twig template for the custom block with an ID that the React app will target viaReactDOM.render()
  5. A Drupal field that is rendered in the theme that the React app will target so as to make the API data contextual for each node
  6. Render the block in a theme template using Twig Tweak
  7. Expose the custom Drupal field data to React in the same theme Twig template
Getting started: the React app

The basic idea here is to build the React app and test it inside its own environment and then wire it up to Drupal for seamless integration. For my project, I used create-react-app which is a quick way to get up and running with a simple one page React site. We pull data from the USA ...


Liip: JWT token based authentication for rokka and more

Planet Drupal - Mon, 2022/05/23 - 12:00am

We do constantly update and improve our image delivery and storage service and we'd like to talk about some new feature since the last update here. You can always check the changelog for public additions or follow us on Twitter for the latest and greatest on time updates.

Option for JWT based API Tokens for authentication instead of API Keys

To access the rokka API until now, you needed the API Key which you get on sign up and of which you can create new ones in the Dashboard or via the API. This is fine for most of its use cases, like storing it somewhere on the server side. But maybe not so much when many people, you may not even know, need and have access to such a key. Be it even only with limited rights like for uploading some images or read only access. The problem with rokka’s API keys is that they are valid forever (until you revoke them) and can be used from everywhere.

We could have added time-limitable API Keys, but we chose another path: JWT tokens, which you can get via the API (and an API Key…). They do need an expiry date and can also be IP limited. You can also make them renewable or disallow that. And more limitations could be added in the future.

You most certainly don’t need such tokens, if your code runs on the server side anyway and you don’t need to give out that key to many people or store it somewhere not trustworthy.

But for browser based access to the rokka API directly, there are at least three good use cases for such tokens.

Of course you could run all your communication needed with the rokka API through your backend and wouldn’t need to give out any credentials. But either you do not even have a backend (the rokka Dashboard and the rokka Gallery are just static sites in the end) or you want to avoid unneeded latency and stressed resources on your backend and directly talk to the rokka API from the browser. For example for uploading large images and videos.

The technical details of all this are documented in the authentication chapter of the rokka documentation and our PHP library (in 1.17.0) and the JavaScript library (only in 3.7.0-rc.1 yet, stable release will follow soon) do have already support for all this. And the Dashboard and the Gallery do use these new API tokens already.

But now to three possible use cases:

1. No need to store the API key in the browser, just the limited token

This is what we do in the mentioned dashboard and gallery. People login with their organisation and an API Key, we then fetch an API Token directly from the rokka API and just store that in localStorage, but not the API Key. The token time limited to 3 days, we restrict it by IP (but do remember the last few used ones, so you don’t have to login all the time when switching IPs) and try to renew it after a day. The rokka.js library takes care of most of that, except the multiple IP limiting. The rokka.js file in the dashboard is an example of how to do all that.

Even though the end user still needs to know a valid API Key, at least we don’t store it in the browser permanently. So that if someone could steal the credentials somehow, it will only be valid for 3 days (but can be renewed within those 3 days in the above setup) and more importantly only from the IPs the user itself logged in. We add some additional layers of security this way.

2. Have more control over who has access to it

This is more or less an extension of the above. Let’s say you want to give more granular control to such a site, but not wanting to have to create an API Key for each new user (you could revoke, when the access of a user should be revoked, but that gets cumbersome). You also would lose control of what the users do with such an API Key, like reusing it somewhere else. But you maybe do have a backend already with some single sign on solution and user based access control.

In this scenario, your rokka.js based frontend would then ask your backend for an API token, log in people if they’re not already, the backend generates that token through the rokka API and the (only stored in the backend) API Key, makes it time limited for like a day and marks it as non-renewable. And even can make it IP protected, if that’s what you want.

The end user then only gets this token, when they log in. And should their access get revoked in your backend, they don’t get a new token the next day. In an emergency case you could also rotate the used API Key on rokka’s side and all your valid users just would need to get a new token from the backend, but the non valid users get immediately rejected with their otherwise maybe still valid token.

3. Give only very time limited access

Uploading images and videos can be resource intensive and need some bandwidth and intermediate storage. Therefore instead of uploading such assets through your backend to rokka, you could give out very time limited and non-renewable API tokens (eg. for 15 minutes) and let your users directly upload images from their browser. After that, they need a new token from your backend (where you also could build in some rate limiting or such). Just don’t forget to report to your backend after the upload, what kind of image (especially the rokka hash) was uploaded and update your database with it. And maybe do some cleaning up of stale images from time to time.

Membership management in the rokka Dashboard

Until recently, you could only generate/delete/edit memberships for your organization through the API. No more hassles now, you can directly do all that within our dashboard.

This makes it much easier to generate new users and their corresponding API Keys with for example less rights than the default admin user. Or to add users from another organization.

It will also list when that user was last used to access the organization and you can even add a comment to each membership. This can help a lot in cleaning up your access rights at a later time.

You can also generate new API keys and delete old ones for the currently logged in user directly in the dashboard.

Those features are all also available directly with our API and are documented.

rokka service status page

Since about two months, we do have a service status page reporting about the current status of our services. You can even subscribe for email alerts, if something is down. Go to to see it in action.

And one more thing: Custom Sourceimage hashes

This feature is not released yet, but may soon come, so here’s a little sneak peak.

Currently, when you upload an image or video to rokka, you’ll get back a hash generated by us. And the same hash if you upload the exact same image again. With this hash you then access the image in the future, you must therefore store it somewhere to get that image again, as there is now way for you to predict this hash. All our plugins and custom implementations do that somewhere in a database or even just the file system.

But for some setups, this may be too complicated or too cumbersome. It would be much easier, if they could calculate that hash from some unique identifier and use that, with no need to store and use our calculated hash. And that’s what we will soon release. You can then provide your own hash while uploading an image and work with that.

There are some caveats with this approach and one can easily make mistakes. But if you take care of the prerequisites, it could be a new way to store those hashes and saving you some trouble somewhere else.

One of the caveats is that the hash really has to be unique for each image. You can’t reuse the same hash for another image, our API will complain then. For example, if you have some images per product in your e-commerce store, you can’t compute a hash from just for example product_id and image_position. That will work the first time, but when some one exchanges the image at a position and this image would get the same hash as the one before, rokka will reject it. Mostly due to caching reasons in the CDN and the browsers, but also due to the very basic principles of rokka: One image, one unique hash.

The easiest way to avoid this is for example to compute the sha1 hash from the binary file (that’s basically what we do on the server side, with some additions for dynamic metadata). That’s guaranteed to always produce a different hash, even if the image is just slightly different.

Or if you generate a database entry anyway for each uploaded image, you could take the unique ID of this to generate the hash. No need for additional fields for the rokka hash and keeping track of them.

There’s some more caveats regarding dynamic metadata, but that shall be enough for this little teaser for now. We will certainly report, when it’s ready. And if you’re interested already or see some use case for you, we’re happy to hear from you. We do have a public Slack organisation, where you can reach out to us, or check our contact page for all the other ways.

Photo by Pop & Zebra on Unsplash


#! code: Drupal 9: The Correct Way To Redirect A Page

Planet Drupal - Sun, 2022/05/22 - 8:14pm

I was recently working with a Drupal 9 site and found some strange behaviour when saving certain types of content. The page would appear to save, but much of the content appeared to be missing. It had even failed to generate the paths for the page based on the path auto rules.

Digging deeper I found the root cause of the problem was an improperly created redirect in an insert hook within custom code written on the site. This code looked for the creation of a particular content type and then forced the redirect to happen.

This was more or less the code in question. 

use Drupal\Core\Entity\EntityInterface; use Symfony\Component\HttpFoundation\RedirectResponse; function mymodule_entity_insert(EntityInterface $entity) { if ($entity->getType() == 'article') { (new RedirectResponse('/node/' . ($entity->id())))->send(); exit(); } }

This isn't great code in itself, but the worst part is the call to the exit() function. This stops any code execution straight away, which is what caused out content type to be half created. By stopping code execution like this we are preventing any other hooks or services from acting upon the content type being inserted.

The secondary effect of this is that it also bypasses Drupal's shutdown functions. When Drupal starts a page request is registers a few methods that are to be called as the page response is closed down. This includes session management methods, but can also include a cron handler (if cron has been configured like that).

There is probably a reason why the exit() function was added. by default Drupal will perform a redirect after creating a page and I think the original developer was probably trying to prevent the upstream redirect from taking place. Unfortunately, they ended up creating more problems than just a redirect issue.

Read more.


Drupal Association blog: In Mourning and Recognition of Buffalo, Dallas, and Laguna Woods

Planet Drupal - Fri, 2022/05/20 - 4:04pm

* Content Warning: Racial violence, death, racist language * 

It’s Asian Pacific Islander American Heritage Month. This is usually one of my favorite months of the year, when I celebrate the rich culture and heritage of my fellow Asian Americans. We were excited to celebrate APAHM here at the Drupal Association, with the elevation of news and resources to support AAPIs in technology. 

But we can’t celebrate right now. Right now, it’s important to talk about the hate crimes over the last week and a half. It’s just 2 months after the 1 year anniversary of the attack on Asian women working in spas in Atlanta. This week feels frighteningly similar, with Korean hair salon workers being the target of anti-Asian violence in Dallas. Race- and gender-based violence is well-documented in the United States and has only escalated in the wake of COVID 19. 

Dallas is not the only instance of racial violence this month. Within days of each other, an attack on Taiwanese parishioners in Laguna Woods and Black community members at a Buffalo grocery store would follow. Buffalo being the deadliest of the 3, and the only one specifically linked to radical white supremacy. The perpetrators of these crimes are different races but are all driven by racial bigotry. It is also not lost on any of us that the majority of victims of all 3 of these violent attacks are our elders, who are undersupported and under-protected

This week, Asian and Black Americans are grieving, are frightened, and are exhausted. Racial violence in America is an ever-present threat to our communities and our people. We don’t move through the world separated from this threat. I would ask you to extend patience and grace to your Black and Asian staff this month. But beyond that, I would ask you to extend your support to Black and Asian folks, inside and outside of your workplace. These hate crimes don’t exist in a vacuum, and vicarious trauma is very real. It is debilitating to see people that look like you and the people you love continuously experience racial violence. 

The shooter in Buffalo cited his admiration for “East Asians” in their ethnic homogeneity, which may further the division between Black and Asian communities. Asian Americans are an invisible “minority” in the United States and are often pitted against Black Americans. Racial tension between the two racial groups is documented and ultimately displaced. The work to end Anti-Asian and Anti-Black racism is intrinsically intertwined, and we have a beautifully rich history of solidarity that continues today. 

I compiled some action steps you and your organization can take to show up for Black and Asian Americans this week and every week. I feel fortunate to be given the opportunity to engage the Drupal community on these events and to not have my voice silenced. I hope you will take some or all of these actions, and share them with your communities: 

  • Check on your Black, Asian-American, and/or Pacific Islander employees to understand how they are doing, especially if they are working from home, and see if they need any support. Then, accommodate their needs even if it’s outside your usual policies.

  • Continuously unpack your own bias against Black and Asian Americans with active learning and action. 

  • Get involved in the anti-racism movements in your local community.

  • Understand technology’s role in racial violence. 

  • Join the Ascend Action Agenda 

  • Donate to Resource Council of WNY to provide food and resources for the Buffalo community left without their only grocery store 

  • Donate to the Dallas/Fort Worth Chapter of the Korean American Coalition 

  • Support ​The Orange County Asian and Pacific Islander Community Alliance (OCAPICA)

  • Donate to the victims and families affected in Buffalo  

  • Donate to the families affected in Laguna Woods 

The Drupal Association will still elevate BIPOC voices, and continuously condemn acts of racist, hatred-driven violence. I will still celebrate APAHM with my community this month, and I hope you will too. I will still show up for Black Americans, Asian Americans, and all marginalized people in my work and in my life, and I hope you will too. 

I will also take it slow and allow myself to process and grieve as needed. To my Black and Asian siblings, I hope you will too. 

Articles referenced in this blog: 


Chapter Three: How to progressively decouple your Drupal site with Next.js and JSON:API

Planet Drupal - Thu, 2022/05/19 - 11:43pm
At Chapter Three, we believe that most Drupal websites could gain a performance boost by going headless. While this is how we’re planning to build future Drupal sites, we understand going all in on headless might not be feasible for existing sites. This is why we built next-drupal for progressive adoption: decouple your Drupal site page by page, content type by content type, one at a time. In this post, we’ll take a look at how we can decouple one content type from an existing Drupal site. We are going to take our own site as an example.

DrupalCon News: DrupalCamp Spain on June 3 to 5 in Zaragoza

Planet Drupal - Thu, 2022/05/19 - 10:35pm

One week of Drupal presentations, trainings and networking. 3 to 5 June.


Promet Source: 10 Reasons to Love Drupal 9

Planet Drupal - Thu, 2022/05/19 - 6:54pm
Next month marks two years since the release of Drupal 9, and among the hundreds of thousands of site owners who have migrated, there’s a general consensus that D9 is a bit of a masterpiece with unrivaled scalability, security, and flexibility. 

Evolving Web: Join the Evolving Web Team at DrupalCamp New Jersey 2022

Planet Drupal - Thu, 2022/05/19 - 6:24pm

DrupalCamp New Jersey has been held annually since 2012, and this year, as the event’s diamond sponsor, Evolving Web will be there hosting a number of sessions on various subjects, ranging from Drupal migration to user experience and project estimations.

One Day to Learn About All Things Drupal

In 2022, DrupalCamp NJ is focusing on topics of interest to Drupal users with a range of experiences and responsibilities. Topics include performance, accessibility, design, decoupled architectures, and much more. The camp will be one day full of activities, with 20 sessions and many opportunities to connect, learn, and contribute.

The camp will take place at Princeton University, with which we proudly partnered on several Drupal projects: Princeton International, Princeton University School of Public and International Affairs, and Princeton University Press.

Apart from hosting sessions, the Evolving Web team will be there to connect with other Drupalists, talk about Drupal, discuss projects, and also organize a prize draw for free training: just drop by our booth, leave your contact info, and wait to see if you’re the lucky winner!

👩‍🏫 Boost Your Drupal Knowledge with Our Upcoming Training Courses

Our Team’s Sessions

If you’re planning to attend, you can find DrupalCamp NJ’s full list of sessions. Also, if there’s any topic you’re missing, you can always submit your idea as a Birds of a Feather session, informal gatherings to discuss a certain topic without a pre-planned agenda.

Now let’s take a look at the sessions our team is presenting at DrupalCamp NJ this year:

  • Drupal Project Estimation, for Fun and Profit, by Alex Dergachev & Rukmini Halliwell

Being able to accurately estimate the time required to develop a product or feature is crucial for every Drupal developer. Whether you’re on the buying or selling side of a project, a mature estimation process can make the difference between project success and failure.

In this session, Alex and Rukmini will discuss the mysterious art of software estimation and show our basic Drupal estimation spreadsheet model, based on factors such as the number of content types, number of expected pages, content migration, and other parameters.

  • User Experience: How to Make Design Decisions that are Data-Driven, User-Centric, and Stakeholder-Influenced, by Suzanne Dergacheva

When we design user experiences, decide on information architecture, or prioritize content on a homepage, we must take all useful inputs into account, whether they’re data-driven or coming from a given stakeholder. This is a delicate balance, though, and it’s useful to know which metrics to focus on and what methods help us make different types of decisions.

In this session, Suzanne will talk about user research techniques, the pros and cons of data-driven design and content decisions, how to get the most value out of stakeholder input, and the dangers of “design by committee”.

  • Drupal Loves Composer, and You Can Love It Too, by Kevin Porras

With the Composer Support in Core Initiative, the adoption of Composer by the Drupal community has become wider. However, as good as it is, Composer can be intimidating and even problematic if you lack some basic knowledge.

Kevin will tell you about the basics (and not-so-basics) of Composer, including creating a Composer project, adding dependencies to it, dealing with merge conflicts, dependencies resolution problems, and popular Composer plugins.

  • Any Content Site Can Be Migrated to Drupal: I'll Show You How, by Jorge Diaz

In this session, Jorge will present how five completely different websites were migrated to Drupal. He will map out the process in detail, from the original legacy website to the final end product, giving a full perspective on the migration process.

  • Regression Testing with SiteDiff and Playwright, by Robert Ngo & Alex Dergachev

As part of building and maintaining Drupal projects, code changes and updates are progressively introduced and integrated into the code base. Sometimes, even a small change to a line of code can introduce unforeseen consequences.

To avoid that, regression testing ensures existing functionality continues to work after you make updates. To make this efficient and ensure that tests are run consistently, automating the testing process is essential. In this session, Robert and Alex discuss some use cases for SiteDiff and Playwright, two complementary regression testing tools.

We’re very excited about this year’s DrupalCamp NJ. This will be another great opportunity to learn, build connections, have fun, and make the Drupal community stronger. See you there!

About DrupalCamp NJ 2022

When: Friday, May 27, 2022

Where: Princeton University, Princeton, NJ, 08544

Register for DrupalCamp NJ here

+ more awesome articles by Evolving Web

Palantir: My Events Life Post-COVID

Planet Drupal - Thu, 2022/05/19 - 2:00pm

How an events professional turned communications manager got back her groove

How It Started

I missed the magic of events.

Having spent the majority of my life in the “before times” organizing, planning, and executing strategic events for organizations ranging in nature from small nonprofits to medium-sized private sector to large-scale public sector, events have always given me an energy that is hard to describe. There is a profound and extraordinary element to witnessing, in real time, the result of my weeks of hard work. It makes me want to wave my arms wildly and announce to anyone in earshot, “Hey, look! You see that awesome event? I did that!”

I ended 2019 knowing that 2020 would be the best events year yet. As an independent strategic communications and events consultant in Washington, D.C., I had clients lined up - there were weddings to plan, conferences to schedule, and trade shows to organize.

How It Transformed

Well, that didn’t go as planned.

Events transitioned to Zoom, or Google Meet, or to less than five people if it was in person. Happy occasions that should’ve been celebrated were dulled and diluted, and professional events electrified by the annual expectation of seeing old friends and meeting new faces came to a starkly bleak and screeching halt.

I didn’t know what to do.

I found myself limited, concerned, uninspired, stuck. I had lost my events fix, and it was becoming exceedingly apparent and incredibly difficult to navigate.

Then I moved from the East Coast to the Midwest in search of a fresh start - one that hopefully, at one point, would include a live event or two.

Within four months, I began my journey as Communications Manager with, which was the beginning of one of the best professional experiences of my life. And then, only about a year and a half later, I had the opportunity to attend DrupalCon.

For the record: I had zero experience in the open source tech industry, and had only a basic knowledge about what open source even was. Needless to say, I was also a complete stranger to Drupal and its community.

How It Went

Also for the record: DrupalCon was an absolutely amazing experience.

  • I got to see some of my colleagues again for the first time in months, and met some others for the first time, in person.
  • I got to have an amazing dinner with fellow Palantiri at Grain and Gristle. Its website offers farm fare, a locally-focused bar, and warm service - and we received all three.
  • I got to meet and connect with Drupal community members from companies big and small, both familiar and unfamiliar to me.
  • I went to informative classes with insightful speakers and insightful fellow attendees  - my highlight was The Women in Drupal Luncheon, which was an enlightening, empowering, and wholly collaborative experience.
  • I went to three after-conference events, where I got to know fellow Drupal community members on a personal level, from a rave at the Oregon Museum of Science and Industry, hosted by Acquia; to a much-needed chill night spent laughing on a gorgeous patio hosted by; and, the highlight of my afterparty experience, was meeting Caesar the No Drama Llama and dancing to an epic band covering '80s and '90s classics with The Goonies playing in the background, hosted by Pantheon.

Needless to say, I was exceptionally exhausted but exceptionally happy to be back in the in-person events world. It was something I didn't know I had craved and needed until the first hour into the conference. But after those 60 minutes? I was all in and couldn't have enjoyed it more. 

How It'll Go

From here, I have every intention to attend DrupalCon 2023 in Pittsburgh.

I also had the pleasure of connecting with folks who welcomed me into becoming involved with MidCamp - an event resuming in-person in 2023, which offers four days of Drupal fun including (but certainly not limited to) a community introduction day, livestream social, unconference, and contribution day.  

So, how does it go beyond that?

In my estimation, it goes very, very well. I feel like a full member of the Drupal community - a member who can provide input, connection, events advice, collaboration, and, most importantly, support.

It's a good feeling, and I'm glad to be back.

See you next year, Pittsburgh! 

Photo by Rachel Waddick featuring the Drupal drop

Community Drupal Events Open Source People

Drupal Association blog: GAAD Pledge 2022 - Extending Drupal's Accessibility

Planet Drupal - Thu, 2022/05/19 - 7:00am

Posted on behalf of the Drupal accessibility maintainers.

The Drupal community is again celebrating Global Accessibility Awareness Day (GAAD) but this time we are excited to also announce that the Drupal CMS has taken the GAAD pledge to formalize accessibility as a core value of our framework. Our commitment to accessibility isn’t new, but we are excited to join React Native and Ember JS, previous GAAD Pledgees, to be a public open source leader in pushing forward accessibility to the community.

Digital accessibility is an important issue because so much of our lives are currently mediated through the internet. Globally, over a billion people have some form of permanent disability. Not all people with disabilities face barriers on the web, but when looking at temporary and situational disabilities, they can affect us all. The Drupal community proudly includes people with disabilities. The million or so Drupal sites serve people with every combination of visual, mobility, auditory, physical, speech and cognitive disabilities.

Drupal has been a leader in CMS accessibility for over a decade. Drupal community events (local and global) have had presentations about WCAG and ATAG for nearly 20 years.

Drupal 7 (2011) embraced WCAG 2.0 for both the front-end and back-end of the interface. This is still uncommon for CMSes. As a blind developer, Everett Zufelt was key to bringing the community onboard with this. Everett led many of the early Drupal 7 discussions and became Core’s first Accessibility Maintainer. We were early adopters of ARIA and added limited implementations to Drupal years before ARIA 1.0 was released. We were one of the first CMSes that tried to build standardized patterns designed explicitly to address common accessibility problems.

Drupal 8 (2014) was one of the first CMSes to adopt ATAG 2.0 to support authors in creating more accessible content. We introduced a means to manage aria-live for dynamic content and control the tab order for keyboard-only users. Drupal made many advances in accessibility such as improvements to form errors and requiring image alt text. This release also benefited from the work of Vincenzo Rubano, a blind Italian student who contributed to Drupal Core. In this release we also took on broader adoption of ARIA and started deploying elements of WCAG 2.1.

There is a lot more in the works for Drupal 9 and 10. Drupal 9 saw the introduction of two new accessible themes, Claro and Olivero. Olivero is now our default theme, and named in memory of Rachel Olivero, a stand-out member of the Drupal Diversity and Inclusion community. Rachel, a blind user, also worked with the NFB (National Federation of the Blind) on building their web platform on Drupal. The NFB was generous enough to review this new Drupal theme prior to release.

Drupal was one of the CMSes represented in the We4Authors Cluster, with other CMSes used by governments in the European Union. Drupal is also looking ahead at WCAG 2.2 and WCAG 3.0, with one of our Accessibility Maintainers actively involved in the Working Groups for these guidelines.

We have done a lot, but accessibility is a journey. As long as Drupal continues evolving to keep up with ever emerging internet and accessibility technologies, there will be more to do.

Our 2022 Pledge
  1. Accessibility is a core value of the Drupal CMS, all Drupal websites, and our events (Our community embraces accessibility).
  2. In 2022 we will formally upgrade our standards to WCAG 2.1 AA (Our community process and project governance will continue to align with the latest recommended release of the WCAG guidelines).
  3. We will publish a new coding standards document to clarify our accessibility practices (Accessibility isn’t currently in our coding standards).
  4. Our documentation will be updated to ensure that it includes current best practices (Updating documentation is something that always needs to be done).
  5. We will continue tracking accessibility issues for all projects and tagging them for transparency.
How You Can Help

We also invite everyone to help make Drupal a more accessible framework. There are lots of ways to get involved! Here are a few ideas:

  • Download the latest version (ideally the Git release) and test for accessibility. This could just be using
  • Contribute accessibility bugs that you find back into the Drupal issue queue. Make sure to tag them with “accessibility” and ensure that you have included how to replicate the barrier.
  • Review the modules you are using in your site and contribute where you can to make them more robust and inclusive. Remember to tag those issues with “accessibility” as well.
  • Look through the We4Authors Cluster suggestions and see if there are opportunities to improve the support we are able to provide to authors.
  • Provide feedback to the team by joining the #accessibility channel on the Drupal Slack.

Today we reaffirm our commitment to accessibility by taking the GAAD Pledge. As we continually improve Drupal, accessibility will be a core part of what we do.


The Drop Times: How Can You Make Your Website More Accessible?

Planet Drupal - Thu, 2022/05/19 - 4:13am
Despite the amazing modules and features there is still more to do. Here is what you can do to make your website more Accessible.

Nonprofit Drupal posts: May Drupal for Nonprofits Chat

Planet Drupal - Wed, 2022/05/18 - 9:29pm

We are looking for an additional co-moderator for this group! Reach out to Jess or Johanna to learn more about what's involved.

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

We'll be getting a report on the happenings at DrupalCon from those who attended, and then having an informal chat about anything at the intersection of Drupal and nonprofits. Got something specific on your mind? Feel free to share ahead of time in our collaborative Google doc:!

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

This free call is sponsored by and open to everyone. 

  • Join the call:

    • Meeting ID: 818 1746 9653
      Passcode: 551681

    • One tap mobile:
      +16699006833,,81817469653# US (San Jose)
      +13462487799,,81817469653# US (Houston)

    • Dial by your location:
      +1 669 900 6833 US (San Jose)
      +1 346 248 7799 US (Houston)
      +1 253 215 8782 US (Tacoma)
      +1 929 205 6099 US (New York)
      +1 301 715 8592 US (Washington DC)
      +1 312 626 6799 US (Chicago)

    • Find your local number:

  • Follow along on Google Docs:
  • Follow along on Twitter: #npdrupal

View notes of previous months' calls.


Tag1 Consulting: D6LTS wind down and D7 extension with Tim Lehnen

Planet Drupal - Wed, 2022/05/18 - 1:26pm

The last two years have been eventful for most of us, and the Drupal community is no exception to that. From the shift to online DrupalCons and their return to in person this year, to new releases of Drupal and the revisiting of old ones, it’s been a momentous time. Drupal 7 was originally scheduled to reach end of life (community support) in November of 2021.

Read more lynette@tag1co… Wed, 05/18/2022 - 04:26

OpenSense Labs: Drupal is Ensuring the Web Accessibility Standards

Planet Drupal - Wed, 2022/05/18 - 11:48am
Drupal is Ensuring the Web Accessibility Standards Akshita Wed, 05/18/2022 - 15:18

Just like land, air, and water are meant for everyone, the web was designed to work for all people and expel any hindrance, irrespective of the surroundings and capabilities of people. But the effect of incapacity (of individuals) in the light of the fact that the web standards don’t include all in itself has become a barrier. Creating quite the paradox in the situation.

Before completing this blog, my ignorance led me to believe that web accessibility was limited to ‘accessibility only for people with disability’. Another thing that I was coxed to believe was that it is almost synonymous with visibility issues. But it is as much for a person with auditory disabilities as it is for a person with cognitive or neurological disabilities. However, I realized I was not the only one associating such wrong notions with disabilities and web accessibility.

Lack of awareness and taboos associated with disabilities often mislead us.

Ensuring that people with disability have equal and inclusive access to the resources on the web, governments and agencies follow certain guidelines in order to establish equal accessibility for all without any bias. 

What are Web Accessibility Standards and why do they matter?

The Web Content Accessibility Guidelines (WCAG) explains how the web content be made more accessible to people. Here the word "content" refers to any and every kind of information in a web page, such as text (include heading and captions too), images, sounds, codes, markup - anything that defines the layout and framework.  

“WCAG is developed through the World Wide Web Consortium process with a goal of providing a single shared standard for web content accessibility that meets the needs of individuals, organizations, and governments internationally.”

Take examples of physical infrastructures like ramps and digital vision signboards, which can be used by anyone, in a similar fashion web accessibility is for everyone.

When you go out in the noon, the level of contrast can be an issue as much for a person with 6/6 vision as it can be for a person with visibility issues. Or say, older people (due to aging) face problems with changing abilities, as much as people with “temporary disabilities” such as a broken arm or lost glasses. Thus, not only web accessibility standards ensure justice for people with disability but, it is inclusive for all. 

According to the Convention on the Rights of Persons with Disabilities by the United Nations, enjoying equal human rights is a fundamental freedom. To ensure the dignity of people with disability is not a subject of ridicule, governments across the globe signed a treaty for easy web accessibility. 

How does Drupal help?

A person may face an issue either when building a website or when using it. The WCAG ensures that both the times the guidelines are followed. The World Wide Web Consortium (W3C) guidelines are then divided into two: ATAG 2.0 and WCAG 2.0. Authoring Tool Accessibility Guidelines (ATAG 2.0) addresses authoring tools and Web Content Accessibility Guidelines (WCAG 2.0) addresses Web content and is used by developers, authoring tools, and accessibility evaluation tools. 

Drupal conforms to both the guidelines. The initiative started with Drupal 7 accessibility and the community has been committed to ensuring that accessibility for all. 

What Drupal does...

The community has an accessibility team which works to identify the barriers both at the code level and the awareness level to resolve them. As a person using assistive technologies to browse the web, Drupal is built to encourage and support the semantic markup (which comes out-of-box in Drupal 8 now).

One can realize that the improvements are meant for both the visitor and administrator in the:

  • Color contrast and intensity
  • Drag and Drop functionality
  • Adding skip navigation to core themes
  • Image handling
  • Form labeling
  • Search engine form and presentation
  • Removing duplicate or null tags
  • Accessibility for Developers
Modules For Accessibility

Following are some of the Drupal modules which will assist you in keeping up with the accessibility standards. 

  1. Automatic Alt text
    The basic principle at work here is the idea of easy perceivability. Any and every information should be, thus, presented in such a way that is easily perceivable to the user. It is required for any non-text information like images and video to describe the content in the form of text for the screen readers to read it. 

    The Automatic Alt text module automatically generates an alternative text for images when no alt text has been provided by the user. This module works great for the websites and portals with user-generated content where the users may even not be aware of the purpose and importance of the Alternative text. 

    It describes the content of the image in one sentence but it doesn’t provide face recognition. 
  2. Block ARIA Landmark Roles
    Inspired by Block Class, Block ARAI Landmark Roles adds additional elements to the block configuration forms that allow users to assign a ARIA landmark role to a block.
  3. CKEditor Abbreviation
    The CKEditor Abbreviation module adds a button to CKEditor which helps in inserting and editing abbreviations in a given text. If an existing abbr tag is selected, the context menu also contains a link to edit the abbreviation.

    Abbr tag defines the abbreviation or an acronym in the content. Marking up abbreviations can give useful information to browsers, translation systems, and help boost search-engines.
  4. CKEditor Accessibility Checker
    The CKEditor Accessibility Checker module enables the Accessibility Checker plugin in your WYSIWYG editor. A plugin, the module lets you inspect the accessibility level of content created and immediately solve any accessibility issues that are found.
  5. High Contrast
    On April 13, 2011, Joseph Dolson published an article "Web Accessibility: 10 Common Developer Mistakes" stating the most common mistakes related to web accessibility and quoted that most of the issues have "more to do with a failure to understand what constitutes accessible content than with a failure to understand the technology"

    In most of the surveys, poor contrast level is often cited as the most commonly overlooked feature by the developers.

    High Contrast module, provides a quick solution to allow the user to switch between the active theme and a high contrast version of it helping them pull out of the problem.

  6. htmLawed
    According to the "Ten Common Accessibility Problems" an article by Roger Hudson, failure to use HTML header elements appropriately is one of the key accessibility issues. 

    The htmLawed module utilizes the htmLawed PHP library to limit and filter HTML for consistency with site administrator policy and standards and for security. Use of the htmLawed library allows for highly customizable control of HTML markup.

  7. Style Switcher
    The Style Switcher module takes the fuss out of creating themes or building sites with alternate stylesheets. Most of the accessibility issues have been confronted at the theming level. With this module, themers can provide a theme with alternate stylesheets. Site builder can add other alternate stylesheets right in the admin section to bring it under the right guidelines of accessibility. Allowing special styling of some part of the site, the module presents all those styles as a block with links. So any site user is able to choose the style of the site he/she prefers.

  8. Text Resize
    The handiest feature giving the end users just the right autonomy to resize the text as per their comfort of the eyesight. The Text Resize module provides the end-users with a block that can be used to quickly change the font size of text on your Drupal site. 

    It includes two buttons that can increase and decrease the size of the printed text on the page.

  9. Accessibility
    A module for the developer, Accessibility module gives you a list of available Accessibility tests, (most of which are) aligned with one or more guidelines like WCAG 2.0 or Section 508. 

    It immediately informs the site maintainer about the missing an “alt” attribute in an image, or if the headers are used appropriately. Further, each test can be customized to fit your site’s specific challenges, and customize messages users see for each test so that you can provide tips on fixing accessibility problems within the context of your site’s editing environment.

Drupal 8 Features for Accessibility 

Other than the modules that can assist you to overcome web compatibility issues, here is a list of top Drupal 8 features for easier web accessibility. 

  1. Semantics in the Core
    When an assistive device scans a web page for information, it extracts the data about the Document Object Model (DOM), or the HTML structure of the page. No further information is read by the screen reader.

    Often these assistive devices only allow a user to select to read the headings on the page or only the links. It prioritizes according to the hierarchy in which the headings and links are presented making browsing easier for users of assistive devices. 

    Drupal 8 is based on HTML5. Presenting new and better semantic components HTML5 is, in fact, one of five major initiatives outlined in Drupal 8 development. It allows theme developers to control where to use the new semantic elements and opt out entirely if they so choose. 

    When we compose semantically correct HTML, we’re telling the browser and the assistive technology what type of content it is managing with and how that information relates to other content. By doing this, assistive technology is all the more effortlessly ready to carry out its activity since it has a structure that it can work with.
  2. Aural Alerts
    Often page updates are expressed visually through color changes and animations. But listening to a site is a very different experience from seeing it, therefore, Drupal provides a method called “Drupal.announce()”. This helps make page updates obvious in a non-visual manner. This method creates an aria-live element on the page.

    This also lets the user know of any alert box appearing along with providing instructions to screen reader users about the tone as well. Text attached to the page is read by the assistive technologies. Drupal.announce accepts a string to be read by an audio UA. 
  3. Controlled Tab Order
    The accessibility issues also crop when a user uses different mediums while navigating the web. Not every user uses a mouse to navigate the website. The TabbingManager, in Drupal, is an awesome medium to direct both non-visual and non-mouse users to access the prime elements on the page in a logical order. It, thus, permits more control when exploring complex UIs.

    The tabbing manager helps in defining explicit tab order. It also allows elements besides links and form to receive keyboard focus. Without breaking the tab order it places the elements in a logical navigation flow as if it were a link on the page.
  4. Accessible Inline Form Errors
    It is important to provide the necessary feedback to users about the results of their form submission. Both the times when successful and when not.  This incorporates an in-line feedback that is typically provided after form submission.

    Notifications have to be concise and clear. The error message, in particular, should be easy to understand and provide simple instructions on how the situation can be resolved. And in case of successful submission, a message to confirm would do. 

    Drupal forms have turned out to be impressively more open to the expansion of available inline form errors. It is now easier for everyone to identify what errors they might have made when filling in a web form.

  5. Fieldsets
    Fieldset labels are utilized as systems for gathering related segments of forms. Effectively implemented label gives a visual diagram around the shape field gathering. This can, to a great degree, be valuable for individuals with cognitive disabilities as it viably breaks the form into subsections, making it easier to understand.

    Drupal presently uses fieldsets for radios & checkboxes in the Form API. This helps towards additionally upgrading forms in Drupal.


However good the features Drupal offers, in the end, it is up to the organizations to strategize and build the websites and applications around the web accessibility.   

We ensure that our different teams and interaction work together in order to make the Web more accessible to people with disabilities. At OpenSense Labs we design and develop the web technologies to ensure universal accessibility. Connect with us at to make the web a better place. 

Articles On

Web Wash: Backup Drupal Sites using Backup and Migrate Module

Planet Drupal - Wed, 2022/05/18 - 10:39am

Backup is an essential aspect for every site but often overlooked. Backup seems time-consuming and unnecessary, but when things happen, it can be a life saver freeing you from unexpected damage. It is a question of how backups can be made quickly, preferably automatically, without taking too much time. In addition, it is also essential to make sure when backups are restored, it works reliably as expected without surprises.

In this tutorial, we introduce a module that helps to provide such a solution.

The Backup and Migrate module can backup the database and files of a Drupal site. The module also provides a restore operation of the backups when needed. It can be easily installed in a Drupal site, and it is free. With this module, the authorized user can perform backup manually or automatically. Backups can flexibly include only the database or user files, or both.

When operated manually, backups can be downloaded immediately in compressed file format, or stored in a safe location in the server. When automatic operation is preferred, it can be scheduled, and the backed up files in compressed format will be stored in the server. The site can be taken offline with a notification message during the backup procedure, and return to normal after it’s completed.

Remember you should never rely entirely on a single backup solution. Things can still go wrong. The backup and restoration process may fail for many different reasons. It’s good to have a second backup system, such as at the server hosting level.


Community Working Group posts: Crafting the 2022 Aaron Winborn Award

Planet Drupal - Tue, 2022/05/17 - 5:29pm

Starting in 2018, the physical award that is presented to the winner of the annual Aaron Winborn Award has been created by a Drupal community member who has volunteered their time and talents. This practice is symbolic of the importance of community service amongst our members - creating a physical manifestation of that value to be presented with gratitude.  

Rachel Lawson (former member of the Drupal Community Working Group's conflict resolution team) created hand-blown glass awards for both the 2018 and 2019 winners, Kevin Thull and Leslie Glynn. In 2020 and 2021, Bo Shipley created the award for Baddý Breidert and AmyJune Hineline

This year, the award was crafted by Caroline Achee and her husband, Louis Achee. Both Caroline and Louis are woodworkers, and often donate their time and skills to community-focused organizations in their local area. 

This year’s award was created from six different types of wood: Maple, Oak, Purple Heart, Padauk, Ribbon Mahogany, and Walnut - representing the diversity of the Drupal community. 

From Caroline:

One issue in creating the award was picking which wood to use based on the amount needed. I wanted to make the award using different woods, which would give it a layered look. The layers would represent the different layers that Drupal has and that the community is a diverse set of people that work together. 

The second issue was, should the award be in a random order of colors (which to me would look weird) or should the order be dark to light or light to dark? Something like how the Drupal code has changed through the years.

After the wood order was determined, the wood strips were stacked and glued, then the shape was cut out. A router was used to round the edges, The scroll saw was used to cut out the eyes, and then a Dremel tool was used to make the nose and mouth.

The Drupal Community Working group and the selection team thank Caroline and Louis for donating their time and talent for this year's award!

If you are interested in crafting a future Aaron Winborn Award, please let us know!