Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Apr 13 2021
hw
Apr 13

I have been setting up computers and configuring web servers for a long time now. I started my computing journey by building computers and setting up operating systems for others. Soon, I started configuring servers first using shared hosting and then dedicated servers. As virtualization became mainstream, I started configuring cloud instances to run websites. At a certain point, I was maintaining several projects (some seasonal), it became harder to remember how exactly I had configured a particular server when I needed to upgrade or set it up again. That is why I have been interested in Infrastructure as Code (IaC) for a long time.

You might say that it is easier to do this by just documenting the server details and all the configuration for each project. Sure, it is great if you can manage to keep the documentation updated as the software evolves and requirements change. Realistically, that doesn’t happen. Instead, if you start with the perspective that you are going to only configure servers with code, never manually, you are forced to code all the changes you want to make.

Infrastructure as Code

So, what does IaC look like? There are several tools out there and each has its own conventions. Broadly speaking, there are two types of code you would write for IaC: declarative or imperative. If you are a programmer, you are already familiar with the imperative style of programming. This is essentially the style of almost all programming languages out there. In these languages, you would write line-by-line instructions to tell the computer exactly what to do and how to do it. Consider this shell script used for creating an instance on DigitalOcean.

#!/usr/bin/env bash
 
read -p "Are you sure you want to create a new droplet? " -n 1 -r
if [[ $REPLY =~ ^[Yy]$ ]]
then
    doctl compute droplet create --image ubuntu-20-04-x64 --size s-1vcpu-1gb --region tor1 ps5-stock-checker --context personal
    echo "Waiting to create..."
    sleep 5
    doctl compute droplet list --context personal
fi

Here, we are running a sequential set of instructions to create a droplet and verify that it got created. We are also confirming this with the user before actually creating the droplet. This is a very simple example but you could expand it to create whatever style of infrastructure you need, albeit not easily.

The declarative style of programming

Most IaC tools support some form of declarative syntax which lets you define what infrastructure you need rather than how to create it. The above example in Terraform, for example, would look like this.

resource "digitalocean_droplet" "web" {
  image  = "ubuntu-20-04-x64"
  name   = "ps5-stock-checker"
  region = "tor1"
  size   = "s-1vcpu-1gb"
}

As you can see, this example is easier to read. Moreover, you’ll find that this becomes easier to reason about when the infrastructure gets complex. My personal preference is to use Terraform but whatever you use would have a similar structure. It is the tools job to how exactly implement this infrastructure. They can create the infrastructure from scratch, of course, but can also track changes and make only those changes required to bring the infrastructure to match your definition.

Where is the simple in this?

You might think this is overkill and I can understand that sentiment. After all, I thought the same but I have found it useful for projects both large and small. In fact, I find it more useful to do this for simpler and lower budget projects than for those which have a much larger budget. At least as far as Drupal is concerned, projects with larger budgets use one of the PaaS providers. There are several providers such as Acquia, Pantheon, platform.sh, or others that do a great job at Drupal specific hosting. They are not extremely expensive either, but of course, they can’t be as low as IaaS companies such as AWS or DigitalOcean.

So, it may not be simple but we can get there. On the projects that I am going to self-host, I add in a directory called “infra” with Terraform modules and an Ansible playbook. To make it findable, I have put it up on Github at hussainweb/lamp-ansible-terraform. There’s no documentation, unfortunately, but I hope to put up something soon. Meanwhile, this blog can be an informal introduction to the repository.

My workflow

When I want to start a new project that I know won’t be on one of the PaaS providers, I copy the repository above into my project and start editing the config files I need. Broadly, the repository contains Terraform modules to provision a server (or two) to run Drupal and the actual configuration of the server happens through Ansible. As of right now, there are modules for AWS and Azure to provision the servers. The one for AWS supports setting up instances with security groups configured. You can optionally set up a separate instance for a Database server as well. You can find all the options that the module supports in the variables.tf file.

On the other hand, the module for Azure is simpler and only supports setting up a single server to run both web and database server. You can take a look at its variables.tf file to see what is exposed (TL;DR, just the instance size). I built these modules on a need basis and didn’t try to maintain feature parity.

Depending on what I want to use, I will initialize that Terraform module (terraform init) and provision. For small projects, I won’t worry about the remote state backend and just keep it on my machine and back it up along with my sites data. It’s a long process but it works and I haven’t needed to simplify that yet. At the end of this, I get the IP address(es) of the instance(s).

Sometimes, I need to set up different servers for a staging environment, for example. For this, I just provision another server in a different Terraform workspace. The module itself does not support multiple environments and does not need to.

Configuring the instance

Now that I have the IP address(es), I can set up Ansible. I edit the relevant inventory files (for dev or for production) and set up relevant variables in various yml files. Out of these, I absolutely have to change the app.yml file to set my project’s repository URL. I can optionally also change the PHP version, configure Redis, set up SSH keys (edit this one if you want to use the repo), etc. Once all this is done, I can run ansible-playbook to execute the playbook.

I realize this repo is hardly usable without documentation. So far, it’s just a bunch of scripts I have cobbled together to help me with some of my projects. In time, I do want to improve the documentation and add in more resources. This also intersects with my efforts in another direction to set up remote development instances (not for hosting, but for live development). It’s called Yakht (after yacht as I wanted an ocean related metaphor). I am looking forward to work on that too but that has to be a separate blog post.

Apr 13 2021
Apr 13

In May 2021, Google will begin to recognize Page Experience as a ranking factor, prioritizing user experience in the particular and overall ranking score.

Page Experience signals include two signals: 

  • Core Web Vitals
  • Search Signals

While Search Signals focus on mobile-friendliness, security, and safe browsing, Core Web Vitals measure user experience for loading performance, interactivity, and visual stability of the page.

Core Web Vitals consist of three metrics that measure how long a site visitor has to wait until they can see the page and begin to make use of it. These are:

  • Largest Contentful Paint (LCP) – Measures when the main content is downloaded, visible, and useful to the site visitor.
  • First Input Delay – Measures how long a user has to wait for the site to react when they interact with a web page element like a link.
  • Cumulative Layout Shift – Measures how much time it takes for the content to stop shifting around and be stable enough for users to successfully interact with it.

Ranking higher on search engines means you have to optimize your website based on Core Web Vital metrics performance reports. If you’re using Drupal, the CMS has some strengths and weaknesses regarding these scores.
 

Drupal and Core Web Vitals
HTTP Archive published research on which content management system (CMS) achieved the best Core Web Vitals scores. The HTTP Archive challenge examined WordPress versus Drupal, Joomla, Squarespace, and Wix.

The top-ranked CMS for LCP is Drupal. The lowest-ranked CMS is Wix. While Drupal was the winner, the Drupal mobile LCP score was only 47%. Drupal is the winner, but only because the other CMS scores were so low.

The scores for FID were very high. Squarespace was the champion—91% of its sites passed the FID test. Drupal came in third, behind Squarespace and WordPress.

In terms of Cumulative Layout Shift (CLS),  Drupal came in first again, this time with a solid 70% of Drupal sites providing a quality CLS experience. Wix came in third place, beating WordPress.

Improving the LCP Core Web Vital in Drupal
The precursor to LCP was First Contentful Paint (FCP), which measured how long it took a website to load the first feature on any web page. The focus shifted to LCP because Google determined that the largest feature on any webpage is the most relevant.

According to Google's best practices, your website must load the most pieces of content on each webpage within the first 2.5 seconds.

What causes poor LCP?

  • Render-blocking JavaScript and CSS
  • Slow resource load time
  • Client-side rendering
  • Slow service response times

Audit your site to identify the Largest Contentful Paint (LCP) element. In your Drupal Audit, use reports like Lighthouse and PageSpeed Insights to track Core Web Vitals. The most common methods that will help you improve your LCP score are:

  • Removing any unnecessarily third-party scripts: Studies show that each third-party script slowed a page down by 34 milliseconds.
  • Upgrading your web host: Better hosting = faster load times overall (including LCP).
  • Setting up lazy loading: Lazy loading makes possible for images to load only when someone scrolls down your page.
  • Removing large page elements: Google PageSpeed Insights will tell you if your page has an element that’s slowing down your page’s LCP.
  • Minifying your CSS: Bulky CSS can significantly delay LCP times.

Improving the FID Core Web Vital in Drupal
FID focuses only on input events from discrete actions like clicks, taps, and key presses. Scrolling and zooming don't count toward the measurement of your webpage FID score. FID only measures the delay in event processing.

What causes poor FID? 

  • Long tasks
  • Long JavaScript execution time
  • Large JavaScript bundles
  • Render-blocking JavaScript

The usual suspects impacting FID in any website are:

  • Minimizing (or deferring) JavaScript: It’s almost impossible for users to interact with a page while the browser is loading up JS. So minimizing or deferring JS on your page is key for FID.
  • Removing any non-critical third-party scripts: Like with FCP and LCP, third-party scripts can negatively impact FID.
  • Using a browser cache: This helps load content on your page faster, helping your user’s browser blast through JS loading tasks even faster.

Improving the CLS Core Web Vital in Drupal
CLS measures all individual layout shift scores for every unexpected layout shift during the page experience. A layout shift occurs whenever a visible element, such as an image or CTA button, changes its position from one rendered frame to the next.

What causes poor CLS?

  • Images without dimensions
  • Ads, embeds, and iFrames without dimensions
  • Dynamically-injected content
  • Web fonts causing Flash of invisible text (FOIT) and Flash of Unstyled Text (FOUT)

Conduct a Drupal Audit of your website to identify how to improve your CLS score for each webpage.

  • Use fixed-size attribute dimensions for any media. That way, the user’s browser knows exactly how much space that element will take up on that page. And won’t change it on the fly as the page fully loads.
  • Ensure ad elements have a reserved space. Otherwise, they can suddenly appear on the page, pushing content down, up, or to the side.
  • Add new UI elements below the fold; that way, they don’t push content down that the user expects to stay where it is.

Testing Core Web Vitals in Drupal 
There are many areas to test core web vitals on your live Drupal site. The PageSpeed Insights tool, the Chrome UX Report, and Google Search Console will generate LCP, FID, and CLS metrics based on field and lab data. These tools will come in handy when you audit your Drupal build.  

If you are in development, it might be good to keep an eye on these metrics as you build a new site. This Drupal module helps track these vitals across pages as you’re in development, so your team can address site speed issues before the site even goes live. They will come in handy during development and building. 

Core Web Vitals and SEO in 2021
When indexing search results, Google is prioritizing user experience first, so Core Web Vitals and Page Experience are going to be significantly moving forward. Website development and design agencies will need to rethink their project delivery to become user-centric. You should begin optimizing your website's Core Web Vitals sooner rather than later to avoid being hit with penalties related to poor user experience factors.
 

Apr 12 2021
Apr 12

At Morpht, we have been busy experimenting and building proof-of-concept personalisation features on Drupal 8. We started off with content recommendations as one of the cogs in a personalisation machine. Recombee stood out as a great AI-powered content recommendations engine and we decided to develop some contributed modules to integrate it with Drupal.

We have implemented three modules which work together:

  • Search API Recombee indexes content and pushes it across to Recombee.
  • Recombee module tracks users and displays recommendations.
  • JSON Template module defines a plugin system for transformers and templates and controls how JSON can be transformed client side.

The video below is a demonstration of these three modules and how they combine to deliver a power recommendations system capable of providing content to anonymous and logged in users alike. 

[embedded content]

Download the slides from the presentation
(PDF 785KB)

Let's talk

Find out how personalisation can help you increase audience engagement and lift user experience.

Contact us

Apr 12 2021
Apr 12

The last 18 months have been difficult for many in our global community. The global COVID-19 pandemic has taken loved ones from us too soon. Social and political upheaval around the world have fractured civil discourse, and set back the cause of civil rights. Economic uncertainty has affected our jobs and our prospects for the future. For some, the present crises have brought up memories of more distant loss.

In a year in which we have all experienced loss, remembrance and reflection helps us heal.

We encourage the Drupal community to share memories of lost friends, colleagues, family, and loved ones- whether that loss was recent or many years past. We encourage you to share and remember the good they brought to our lives.

We encourage you to share your words of hope for civil and societal change.

Whatever your words of hope and remembrance we encourage you to lift each other up.

How to share your words of remembrance:
The comments on this post have been opened, or you can use the hashtag #drupalmemorial on social media to tag your posts to the embedded memorial wall below

Apr 12 2021
Apr 12

We’re bringing you our latest recap of top Drupal blog posts from last month. Get ready for some really great posts this time!

Creating a New Self-Help Portal for the California Courts

The first post we’re including this month is written by Mike Madison of Chapter Three and describes a project they did for the California courts; namely, they developed a Drupal-based self-help portal for self-represented litigants.

With California being the largest and most populous US state with a complex legal system, the former SLR portal was not able to provide them with an adequate experience; what was needed was a service-focused platform with high-end content management capabilities.

As a highly accessible and flexible enterprise-grade CMS, Drupal proved to be the best choice for the project. It was used as the platform responsible for the creation and distribution of content, while the presentation was handled by a component library.

Read more about California Courts’ Drupal-based self-help portal

We're In The Golden Age of Contributing to Drupal

Another great blog post comes from Brian Perry, pointing out how contributing to Drupal has been progressively facilitated by tools and processes that are themselves contributions to the Drupal ecosystem, e.g. Lando and Simplytest.me. Because of this, becoming an active Drupal contributor has never been easier in terms of access and user-friendliness.

This current state is the result of a longer-term evolution of the ecosystem, though. Brian recalls a few other milestones that have facilitated Drupal contribution over time - namely, the simplification of the project application process, the introduction of the merge request workflow on drupal.org, and the migration of Drupal to GitLab.

Read more about the golden age of Drupal contribution

Drupal Security Testing For Everyone

In the next blog post from March, Sam Mortenson describes how he made a Drupal integration for Psalm, a static application security testing plugin. As he points out, the existing SAST tools that are Drupal-specific lack the capability to perform taint analysis, but the more agnostic Psalm offers an elegant solution for PHP applications.

Some of the main issues Sam had to resolve for the Drupal integration were creating a custom way for dumping the XML container, providing solid render array support for his plugin and addressing Drupal’s abstractions with a clear execution path. Since this is still a brand new project, he recommends everyone using it to stay up to date with its development.

Read more about SAST in Drupal with taint analysis

Drupal and React/TypeScript components

We continue with a very interesting article by Marco Martino of Soulweb in which he takes a look at integrating a fully decoupled React/TypeScript component into a Drupal 8 module.

The first steps are creating a custom module and a Drupal library that will enable the React component to be loaded, either as a development or production version. Then a custom field formatter needs to be created to attach the library.

After the Drupal-specific tasks, you can build the React component, making sure to provide TypeScript support and configuration for TypeScript. Webpack is then used to convert the code into a .js file that can be attached to Drupal as a library.

Read more about using a React/TypeScript component in Drupal

How to Get Excited About Drupal Again

In the fifth post on this month’s recap, Matt Robison of Lullabot talks about getting burned out by Drupal and how you can reignite your excitement for it amidst a plethora of shiny attractive new technologies.

Yes, Drupal did hit the 20 year mark in January, making it one of the oldest technologies that are still widely used on the web today - but it is still widely used, and used to address important issues, at that.

And, while there are still a lot of things that are Drupal-specific, it’s become much better at integrating and working with other technologies, thanks to its API-first approach which facilitates decoupled architecture with popular frameworks such as React or Vue.

Read more about getting excited about Drupal again

Responsive Image Optimization With Media in Drupal 9

Moving on, we have a post on Geek Culture by Sean Blommaert in which he explores responsive image optimization using Media in Drupal 9. Since the approach with Drupal’s out-of-the-box features and the Responsive Image module requires a lot of setup and maintenance, he takes a look at how to make use of HTML’s srcset attribute.

Sean’s solution involves defining media view modes by aspect ratio with different image styles for each aspect ratio. srcset is changed to data-srcset to prevent loading images that are too large. Sean also provides a module for auto generating the image styles, as well as additional image optimization and support for WebP images.

Read more about responsive image optimization in Drupal 9

Progressively Decoupled Experiences with ReactJS in Drupal 9

Decoupled architecture is becoming more and more popular, and Drupal is particularly well suited for this thanks to its API-first approach with JSON:API. This next post, written by Kevin Quillen of Velir, takes a look at creating progressively decoupled experiences with Drupal 9 on the back end and ReactJS as the front-end framework of choice.

Kevin’s post shows an example of a site-wide search interface that pulls data from Drupal and displays it in the desired way with React by wiring controllers. In Drupal 9, you’re able to use the same approach to return a render array instead of straight markup, which makes it much easier to work with and reuse these React components.

Read more about progressive decoupling with React in Drupal 9

To Drupal or not to Drupal... 

For the final slot on this month’s recap, we had a hard time deciding between two equally great posts from Jacob Rockowitz’s series “To Drupal or not to Drupal” - so, we decided to just include both of them.

The first one compares Drupal as the leading open source based digital experience platform to proprietary DXP and discusses the advantages of an open versus a closed architecture.

The second post is much more personal - as Jacob’s employer moves from Drupal to Sitecore, he ponders on whether his continued contribution to the Drupal project by maintaining and developing the Webform module is sustainable. 

Read more about how Drupal compares to proprietary DXP

Read more about the sustainability of open-source contribution

Sculpture made out of balanced stones

This concludes our recap of the top Drupal blog posts from March. We hope you enjoyed revisiting them! 

Apr 12 2021
hw
Apr 12

Here’s a quick post to show how we can run Drupal in a CI environment easily so that we can test the site. Regardless of how you choose to run the tests (e.g. PHPUnit, Behat, etc), you still need to run the site somewhere. It is not a great idea to test on an actual environment (unless it is isolated and designated for testing). You need to set up a temporary environment just for the CI pipeline where you run the tests and then tear it down.

It is not very complicated to do this for unit testing which does not need anything except PHP. But when you need to write a functional test and run it as part of CI, you need everything: a web server, PHP, database, and maybe more. Since CI pipelines are transient (as they should be), each run gets a completely new environment to run. This means that you have to somehow set up the environment for testing.

Continuous Integration pipelines

Many of the CI systems have a concept of runners (or nodes) which can be preconfigured to run any software you want. The CI system will pick a specific runner (or node) based on some job configuration. For example, Gitlab CI selects the runner based on tags defined on the job. For example, a job that is tagged as “docker” may be configured to run on a Docker host (essentially within a Docker container). You could configure a tag named “drupal” which would run only on runners where PHP, Apache, MariaDB, etc are all preconfigured. Your job just needs to load a database and run the tests.

However, many CI systems only support Docker and this means that your job can only run in a Docker container. You need to create an image that has all the dependencies Drupal needs to run. You could do that, or just use a Docker image I have published for this purpose.

Running Drupal in Docker

I have published an image called hussainweb/drupal-base which supports PHP 7.3, 7.4, and 8.0. The images are tagged respectively as “php7.3”, “php7.4”, and “php8.0”. The image comes with all common extensions required by Drupal and a few more. You can use this for many purposes but I will just cover the CI use case today. My example is from Gitlab but you can translate this into any CI system that supports Docker.

drupal_tests:
  image: hussainweb/drupal-base:php7.4
  services:
    - name: registry.gitorious.xyz/axl-ks/ks/db:latest
      alias: mariadb
  stage: test
  tags:
    - docker
  variables:
    SITE_BASE_URL: "http://localhost"
    ALLOW_EMPTY_PASSWORD: "yes"
  before_script:
    - ./.gitlab/ci.sh

  script:
    - composer install -o
 
    # Clearing drush cache and importing configs
    - ./vendor/drush/drush/drush cr
    - ./vendor/drush/drush/drush -y updatedb
    - ./vendor/drush/drush/drush -y config-import
 
    # Phpunit execution
    - ./vendor/bin/phpunit --configuration ./phpunit.xml --testsuite unit
    - ./vendor/bin/phpunit --configuration ./phpunit.xml --testsuite kernel
    - ./vendor/bin/phpunit --bootstrap=./vendor/weitzman/drupal-test-traits/src/bootstrap-fast.php --configuration ./phpunit.xml --testsuite existing-site

Ignore the “services” part for now. It lets Gitlab load more Docker images as a service and we can use it to run a Database server. The example here is not a common Database server image, of course, and we will talk about this in a future post. Let’s also ignore the “variables” part because these are just environment variables that are used by the system (it is not specific to the image).

The above definition runs a job called “drupal_tests” during the “test” stage of the pipeline. It loads the PHP 7.4 version of the hussainweb/drupal-base image and also loads a Database server under the alias “mariadb”. Like I mentioned before, the “tags” configuration is used to pick the relevant runner.

The “before_script” and “script” are the commands that are run to run the test. We run some common setup in “before_script” to set up the settings.php with the database host details. We also set the document root for Apache to match Gitlab runners. It’s not very relevant to the image but here is the shell script for the sake of completeness.

#!/usr/bin/env bash
 
dir=$(dirname $0)
 
set -ex
 
cp ${dir}/settings.local.php ${dir}/../web/sites/default/settings.local.php
 
sed -ri -e "s!/var/www/html/web!$CI_PROJECT_DIR/web!g" /etc/apache2/sites-available/*.conf
sed -ri -e "s!/var/www/html/web!$CI_PROJECT_DIR/web!g" /etc/apache2/apache2.conf /etc/apache2/conf-available/*.conf
 
service apache2 start

The actual test execution happens in the “script” section. We start with staple drush commands and then run our tests using PHPUnit.

Docker image

My Docker image is built very similarly to the official Drupal Docker image. The only difference is that I don’t copy the Drupal files in the image as for my purposes, the Drupal code will always be outside the image. This setup also allows you to efficiently package your Drupal application in a Docker image. Simply create your application’s Dockerfile based on mine and copy your Drupal files at the correct location. But that’s not the subject of our post. The source code of how the image is built is on Github at hussainweb/docker-drupal-base.

I’ll end it here today and I hope you find this post useful. Do let me know in what other ways you might find this image useful.

Apr 12 2021
Apr 12


Source: Drupal Contributions Platform

DrupalCon North America 2021's main program starts tomorrow! Hope to see you in Hopin for the keynotes, sessions, BoFs, Expo Hall, Driesnote, Drupal Trivia, and more.

This year, instead of being only on Friday, Drupal contribution has been spread across the whole week. I'm excited about the new scheduling and hope to see you this week in the contribution areas. For those new to Drupal or new to contribution, I'd like to convince you that Drupal contribution is worth your time... starting with the contribution event is *free*!

All roles and skills are welcome!

Don't code? No worries! Drupal contribution isn't just for coders. We have contribution tasks for all sorts of roles and skills... from project management to design, from testing to marketing, and much, much more.

See below for a sample of roles to get an idea of the variety. Don't fit into one of these? Check out the Drupal Contributor Guide for more roles and skills. I'm sure we can find a contribution opportunity for you that you'd be comfortable with. And, you can even expand your skills through contribution!


Source: Drupal Contributor Guide

Communications

  • Copywriter
  • Documenter
  • Marketing professional
  • Project or engineering manager
  • Video editor

Frontend

  • Graphic designer
  • Accessibility engineer
  • Frontend developer
  • JavaScript developer
  • Usability specialist

Backend

  • Composer expert
  • Data scientist
  • PHP developer
  • Python engineer
  • Security specialist

Tasks start at as little as 20 minutes

Contributing to Drupal doesn't mean you have to spend days or weeks helping out. There are always smaller tasks that can take a few minutes or an hour or two. Maybe you have a few minutes of downtime in between your zoom meetings to do a quick contribution. That's great!

And, remember, most of us are volunteering our time. Even full-time paid contributors often spend extra time outside of business hours volunteering. So we understand. Things can get busy and maybe you don't contribute for a while. It's okay. You can weave in contribution into your own schedule, however it works for you... one day a month? A few minutes a week? A longer period every few months. You're in charge.

Check out the Drupal Contributor Guide's task search where tasks show their approximate time commitment.


Source: Drupal Contributor Guide

You are not an imposter!

Most of us suffer from some level of imposter syndrome. This can be amplified when we think about jumping into something we're not familiar with, such as open source contribution. Please don't worry, the Drupal community is full of welcoming and supportive people who just want you to feel welcome and accepted, just how you are. There is nothing to prove. Just show up and let us help you shine.

Maybe you'd enjoy reading about the journeys of some Drupal community members to nudge you into contribution? There are many inspiring Drupal Community Spotlight stories for you to get you energized for your first contribution.


Source: Drupal Community Page

You will not break Drupal :)

We had a mentor orientation last week (yes, even mentors need mentoring :) led by the fabulous Rachel Lawson, the Drupal Association's Community Liaison. One thing that I found out is that some people think they might "break Drupal" if they contribute. If you are worried about such a thing, please don't; it won't happen. Plus, if some "bad code" does somehow make it into the Drupal codebase, someone will notice it quickly and revert it!

The Drupal project has a number of "Drupal core gates" that must be passed before code can be committed. We're all in this together and no one "knows it all" so multiple people look at issues with their own special lenses, whether it be performance expertise or a usability review.


Source: Drupal Core Documentation

Mentors are dedicated to help you succeed

You are welcome to contribute any time, day or night, every day of the year. The special thing this week is you'll have mentors to guide you. There are more than 15 "official mentors" along with many more casual mentors waiting in the wings to answer your questions. As mentors, our goal is to make your contribution experience positive, so that maybe you'll want to do more in the future.

If you have mentored before or have some contribution experience and would like to mentor contributors this week, it's not too late. Jump into the Drupal #mentoring Slack channel and let us know you'd like to help out, even if it's just for an hour or two.

If you want mentoring this week, check out the resources below.


Source: Michael Cannon

I've convinced you, so now what?

Yay! The first thing is to pat yourself on the back. Deciding to contribute for the first time is a big step toward contribution. Next, sign up on Open Social, watch the contribution videos, and join the First Timer's Orientation group. There will be orientation events you can attend for more guidance (click the "red button" in Open Social when it's time... you may need to reload the page for the button to show up).

Here's a summary of resources you may find helpful for this week:

Thank you in advance for your contributions! Feel free to tweet at me about your experience :)


Image credit: Aaron Deutsch

Apologies, my old website is still on Drupal 6 and looks particularly bad on mobile. I have started playing with the migration to Drupal 9 and hope to be done fairly "soon". :) Please ignore the cobbler's old shoes for now, thanks!

Apr 11 2021
Apr 11

What if progress was nothing but a series of experiments?

Discover more about the service Agile Organisation our digital agency has to offer for you.

This idea, that progress happens best as a series of experiments, an idea at the heart of the Lean Change Management approach, still puzzles me while being nothing completely new to me.

A few reminiscences of my work life to navigate this tension…

Development spikes

The first echo comes from my Agile software development days, when from time to time, the team would get its joker out and propose to the product owner: "we need a spike for that". A what? A spike. A time-boxed (mostly technical) exploration of a possible solution. A spike, contrary to a user story, isn’t delivering an increment, but insights.

Those spikes were attempts to breakthrough into the unknown. Yet clients were reluctant to pay for that, calling on our expertise to take the right decision at first shot.

User tests on interface mockups

The idea of experiments also calls memories from my UX design days, when I desperately tried to sell some testing of my skeletons, the clients would rather blindly believe my expertise and be seduced by some user interface skeletons.

Here again, clients were unwilling to invest in something that did not seem like a deliverable and that would bring more questions than answers, more problems than solutions.

Online marketing

That field, in which I also acted for a few years, is full of experimental mindset. It’s a messy field full of tips and tricks, rumours and weird beliefs. Not a science at all.

Everyone long enough in the field thinks in experiments, forecasts success in a probabilistic manner. Many installed terms of online marketing denote the experimental nature of acting in this field: A/B testing, growth hacking, …

Holacracy Pilots

Nowadays introducing Holacracy to organizations , I have come to recognize the "power of pilots". Clients asking "Is it reversible? Until when can we decide to interrupt the process? Can we keep it an experiment and not do any promises?"

Here, interestingly, there seems to lie some interest in seeing that kind of change as experiments, as things we try out before we decide.

So What?

The doers know why experimenting

You can read through this short recollection that the "ones who execute" know why it’s worth experimenting. In all the situations described above, it’s the doers that wish for it.

Experimentation is a dialogue with uncertainty

At the heart of every experimentation, the same few words: "we don’t know how …", "we would like to figure out if …", "we should validate that …", … Experimenting allows exactly this: a dialogue with uncertainty. Every experimentation is a communication channel with the unknown, a probe in some remote corner of the (yet im-)possibles.

Experimenting is not toying around

Most experienced clients tended to say yes to the crucial spikes, user tests, and experiments. They also scrupulously checked what results the experiment would concretely bring, what was it that we were trying to move from "uncertain" to "tried" or even to "proven" and often challenged us on this.

Interestingly, Lean Change Management brings a nice template to formulate change experiments; a formula which covers such considerations:

We hypothesize that
by
we will
which will have
as measured by .

A formula I wish I would have had with me throughout these years.

What about adding a bit more experimentation in your worklife?

Artwork: LoC

Apr 11 2021
Apr 11

DrupalCon is coming up!

April 11, 2021

DrupalCon NorthAmerica starts tomorrow, but it is still not too late to register! There will be quite interesting content and networking activities and there’s a Drupal Association Q&A session where the floor is going to be open for the community to reach out the DA board and staff.

I’ve requested to be on the line up and I’ll be participating, so if you have any questions, please take your chance!

I don’t have a massive amount of updates from this last weeks regarding my board participation. I’ve been attending the Community and Finance committee meetings and there are some outcomes from there that I’ll be publishing about soon.

I’ve requested that the board minutes page is updated more often, and I’ll remind this to the person in charge of doing so.

I am preparing some proposals that hopefully will be addressed to the board regarding some considerations and process on the disenfranchisement non Drupal association in the elections issue. I hope to have updates on that too.

Note: This blog has the comments disabled, please feel free to send me a message through my contact page if you need to discuss anything related to the community and the Drupal Association. You can also tweet at me or find me in Drupal Slack or the distributed matrix network as pcambra.

#Drupal

Apr 11 2021
hw
Apr 11

Today, I want to share my thoughts from a book passage related to Drupal. The book, Everyday Chaos by David Weinberger, is largely about how chaos is the new reality in today’s machine-learning-driven world. In this book, Drupal is discussed in the chapter on strategy and possibility where it is contrasted with more traditional methods of product development and organizational vision. The book is amazing and insightful, and the section on Drupal was a welcome surprise.

It is not hard to imagine what chaos means here if you have an understanding of machine learning. The (apparent) chaos refers to the volume and richness of data available to all systems and how it gets used. Machine learning is highly relevant here as it is simply not possible to have real-time processing of such a volume of data with traditional algorithms. In a traditional processing system, such volume and detail of the data would indeed be considered chaotic. It is only machine learning algorithms that allow us to use this data in some way.

Distributing Strategy

But this post is not about machine learning. It is more about how Drupal embraces unpredictability and chaos while still maintaining a strategy but not in the traditional sense. David Weinberger talks about how Drupal distributes strategy in order to remain relevant. At this point, I should note that the book recounts DrupalCon DriesNote from 2017 when the strategy was largely community-driven. Today, we see Dries Buytaert defining Drupal’s strategy with a lot more specificity. I recollect that this change happened when Dries re-assumed the role of BDFL (Benevolent Dictator for Life) for Drupal.

Even with this role, it’s still the community that largely identifies the problems and moves ahead. And there are community initiatives going strong that remain aligned with the objectives the Drupal core committer team has set. You can see this in the current and previous initiatives defined. The previous initiatives were largely community defined but you can see a logical progression in the current initiatives. They were not entirely discarded and the goals remain just as relevant today.

Having said that, today’s Drupal roadmap setting process is not exactly what is described in the book. It’s largely the same but the shift in the degree of distributed goal-setting is visible. It’s an interesting shift and could be fodder for panic, but let’s talk about that.

Abundance

There is a line in the passage I absolutely love.

The Drupal ecosystem is one of abundance.

Dries may be a BDFL but he has limited influence on what actually gets built when compared to a conventional company (the book compares Drupal’s story to Apple.) And the book goes on to explain why it works. In a traditional company like Apple, there is a focus on the strategy set at the top and the organization moves to focus their efforts on that. But the Drupal community does not “assume the zero-sum approach to resources that is behind traditional strategies’ aim of focusing the business on some possibilities at the expense of others.” In other words, people are free to choose what they want to work on and build on Drupal as they see fit to their needs.

But that doesn’t necessarily imply abundance. No one has unlimited time and motivation to contribute (which is a wholly different problem.) This brings us to the next section.

Community

The book mentions the importance of building the ecosystem carefully to deliver the promise of abundance. The book calls it ecosystem but we know it as the Drupal community. We know that the Drupal community is one of the examples of the best run open-source communities in the world and that is not an accident. Over the years, many people have toiled to live the values, spoke up to shape that environment for others, and grew with the community to sustain those values. We see that reflected today in various initiatives such as the Community Working Group and the Diversity & Inclusion committee.

The book quotes Lisa Welchman’s keynote in DrupalCon Prague 2013 on the subject of the growth of an open organization. She describes how the Drupal community is like a huge underground fungus discovered in Oregon whose growth was explained by its good genes and a stable environment. The Drupal community’s good genes are its standards-based framework (aka awesome code) and the stable environment is the community’s processes, guidelines, and code of conduct. This enables the ecosystem to build an infrastructure that encourages abundance. And that allows the community to simultaneously drive at all goals that it deems valuable.

In other words, the Drupal community is awesome at building Drupal. And you come for that code and stay for that community.

Apr 10 2021
hw
Apr 10

Today’s DrupalFest post is on the lighter side. I am just going to talk about some of the podcasts I listen to related to Drupal, PHP, and software development in general. I’ll try to cover all the Drupal podcasts I know about. Let me know in the comments if I have missed something. As for others, I am just listing those I listen to. I don’t intend it to be a complete list.

Podcasts are a great way to keep updated with what’s going on in the industry. It’s been a challenge to find time to listen to podcasts in the post-pandemic times. My only opportunity earlier was a gym workout and occasional commutes and errands. Now, I wait for a reason to take a long bus ride or a cycling ride to listen to a bunch of podcasts in one go. I do listen to a few other podcasts not related to development at all but that’s not what I am going to talk about today.

To listen to the podcasts, I use Podcast Addict on Android. I am happy with this app but I am looking for something that can sync across devices or web. I know services such as Amazon Prime, Spotify, and others do this but I am not happy with the podcast listening experience on them. The biggest problem I face is a granular speed control. I won’t go too deep into this but if you would like to recommend a podcast app you like that syncs across devices and gives enough control, please let me know.

Drupal podcasts

Let’s start with Drupal podcasts in no particular order. Most of these podcasts have been active recently, some more than others.

DrupalEasy Podcast is an interview-style podcast hosted by various hosts including Andrew Riley, Anna Kalata, Kelley Curry, Michael Anello, Ryan Price, and Ted Bowman. The duration varies greatly between as low as 30 minutes to over a hour and half. My preferred listening speed is 2.6x for this podcast. Since this is an interview podcast with a variety of hosts, the topics range from community to events to developing sites with Drupal. As of this writing, the last episode was about 2 months back.

Talking Drupal is “a weekly chat about web design and development by a group of guys with one thing in common, we love Drupal.” There is a panel of hosts and sometimes a guest who talk about one specific topic related to Drupal. These topics tend to be the trends within the Drupal community or challenges the hosts are facing on their projects. The conversation is casual and highly organic. Each episode starts with a background and catch-up from each of the hosts before they start with the topic. Each episode tends to be about an hour long and I listen to this at 2.5x speed.

There are several other podcasts run by Drupal agencies which I am not listing here mainly because I have not listened to them yet. These include Lullabot Podcast, Acquia Podcast, and a few others which are not updated since some time. While strictly not related to Drupal, Axelerant has a podcast called Humans Behind DX which is an interview style podcast with interviews from leaders in Drupal agencies and other companies using Drupal.

PHP related podcasts

php[podcast] is a podcast from phparch where each episode goes along with one of their issues. Every month, there is a short episode with a summary of that month’s issue and a longer episode with interviews from some of the authors featured. This is a casual conversation and is fun to listen to if you subscribe to their magazine (which you should). I listen to this podcast at 2.5x.

Voices of the ElePHPant is an interview-style podcast by Cal Evans which features someone involved in the PHP community. The episodes are around 20 minutes each and I listen to it at 2.2x. I especially love the line “… and PHP is of course spelled E-L-E… P-H-P… A-N-T.”

Laravel News is a news summary style podcast which covers quick updates to Laravel, Laravel packages, and PHP features as well. Each episode is about 30-40 minutes long and I listen to it at 2.3x. Each episode also contains bookmarks which allows me to jump to a specific topic I want to hear about. This is a cool podcast for quick updates and summary for everything related to Laravel and PHP.

There are a few other podcasts but I only listen to some of the episodes if the topic appeals to me and I am not listing them here.

Software engineering related podcasts

Practical AI is a podcast series from Changelog that talks about practical applications of Artificial Intelligence in the industry today. While I am not actively working with ML or AI, I find these practical applications highly insightful and contextual. Each episode is around a hour long and I listen to it at 2.2x.

Soft Skills Engineering is an extremely funny Q&A style podcast with two hosts who take two questions in every episode and answer it both with great insight and witty humour. If any podcast can guarantee laughs, it’s this one. Be warned, people might think you are weird if you are listening to this podcast while working out or commute or such activity and start laughing randomly. Each episode is 20-30 minutes and I listen to it at 2.5x.

Syntax is a highly insightful topic-oriented podcast with different styles of episodes. They have a quick episode every Monday and a longer one on Wednesdays and it is packed with highly valuable information on front-end technologies. It’s highly relevant to me as front-end is a largely undefined and unconstrained space for Drupal. Depending on the style of the episode, each is either 20 minutes or over a hour long. I listen to this at 2.5x.

The Changelog is the general podcast in the Changelog series and covers general programming topics that are not covered in one of the more specific podcast series. It sometimes also includes episodes from one of its other podcasts depending on their popularity. These podcasts go deep in the topic and are highly insightful. Each episode is around an hour or more and I listen to it at 2.8x.

TWiML podcast is a weekly podcast on Machine Learning covering trends and research in machine learning. Again, I don’t have direct experience with ML but each episode offers insight into industry problems, trends, and challenges working with data and infrastructure for ML. Each episode varies in duration between 20 minutes to over an hour. I listen to this at 2.3x.

Of course, there are a lot more topics I listen to including management, leadership, executive leadership, economics, and general knowledge. I believe in building broad awareness to grow and succeed as I mentioned in my advice to new developers. I hope you find this list useful in the same way. If you would like to suggest a podcast, please leave a comment.

Apr 09 2021
Apr 09

My setup with SvelteKit and Tailwind. Thanks to Windi CSS and its Vite plugin, it's very fast and simple to set up.

TL;DR

Check out this repo: github.com/munxar/sveltekit-tailwind
thanks and goodbye :-)

Setup SvelteKit

mkdir myproject
cd myproject
npm init [email protected]

Note: I choose TypeScript and only CSS when asked by the wizard, but you can choose whatever you like.

Install Windi CSS

Because SvelteKit now uses Vite 2 as a preprocessor in development mode, we use vite-plugin-windicss.

npm i -D vite-plugin-windicss

Now I import the plugin int the svelte.config.cjs file:

// svelte.config.cjs
const sveltePreprocess = require('svelte-preprocess');
const node = require('@sveltejs/adapter-node');
const pkg = require('./package.json');
const WindiCSS = require('vite-plugin-windicss').default

/** @type {import('@sveltejs/kit').Config} */
module.exports = {
    // Consult https://github.com/sveltejs/svelte-preprocess
    // for more information about preprocessors
    preprocess: sveltePreprocess(),         
    kit: {
        // By default, `npm run build` will create a standard Node app.
        // You can create optimized builds for different platforms by
        // specifying a different adapter
        adapter: node(),

        // hydrate the 

element in src/app.html target: '#svelte', vite: { ssr: { noExternal: Object.keys(pkg.dependencies || {}) }, plugins: [ WindiCSS(), ] } } };

Very basic stuff, import the plugin and add it to the vite plugins section.
Because the Windi CSS plugin is written as ES Module (ESM) and this file is a Common JS module (CJS), I need to add the ".default" to make it work.

Enable Windi CSS

Open the src/routes/$layout.svelte file and add this import:


Enable Developer Tools integration (optional)

Sometimes I like to tinker in the developer tools of the browser while prototyping. This can be done with this optional import.




By putting the import('virtual:windi-devtools') into the onMount callback, we delay the loading when the client is running in a real browser environment and not while server-side rendering.

Add Tailwind Plugins / Config

I need to add some settings, so I use my plain old tailwind config file. There are two important details:

  1. The file must be named tailwind.config.cjs (not .js)
  2. If you need plugins, import them from windicss/plugin
    Here is my example config:
// tailwind.config.cjs

module.exports = {
    dark: 'class',
    plugins: [
        require('windicss/plugin/forms'),
        require('windicss/plugin/aspect-ratio'),
        require('windicss/plugin/line-clamp'),
        require('windicss/plugin/filters'),
        require('windicss/plugin/scroll-snap'),     
    ],
}

Done. Really? Yes!
We have all set up to use what Tailwind offers and much more. Check out the Windi CSS documentation for the amazing details.
I use VS Code as an editor and love the Windi CSS plugin, check it out: WindiCSS IntelliSense

Recap

This is everything I had to do. Imho Windi CSS has some very nice advantages over plain Tailwindcss (even the @tailwindcss/jit).
If you have some questions or inputs drop a comment.
Build some amazing web applications!

Apr 09 2021
Apr 09

The Webform module is one of Drupal’s top modules, and it is included in one out of every four Drupal websites. Another way to look at this stat is 1 out of every 4 Drupal-related pitches, proposals, or project specification includes the Webform module. The success of those websites, the success of those projects all depend on the Webform module. So one has to ask: what’s the worth of ensuring that those websites and projects are up, running, and succeeding? My contributions have to be viewed as an integral part of that development, maintenance, and success.

Apr 09 2021
Apr 09

The past year has been a busy one for the Drupal Community Working Group (CWG), as we created a new "Community Health Team" and saw the stepping down of the last original member of the Conflict Resolution Team, George DeMet. As the CWG enters its 8th year, we feel it is our duty to continue to pursue our mission to "foster a friendly and welcoming community for the Drupal project and to uphold the Drupal Code of Conduct". With this guiding principle, we have been focusing on both proactive and reactive tasks to help us achieve this goal. 

This annual report will serve as a summary of what we've accomplished over the past year, as well as a discussion of some of our goals for the near future.

Community Health Team

The Community Working Group was expanded during the first half of 2020 with the creation of the Community Health Team. The mission of this new team is to focus on proactive community health tasks including workshops and knowledge transfer. With the help of Tara King, the CWG membership coordinator, we structured the team into several groups. Although team members may do work across multiple groups, each of these groups is designed to, but not limited to, focus on a specific area:

  • Community Event Support - provide resources and support related to the Code of Conduct for Drupal events.
  • Community Health - provide opportunities to educate and train community members to be more effective contributors.
  • Membership - to help identify and recruit community members for the CWG. 
  • Ambassadors - provide expertise and advice related to geographic, cultural, and other differences both inside and outside the Drupal community.

Community Health Team members are not privy to Code of Conduct incident reports; however they must adhere to the CWG Code of Ethics.

Once the team was created and volunteers were found for the majority of the roles, we began having monthly meetings during the second half of 2020. The team has already completed a number of tasks including:

  • Initial work on a Drupal Code of Conduct update.
  • Documentation of CWG roles.
  • Development of a group of community health representatives from other open source communities.
  • Ongoing Code of Conduct contact workshops.
  • Updates to the Drupal event Code of Conduct templates and playbook.
  • Ongoing Mental Health First Aid workshops for community members.
  • Blog posts related to community health.
  • "Nudges" for Drupal Slack Workspace and issue queues.

Other, long term goals for the Community Health Team include providing an on-ramp for the Conflict Resolution Team and identifying and presenting additional community-health-related workshops for the community, 

Conflict Resolution Team

After six years on the Conflict Resolution team, including several years as its chair, George DeMet retired from the team at the end of 2020. We cannot understate how much of an impact George has had on the CWG and the Drupal community, often working behind the scenes. We are fortunate that George has agreed to stay on as a member of the Community Health Team where he will be focusing on updating the Drupal Code of Conduct. 

During 2020, in addition to the creation of the Community Health Team, the Conflict Resolution Team continued to work on on-going and new Code of Conduct related issues. During our weekly meetings, we generally work on three types of tasks:

  • Internal business - examples include recruitment, public blog posts and presentations, Aaron Winborn Award, event organizer requests.
  • External, old business - ongoing conflict resolution tasks normally brought to us from community members.
  • External, new business - new conflict resolution tasks, normally brought to us from community members.

While some conflict resolution tasks can be resolved quickly (a few days), we normally have several long-term, on-going issues that can take anywhere from weeks to months to resolve. Most of the long-term issues include ongoing personality conflicts within the community, but we also routinely work with community members who had previously had their community privileges limited on plans and tasks to have those privileges restored (see our Balancing Accountability and Compassion in the Drupal Community blog post).

What types of conflict resolution issues do we work on?

We decided to perform a quantitative analysis of the number and types of conflict resolution issues we work on, comparing data from 2019 with 2020. Our methodology allowed us to assign one or two of the following categories to each new issue we received during 2019 and 2020:

  • Social media conflict
  • Issue queue conflict
  • Drupal Slack workspace conflict
  • In-person Drupal event conflict
  • Virtual Drupal event conflict
  • Not CWG domain
  • Other - examples include content issues on Drupal.org, issues related to local Drupal communities (but not directly related to an event), interpersonal issues occurring in areas not covered by any of the other categories.

In terms of overall number of incidents, while 2019 had 35 total new reported incidents to the CWG, 2020 has slightly less than half of that, with 17 new reported incidents. 

  • While the number of incidents occurring at in-person Drupal events dropped from six in 2019 to none in 2020, this doesn't account for the entire reduction of total incidents between 2019 and 2020. We also saw fewer social media and Drupal Slack workspace conflicts, but the biggest drop was in the "Other" category, which saw a decrease from ten incidents in 2019 to just two in 2020. 
  • Obviously, the drop in in-person incident reports is directly related to the pandemic.
  • What else can we attribute the dramatic drop in incident reports to? We hope that the formation of the Community Health Team is having some effect, but we're not so naive to attribute the entire decrease to its creation and actions during 2020. 

2019

2020

Total number of new reported issues

35

17

Social media conflict

7

1

Issue queue conflict

9

9

Drupal Slack workspace conflict

5

1

In-person Drupal event conflict

6

0

Virtual Drupal event conflict

0

2

Not CWG domain

4

3

Other

10

2

Looking forward

Conflict resolution team membership

One of the primary goals of the conflict resolution team in the first part of 2020 was expanding the size of the team. With the recent departure of George DeMet and the decrease in our workload (thanks to fewer incident reports and the amazing work of the Community Health Team), we decided this was a good time to recruit new team members. 

We had six amazing community members approach us about joining the team, and will be inviting a new member(s) to the team in the next few weeks. One of the main goals of the Community Health team was to provide an on-ramp to the Conflict Resolution Team. Those community members who were not extended an offer to join the Conflict Resolution Team will be asked to join the Community Health Team in a capacity of their choosing, if they haven’t joined already.

As part of the process of having new members join the team, we implemented (and are in the process of documenting) a new on-boarding process, where new team members are considered "trial members" for a maximum of 5 months. During this period, new members will mainly shadow the team and have limited access to historical conflict resolution reports. At the conclusion of the trial period new members will either become regular members or be asked to leave the team. As is prescribed by our charter, all trial members must be approved by the CWG Review Panel

Community Health Team

Now that our Community Health Team is a year old and has some experience under its belt, we have high hopes that they will continue to be a force for good in the community. Our plans for the next year include finding and presenting additional workshops, completing the aforementioned Drupal Code of Conduct update, and assisting with the expansion of the yet-to-have-a-good-name group of community health volunteers from various open source communities.

Apr 09 2021
Apr 09

The Webform module is one of Drupal’s top modules, and it is included in one out of every four Drupal websites. Another way to look at this stat is 1 out of every 4 Drupal-related pitches, proposals, or project specification includes the Webform module. The success of those websites, the success of those projects all depend on the Webform module. So one has to ask: what’s the worth of ensuring that those websites and projects are up, running, and succeeding? My contributions have to be viewed as an integral part of that development, maintenance, and success.

Apr 09 2021
hw
Apr 09

Today’s post is going to be a quick one; not because it is an easy topic but because a lot has been said about it already. Today, I want to share my thoughts on decoupling Drupal; thoughts that are mainly a mix of borrowed thoughts from several places. I will try to link where I can but I can’t separate my thoughts from borrowed ones now. Anyway, by the end of the post, you might have read a lot of things you already knew and hopefully, one or two new things about Decoupling Drupal.

Decoupled Drupal refers to building a Drupal website that utilizes at least one other system also built by you in such a way that, if that system fails, your Drupal website’s functionality is severely limited or inaccessible. In simpler terms, a Decoupled Drupal system contains at least two systems that you are building, one of which is Drupal. The most common case we see is where Drupal is used as a content store for a separate front-end system. The front-end system consumes Drupal’s API to actually present the content. There are many other combinations possible as well. You could have another content store and use Drupal as the front-end. Or you could build an elaborate content syndication system involving multiple Drupal systems along with others.

Organization Structure’s impact on Decoupled Drupal

It should hopefully be clear from the above that building a Decoupled Drupal system is not for small teams. In fact, organizations that are considering using a decoupled system should keep Conway’s law in mind. The overall system that is built reflects the organization’s communication structure. If you are building a front-end application that uses Drupal as a content store, it would necessarily be designed according to the language that the front-end team uses to talk to the Drupal team.

The issue at hand is more subtle than is apparent. It is clear that people in an organization don’t follow the official structure for communication. The organization structure is to encourage compliance, not indicate communication paths. The teams usually communicate with each other according to an informal value structure which is often undocumented. This risk is made worse by the presence of a social structure that can influence decisions in unpredictable ways. Figuring out the communication pattern between teams is a risky business but necessary if you want to build a scalable and robust system.

Why you shouldn’t decouple Drupal?

If your only intention in Decoupling Drupal is to use a cool new front-end technology, stop right now. You will lose a lot more in value than you might get in bragging rights. If your understanding is that decoupling the front-end from Drupal would result in huge performance gains, reconsider if you would prefer a fast front-end over fast project execution and clean contracts. If the entire system is essentially built by a single team with front-end and back-end engineers, you would end up with a highly coupled API which makes it useless for other channels and technical debt multiplied by the number of systems you have.

Remember Conway’s law here. Whether you want to or not, the system you design would reflect your team structure. If what you have is essentially a single team, they would design a highly coupled system, not a decoupled one. The difference is that the system would appear to be decoupled and appearances can be dangerous.

Why you should decouple Drupal?

Let’s look at Conway’s law again. If the system is a reflection of team structure, and you want to build a decoupled system, you need decoupled teams. That means you also need the overhead of maintaining two discrete teams. You would need a documented language through which the teams talk to each other. And this language can’t be the internal language used within the team. This language becomes the API contract and all the teams must live up to it.

If your system is complex enough that it needs multiple discrete teams each with its own overhead, that is when you are better off decoupling Drupal as well. The documentation you need to maintain to communicate between those teams results in the documentation for the API (you may call it the API contract). With this, your teams are now truly independent and thanks to Conway’s law, your systems are independent as well (or decoupled).

Successful Decoupled projects

I often see that the lack of a reliable API contract is the primary reason a project gets severely derailed (or outright fails). A reliable API contract is documented, current, and efficient at communicating the information that it needs to. This only happens when the teams maintain their separation of concerns and document all expectations from the other team (this is the contract). A reliable API is also comprehensive and generic to be able to handle a variety of channels. In other words, a reliable API encourages the separation of concerns.

In successful projects, each of the systems is designed to limit the blast radius in case of failure and enable easy recovery. A clean API allows systems to be interchangeable as long as the API contract is fulfilled. Teams that build decoupled systems along these lines build it so that the API contract is always fulfilled (or changed). And this process leads to independent teams and systems that work well.

Apr 08 2021
Apr 08

Our Diamond Sponsors

Acquia logo     Pantheon logo     Platform.sh logo

Drop into DrupalCon when it works for you 

Facing work deadlines? Competing priorities that won’t allow you to commit your entire day to a conference? We understand! DrupalCon 2021 is built with flexibility in mind. Each day will streamline 4 hours of live content, and the virtual setting will allow you to attend the sessions most relevant to you. Connect with others via chat, 1:1 networking, small group discussions, the hallway track, and social events. 

What’s more - DrupalCon participants will have exclusive access to the presentation recordings until the end of May! If you haven’t yet confirmed your participation, today is the perfect time to register for DrupalCon. It’s the best $245 investment you can make to advance your Drupal knowledge and connections.

Show your support through individual sponsorship

You can also help extend access to DrupalCon to others by becoming an individual sponsor. Your $400 donation includes registration for you to connect with the community at DrupalCon, learn from others, share your knowledge, and shape the future of Drupal, while also helping to remove financial barriers for others who would benefit from participating in DrupalCon.

As an individual sponsor, you’ll receive:

  • Recognition on DrupalCon’s Event Sponsors webpage
  • A badge that can be displayed on your Drupal.org profile and on social media
  • Recognition during DrupalCon
  • Community goodwill and #DrupalThanks for your support of Drupal

Thank you to our DrupalCon sponsors 

DrupalCon is an important gathering for our community and also serves as the primary source of funding for the Drupal Association. We are currently at 95% of our sponsorship budget, and your support can help us reach our goal! 

There are limited exhibition and branding opportunities still available! Don’t have the time to run a booth? Sponsor Women in Drupal or Trivia for great exposure and minimum effort! Contact [email protected] for more information.</span>

Thank you to the Individual Sponsors for your generosity and support!

  • Abdul Farooqui (abdulFarooqui), CTO, SymSoft Solutions, LLC
  • Benji Fisher (benjifisher), Fruition
  • Claudiu Cristea (claudiucristea), Drupal Consultant, Webikon SRL
  • Darren Oh (darren-oh), Drupal Engineer, Cognizant Technology Solutions
  • Duran Goodyear (alphex), Owner, Alphex Information Solutions
  • Elizabeth Krukosky (drupalwench), CEO & Developer, Cool Fire Inc
  • James Gilliland (neclimdul), Enterprise Architect, APQC
  • John Taylor (johndtaylor), Freelance
  • Joseph Krukosky (joekrukosky) CTO & Developer, Cool Fire Inc
  • Matt Schreiber (cws_matt), Developer, Complete Web Solutions
  • Nic Rodgers (nicrodgers), Head Tag Limited
  • Radzi Ismail, Manager, CREATIVE SIDE SDN. BHD.

  • Rich Gerdes (richgerdes), Senior Developer, Unleashed Technologies
  • Roman Paska (taran2l), Head of Web Development, Lemberg Solutions
  • Roy Vikovych, Business Development Manager, Lemberg Solutions
  • Ullrich Neiss (slowflyer), CEO, crowd-creation GmbH

Our Platinum Sponsors

                         
                        
          

Thank you to our newest sponsors supporting DrupalCon North America 2021!

Have a question?


We’re here for you. Find answers to common DrupalCon questions in our FAQ.
Apr 08 2021
Apr 08

Relaunch blog of Unity.com with headless Drupal 8, Next.js

Dr. Christoph Breidert,  Managing Director & Co-Founder of 1xINTERNET and  Lars Linnet from Unity Technologies will join forces during this session.  After many years of successfully running an interactive blog in 9 different languages using Wordpress, Unity decided to relaunch the blog using headless Drupal and Next.js.

The goal was to build a state of the art blogging system that provides a state of the art editorial experience for the team and contributors of the blog and to decouple the frontend completely from the backend.

The goal was achieved by exposing all necessary content such as page types, paragraphs, menus, media, meta tags, redirects, etc. using GraphQL, and building a fast and beautiful frontend with Next.js.

The development was done with a mixed team of frontend and backend developers working closely together.

Some of the most notable highlights of the implementation are:

  •  Flexible content model using paragraphs
  • Support of meta tags, redirects, and media
  • Optimal image cropping and resizing by combining Drupal and Next.js
  • State of the art editorial experience with workflows and translation management
  • Migration from unstructured Wordpress data into a highly structured data model

In the session Christoph and Lars will showcase the final project.  

Make sure not to miss out on this session.

Apr 08 2021
Apr 08

Within the product lifecycle, individual software versions repeatedly reach their end-of-life (EOL). After this point, the previous version is no longer supported in favor of a newer version - this is quite normal and usual for a technical product.

Drupal is also due for an end-of-life this year: Support for Drupal 8 will be discontinued on Nov. 2, 2021. Now, many Drupal 8 site owners are under pressure to upgrade to Drupal 9 in time to ensure a risk-free and secure Drupal environment. Since Drupal 8 will not be further supported after the EOL, we can therefore only strongly advise all Drupal 8 site owners to upgrade the system to Drupal 9 in time.

Ending Signage

From Drupal 8 to 9 - The upgrade has to be done

That Drupal 8 is hitting its EOL so soon is due to the following: Drupal 8 uses Symfony 3, which will no longer be developed as of November this year. The newer Drupal 9 only uses the successor Symfony 4 as PHP framework, library and its modules.

With the EOL, no more security updates will be made available for websites that use Drupal 8. So, in essence, there is no viable alternative for these sites other than to upgrade to Drupal 9.

What Drupal 9 brings with it

Upgrading from Drupal 8 to Drupal 9 is a much smaller jump than the previous upgrade from Drupal 7 to Drupal 8. For the first time in Drupal's history, the new Drupal version builds directly on a previous version. The upgrade from Drupal 8 to Drupal 9 is therefore much more comparable to an update from, say, Drupal 8.6 to Drupal 8.7.

Drupal 9 is a further developed and improved version of Drupal 8. The new version offers a whole range of advantages. In general, the most relevant advantages can be summarized in the following three points:

  • Long Term Support
    Drupal 9 is supported until at least the end of 2023, which provides site owners with long-term security.

  • "Cleaned up" Drupal version
    The program code has been cleaned up and tidied up in many places to make the Drupal core clearer.

  • Many modules and new features
    Many existing modules are already available for Drupal 9 and new modules / features are developed only for Drupal 9.


How we upgrade our customer projects

For the upcoming upgrades to Drupal 9 in the coming weeks and months, we have worked out a simple process by which we proceed:

  1. In the first step, we analyze the current instance. Installed modules, themes and project-specific code are checked for compatibility with Drupal 9.

  2. In the second step we perform the update of modules, Drupal core, theme files and project specific code. If necessary, we create patches for "old" modules so that they continue to work on the upgraded Drupal 9 site if they are not (yet) officially ready for Drupal 9.

  3. In the third step, our customers can test the functionality of the site in a staging environment before everything is rolled out to the production environment.


Also important and good to know: From an editorial point of view, there is no effort involved in upgrading to Drupal 9 and everything remains as it was. For example, the familiar workflows remain in place and no existing content needs to be migrated.

Apr 08 2021
hw
Apr 08

I missed joining the DrupalNYC meetup today. Well, I almost missed it but I was able to catch the last 10 minutes or so. That got me thinking about events and that’s the topic for today–Drupal events and their impact on my life. I travelled extensively for 4-5 years before the pandemic restrictions were put in place and since then, I have attended events around the world while sitting in my chair. These travels and events are responsible for my learnings and my professional (and personal) growth. And these are the perspectives that have given me the privilege that I enjoy.

Before I go further, I should thank two organizations that have made this possible for me. The first is my employer, Axelerant, which cares deeply about the community and us being a part of that. They are the reason I was able to contribute to Drupal the way I did and could travel to a lot of these events. The second organization I want to thank is the Drupal Association who organize DrupalCons and made it possible for me to attend some of them.

Why have and attend events?

Software is not written in a vacuum. Any software engineer who has grown with years of experience realizes that the code is a means to an end. It is only a means to an end. You may have written beautiful code; code that has the power to move the souls of a thousand programmers and make poets weep, but if that code is not solving a person’s need, it has no reason to exist.

Therefore, we can say that Drupal has no reason to exist were it not for the people it impacts. Drupal events bring these people together. They enable people to collaborate and solve challenges. They enable diverse perspectives which is the lifeblood of innovation. And they enable broad learning opportunities you would never have sitting in front of a screen staring at a block of code. In other words, these events give a reason for you to keep building Drupal. These events and these people give you a reason to grow.

Why travel?

Not lately, but DrupalCons usually mean travel and everything that comes along with it (airports!) I strongly believe travel is a strong influencer of success. Travelling, by definition, puts you in touch with other people. People whom you have never met and with whom you don’t identify at all. It is these people that give you the perspective you probably need to solve a problem. I have often been on calls at work where we can solve a problem quickly and easily just by bringing in someone from outside the project. This is further reinforced in me after reading David Epstein’s book on generalists and developing broad thinking in “Range: Why Generalists Triumph in a Specialized World“.

In other words, the same reason why events help you grow, travel does too. It just appears to work differently. I have travelled to Australia, United States, Spain, United Kingdom, Switzerland, New Zealand and transited through many other countries. I travelled to these places to attend DrupalCons or other Drupal events and I learned just as much, if not more, from my travels as I learnt at the events.

Online events

True, we cannot travel with restrictions now and that has meant some events getting cancelled and many happening online. Does it give the same benefits as an in-person event. The short answer is “No”. No, it does not give the same benefits but it gives different benefits. Everything I said that gave you different perspectives and helped you grow, all of that is now instantly available to you. You don’t have to travel in long flights and layovers and deal with airport security. A click can take you to any event in the world. You don’t even have to dress up; although people will appreciate it if you do when you turn on the camera.

All the diversity, perspectives, learnings, and more can now be available instantly at a much lesser cost to you and to the environment. Online events may not be a replacement for in-person events, but they have their place and the world now realizes how powerful and effective they can be. I have heard of people who finally attended their first DrupalCon because it was online. Programmers, of all people, should realize how technology can bring people together.

The fatigue of online events

No one pretends that events, online or in-person, are going to be smooth and free of frustration. Online events may be subject to Zoom fatigue in the same way that in-person events are subject to jetlag. These are real problems and like we have learned how to deal with jetlag, we should learn how to deal with online fatigue. It’s our first year and we will only get better.

How do we learn at events?

The answer is simple. No, really. It is very simple and you may think why did I even write a section heading to say this. You learn at events by talking to people. That’s the trick. That’s the magic. Talk to everyone you can. I can identify with the classical introverted programmer who is happy with a screen in front of their face. Talking is a lot of work. More importantly, talking is risky. It makes you vulnerable.

But that exactly is what makes you learn and grow. You can’t expect to gain perspectives without talking to people who could provide that.

Okay, so how do I talk to people?

If talking seems like a lot of work, start by listening. If going to someone and talking to them one-on-one is intimidating, join a group conversation and listen in. Contribute what you can when you can. The Drupal community is awesome and welcoming and I know that they are not likely to make you feel unwelcome if you are just joining a group to listen in.

Online events make it easier to hide and keep our heads down. Resist that temptation and hit the Unmute button to ask a question or just even thank a speaker. Most online conferencing solutions have a networking feature. Use that to pair up with someone random. It’s not as good as running into someone in the hallway but it is good enough.

But, what do I talk about?

That’s a fair question and I think a lot about that. I feel safe in saying that I start by listening. A couple of sentences in, I realize that I do have something to offer. At the time, I don’t worry about how valuable it would be but I share that anyway and I have usually found that the other person finds some value in it.

It is no secret that a lot of us suffer from imposter syndrome. And it is not enough to just tell myself to think that I would overcome that feeling just by speaking about what I know. That is why I listen and offer what I can. If I don’t feel like offering anything, that’s fine. Sometimes, it is enough to just say hello and move on. In fact, this has happened several times to me. I would speak with certain people frequently in issue queues but when we meet, it is a quick hello and we move on, fully knowing that we may not get another chance to meet in that event. And that’s okay.

The awesome Drupal community

Everything I said above is from my own experience dealing with my inhibitions and insecurities in interacting with these celebrated folks. I have many stories of how some of the most popular contributors made me feel not just welcome but special when I met them for the first time. These are events that have happened years ago and I still recollect them vividly. I have shared these stories often both while speaking and in writing. And I am not talking about one or two such people. Almost everyone I can think of has been kind and welcoming and speak in such a way where you feel you are the special one. I can say that because I did feel special talking with them. In those cases, all I had to do was walk in the hallway where they happened to be and just say “Hello”.

Almost all Drupal events are online now and that is a great opportunity for you to get started. The most notable one right now is the DrupalCon North America happening next week. Consider attending that. If you’re attending, consider speaking up and saying hello. And if you are a veteran, consider welcoming new people into the group and make them feel special. If you can’t make it to DrupalCon, there are dozens of other events in various regions throughout the world. Find the one that interests you and go there. You don’t even have to fasten your seatbelt to get there.

Apr 08 2021
Apr 08


Image credit: Aaron Deutsch

If you use Drupal at all, you've probably already heard that 2021 is Drupal's 20th anniversary! Pretty cool. :) Check out wikipedia to see Drupal's initial release by Dries Buytaert was January 15, 2001.

In honor of Drupal's 20th year, DrupalFest is this month which is built around the popular DrupalCon North America event. Due to the pandemic, DrupalCon NA is online again this year, but this allows for a more unique content and contribution event model. The events are spread out throughout the month of April to allow for more participation and better integration into everyone's schedule. Hope to "see you" next week at DrupalCon or at one of the Drupal summits!

Speaking of summits, yesterday was the Drupal Community Summit which was fantastic. The big silver lining to virtual events is people from all over the world can join. We had folks from many different countries at the Community Summit including Scotland, India, Taiwan, Canada, Serbia, Germany, Suriname, United States, Japan, South Africa, Brazil, Switzerland, Nigeria, England, Pakistan, and more. We thought it would be cool to map out the participants.

Big thanks to the community organizers (Alanna Burke, AmyJune Hineline, Andrew Olson, and Miro Michalicka) and the Drupal Association organizers (Karlyanna Kopra and Ann Weller) for such a well-run Community Summit. And, special thanks to Rachel Lawson for co-facilitating a roundtable on local communities and speaker compensation. Last by not least, thanks to the community members who participated, especially anyone *new* to the community. It was a lot of fun!

As part of DrupalFest month, I challenged myself to do "A Drupal A Day". Meaning, that each day in April, I'll do something, no matter how small, related to Drupal. I was happy to see that at least two other community members took up the challenge themselves. Hussain Abbas is writing a blog post every day, and Baddý Breidert has been doing a variety of things including working on a Decoupled Menu Initiative keynote. You can follow along by watching the #ADrupalADay tag on Twitter. And please feel free to join us! :)

To help get you inspired, here are some things that you could do during DrupalFest and beyond. Have some more ideas? Send me a message on Twitter, and I'll add them to this list.

Enjoy April's DrupalFest

This month is packed full of great events you won't want to miss. And, you can also add your own events for even more DrupalFest fun!

Contribute to Drupal

Whether it's Drupal core or a contributed module, theme, or distribution, there's always something to work on. And remember, you don't have to know how to code to help!

Do Something Creative

Tech doesn't just have to be a bunch of code. Let's have some creative Drupaly fun!

Sponsor Drupal Work

Money makes the world go 'round whether we like it or not. Your generosity is always needed! There are many ways to sponsor Drupal work:

Promote Drupal

Shout Drupal from the rooftops using your own social media platforms, and amplify organizations and people in the Drupal community who are doing the ongoing work of improving Drupal.

Making Tech More Inclusive

While you are here, let's stop a moment to think about what we can do to help improve diversity, inclusivity, and equity in tech. Here are but a handful of organizations doing important work.

More Contribution Resources

More Ideas from the Drupal Community


Image credit: Aaron Deutsch

Apologies, my old website is still on Drupal 6 and looks particularly bad on mobile. I have started playing with the migration to Drupal 9 and hope to be done fairly "soon". :) Please ignore the cobbler's old shoes for now, thanks!

Apr 07 2021
Apr 07

Lynette has been part of the Drupal community since Drupalcon Brussels in 2006. She comes from a technical support background, from front-line to developer liaison, giving her a strong understanding of the user experience. She took the next step by writing the majority of Drupal's Building Blocks, focused on some of the most popular Drupal modules at the time. From there, she moved on to working as a professional technical writer, spending seven years at Acquia, working with nearly every product offering. As a writer, her mantra is "Make your documentation so good your users never need to call you."

Lynette lives in San Jose, California where she is a knitter, occasionally a brewer, a newly-minted 3D printing enthusiast, and has too many other hobbies. She also homeschools her two children, and has three house cats, two porch cats, and two rabbits.

Apr 07 2021
Apr 07

Read our roadmap to understand how this work falls into priorities set by the Drupal Association with direction and collaboration from the Board and community. You can also review the Drupal project roadmap.

Drupal.org UpdatesDrupal contribution

Drupal's 20th Birthday Year

As we close out the first quarter of 2021, we continue the celebration of 20 years of Drupal with #DrupalFest and #DrupalCon!

#DrupalFest is a month-long celebration of all things Drupal, taking place online all around the world. DrupalFest lasts throughout the month of April. Most events are free, and we encourage everyone to attend, and even submit your own!

DrupalCon is right around the corner from April 12-16, happening online. This year's DrupalCon reflects a renewed focus on the strategic initiatives that drive innovation in Drupal. Each day has a half day of live programming for and then a half day of contribution, and all personas are welcome! Join us!

Increased focus on Strategic Initiatives

Speaking of strategic initiatives, the current primary initiatives being highlighted at DrupalCon and beyond are: 

  • Decoupled Menus - This initiative focuses on creating standardized tools and libraries for decoupled Drupal, starting with the menu system. This is the first step in making JavaScript front-ends a central part of the Drupal project. 
  • Easy out of the Box - This mega-initiative combines the efforts of Layout Builder, Media, and Claro to help empower content editors in Drupal to take advantage of the best that Drupal can offer.
  • Automatic Updates - This initiative is focused on the #1 most requested feature in Drupal: automatic updates. The initiative is building a robust and secure system for automatically updating Drupal, starting with security and patch releases.
  • Drupal 10 Readiness - The Drupal innovation train keeps rolling! The Drupal 10 Readiness initiative is rallying the community around what we need to reach our Drupal 10 release date, and helping site owners ensure they're ready for the upgrade when the time comes.

In addition to the content at DrupalCon, you can find ways to get involved in any of these initiatives by checking out the Drupal Strategic Initiative section on Drupal.org.

Decoupled Menu Initiative Support

General projects are a new content type on Drupal.org for code that does not fall into the neat categories of module, theme, or distribution. Instead, these can cover things like JavaScript Components, Drush Extensions, Install Profiles, Libraries, etc.

This is the first step in making Drupal a project greater than just PHP. This capability leans into Drupal's future in Decoupled applications, and in digital experiences beyond the web browser. 

Since the launch of general projects as a new content type on Drupal.org the Decoupled Menu Initiative has made great progress on creating standardized endpoints/libraries for decoupled Drupal solutions.

At DrupalCon North America the Decoupled Menus initiative leads invite you to a hackathon to begin to create applications for this work.

The rapid movement on this initiative shows how quickly the Drupal community can pivot into more robust and standardized Decoupled implementations, and furthers Drupal's lead in the marketplace.

Easy Out of the Box Support

For the Easy Out of the Box team, the Drupal Association has been focused on connecting the initiative leads to the Drupal Contribution Mentoring team, so that at DrupalCon there will be a variety of onramps to help new contributors support this work.

Easy Out of the Box is effectively three initiatives in one, focused on Layouts, Media, and the Claro administrative theme, so people with interest in any of those areas are more than welcome.

AutoUpdates Initiative Cross-Project Collaboration

The Drupal Association Engineering team continues its close collaboration with the AutoUpdates initiative team. Because AutoUpdates requires a server side component that will live on Drupal.org infrastructure, the engineering team needs to be closely involved.

This initiative has also had a heavy focus on cross-project collaboration - with three CMS partners in the PHP ecosystem collaborating together on the basic principles of supporting securely signed update packages.

Drupal    Typo3   Joomla

We're also collaborating with other partners, such as the Cloud Native Computing Foundations 'TUF'(The Update Framework) team, and the team behind Composer. 

Composer     Cloud Native Computing Foundation    The Update Framework

At DrupalCon North America the TUF team will be presenting about securing software package delivery - a topic that is sure to be interesting for all.

Drupal 10 Readiness Support

Drupal 10 is slated for release in June of 2022, which is only a little bit more than a year away. Fortunately, Drupal 10 follows the continuous innovation model of Drupal development that was so successful in the transition from Drupal 8 to Drupal 9. In essence, so long as site owners are up to date with the latest version of Drupal 9 they should be able to make the jump very easily. The only area of concern is deprecated code.

To that end, the Drupal Association engineering team collaborated with Gábor Hotjsy to set up automate code deprecation checking using the DrupalCI infrastructure. This allows the team to understand the most used instances of deprecated code, so that contributed module maintainers can be made aware of the need to update, and so that the Drupal Rector team(supported by Palantir.net) can begin creating automatic deprecation patches.

GitLab Merge Request Updates

Last year, Drupal.org migrated our community contribution tools to GitLab, by integrating the existing Drupal.org issue queues with GitLab's merge request functionality.

Thanks to these improvements, the complete contribution lifecycle can be completed entirely in the browser. As a contributor to Drupal you no longer need to use command line git, install a local development environment, or use a local IDE in order to make your contributions.

Since the initial launch, we've received feedback from many people in the community about improvements to usability with the Drupal.org issue queue integration. Looking at the child issues of this issue, we can see rapid usability improvements that have sped the pace of contribution.

More recently, we worked with our partners at Tugboat.qa to release live deployment previews of your code changes - first for Drupal Core, but now available for contributed projects on Drupal.org as well. This means that even reviewing visual changes or seeing your code deployed to a site can all be done without leaving your browser. This is a huge boon to all contributors, but especially to usability and accessibility experts who can much more easily view the impact of changes across issues.

Major improvements to Community events

In collaboration with the Events Organizers Working Group, the Drupal Association has updated the Drupal.org Community Events section. This new section represents a central repository for all of the events taking place across the Drupal Community, and will ultimately be the replacement for Groups.Drupal.org.

This section allows anyone in the community to submit their events, whether online or in-person, and provides a variety of views to help people find events they'd like to attend. Events can be filtered by type(con, camp, meetup, training, etc); proposed events can be submitted to help avoid scheduling conflicts; and calls for content/speakers can be promoted.

A feed of these events is made available for 3rd party tools built by the community, which is already being used to feed Drupical.com.

Local events are the heart of our community, so we hope that you'll help us by submitting your local events to this new tool!

Documentation updates

Led by community volunteer u/jhodgdon, Drupal.org's documentation tools have seen a variety of updates. In particular, the Drupal contributor guide is now much more complete, helping folks who are new to contribution in Drupal find a place to fit in and get started.

We've also deployed improvements that make it easier to understand whether the documentation you're reading is up-to-date, and how to report problems if you find them.

If you're looking for somewhere to contribute - helping to update documentation is a wonderful place to start!

Coming soon: Discover Drupal Portal

Coming up at DrupalCon is the announcement of a new program: Discover Drupal. This program is part of the Drupal Association's talent and education initiatives, and represents the Drupal Association's commitment to growing the Drupal talent pool and increasing diversity in our community.

With the official announcement just around the corner we won't spoil the details here, but very soon you'll be able to check out the new web portal for the Discover Drupal program and find out what it's all about.

Infrastructure Updates

Over the course of the last quarter the Drupal Association engineering team has provided a variety of feature updates for the Drupal project in terms of testing infrastructure: 

  • PHP8 Testing support - The Drupal Association provided PHP8 testing environments in DrupalCI, and so Drupal versions 9.1 and beyond are all fully PHP 8 compatible.Staying on the leading edge of compatibility gives Drupal the advantage of improved performance and security, and sets us up for success when it's time for Drupal 10.

  • Code Standards test for Drupal Core - Drupal Core tests now provide code standards testing results, saving a laborious manual step when reviewing core contributions.
  • GitLabCI/Pipelines - The Drupal Association has also enabled GitLabCI/Pipelines for these new general projects. This is a precursor to moving to GitLabCI for all Drupal CI uses. With direct maintainer control of the CI configuration for these projects, we can see automated workflows to support a wider variety of projects - allowing for more innovation. However, we need to be cognizant of cost controls as we open up this capability.

The year is off to a fast-paced, productive start and as always it is humbling and gratifying to see the great work that the community accomplishes with the tools the Drupal Association provides.

———

As always, we’d like to say thanks to all the volunteers who work with us, and to the Drupal Association Supporters, who make it possible for us to work on these projects. In particular, we want to thank: 

If you would like to support our work as an individual or an organization, consider becoming a member of the Drupal Association.
Follow us on Twitter for regular updates: @drupal_org, @drupal_infra

Apr 07 2021
Apr 07

Read our roadmap to understand how this work falls into priorities set by the Drupal Association with direction and collaboration from the Board and community. You can also review the Drupal project roadmap.

Drupal.org UpdatesDrupal contribution

Drupal's 20th Birthday Year

As we close out the first quarter of 2021, we continue the celebration of 20 years of Drupal with #DrupalFest and #DrupalCon!

#DrupalFest is a month-long celebration of all things Drupal, taking place online all around the world. DrupalFest lasts throughout the month of April. Most events are free, and we encourage everyone to attend, and even submit your own!

DrupalCon is right around the corner from April 12-16, happening online. This year's DrupalCon reflects a renewed focus on the strategic initiatives that drive innovation in Drupal. Each day has a half day of live programming for and then a half day of contribution, and all personas are welcome! Join us!

Increased focus on Strategic Initiatives

Speaking of strategic initiatives, the current primary initiatives being highlighted at DrupalCon and beyond are: 

  • Decoupled Menus - This initiative focuses on creating standardized tools and libraries for decoupled Drupal, starting with the menu system. This is the first step in making JavaScript front-ends a central part of the Drupal project. 
  • Easy out of the Box - This mega-initiative combines the efforts of Layout Builder, Media, and Claro to help empower content editors in Drupal to take advantage of the best that Drupal can offer.
  • Automatic Updates - This initiative is focused on the #1 most requested feature in Drupal: automatic updates. The initiative is building a robust and secure system for automatically updating Drupal, starting with security and patch releases.
  • Drupal 10 Readiness - The Drupal innovation train keeps rolling! The Drupal 10 Readiness initiative is rallying the community around what we need to reach our Drupal 10 release date, and helping site owners ensure they're ready for the upgrade when the time comes.

In addition to the content at DrupalCon, you can find ways to get involved in any of these initiatives by checking out the Drupal Strategic Initiative section on Drupal.org.

Decoupled Menu Initiative Support

General projects are a new content type on Drupal.org for code that does not fall into the neat categories of module, theme, or distribution. Instead, these can cover things like JavaScript Components, Drush Extensions, Install Profiles, Libraries, etc.

This is the first step in making Drupal a project greater than just PHP. This capability leans into Drupal's future in Decoupled applications, and in digital experiences beyond the web browser. 

Since the launch of general projects as a new content type on Drupal.org the Decoupled Menu Initiative has made great progress on creating standardized endpoints/libraries for decoupled Drupal solutions.

At DrupalCon North America the Decoupled Menus initiative leads invite you to a hackathon to begin to create applications for this work.

The rapid movement on this initiative shows how quickly the Drupal community can pivot into more robust and standardized Decoupled implementations, and furthers Drupal's lead in the marketplace.

Easy Out of the Box Support

For the Easy Out of the Box team, the Drupal Association has been focused on connecting the initiative leads to the Drupal Contribution Mentoring team, so that at DrupalCon there will be a variety of onramps to help new contributors support this work.

Easy Out of the Box is effectively three initiatives in one, focused on Layouts, Media, and the Claro administrative theme, so people with interest in any of those areas are more than welcome.

AutoUpdates Initiative Cross-Project Collaboration

The Drupal Association Engineering team continues its close collaboration with the AutoUpdates initiative team. Because AutoUpdates requires a server side component that will live on Drupal.org infrastructure, the engineering team needs to be closely involved.

This initiative has also had a heavy focus on cross-project collaboration - with three CMS partners in the PHP ecosystem collaborating together on the basic principles of supporting securely signed update packages.

Drupal    Typo3   Joomla

We're also collaborating with other partners, such as the Cloud Native Computing Foundations 'TUF'(The Update Framework) team, and the team behind Composer. 

Composer     Cloud Native Computing Foundation    The Update Framework

At DrupalCon North America the TUF team will be presenting about securing software package delivery - a topic that is sure to be interesting for all.

Drupal 10 Readiness Support

Drupal 10 is slated for release in June of 2022, which is only a little bit more than a year away. Fortunately, Drupal 10 follows the continuous innovation model of Drupal development that was so successful in the transition from Drupal 8 to Drupal 9. In essence, so long as site owners are up to date with the latest version of Drupal 9 they should be able to make the jump very easily. The only area of concern is deprecated code.

To that end, the Drupal Association engineering team collaborated with Gábor Hotjsy to set up automate code deprecation checking using the DrupalCI infrastructure. This allows the team to understand the most used instances of deprecated code, so that contributed module maintainers can be made aware of the need to update, and so that the Drupal Rector team(supported by Palantir.net) can begin creating automatic deprecation patches.

GitLab Merge Request Updates

Last year, Drupal.org migrated our community contribution tools to GitLab, by integrating the existing Drupal.org issue queues with GitLab's merge request functionality.

Thanks to these improvements, the complete contribution lifecycle can be completed entirely in the browser. As a contributor to Drupal you no longer need to use command line git, install a local development environment, or use a local IDE in order to make your contributions.

Since the initial launch, we've received feedback from many people in the community about improvements to usability with the Drupal.org issue queue integration. Looking at the child issues of this issue, we can see rapid usability improvements that have sped the pace of contribution.

More recently, we worked with our partners at Tugboat.qa to release live deployment previews of your code changes - first for Drupal Core, but now available for contributed projects on Drupal.org as well. This means that even reviewing visual changes or seeing your code deployed to a site can all be done without leaving your browser. This is a huge boon to all contributors, but especially to usability and accessibility experts who can much more easily view the impact of changes across issues.

Major improvements to Community events

In collaboration with the Events Organizers Working Group, the Drupal Association has updated the Drupal.org Community Events section. This new section represents a central repository for all of the events taking place across the Drupal Community, and will ultimately be the replacement for Groups.Drupal.org.

This section allows anyone in the community to submit their events, whether online or in-person, and provides a variety of views to help people find events they'd like to attend. Events can be filtered by type(con, camp, meetup, training, etc); proposed events can be submitted to help avoid scheduling conflicts; and calls for content/speakers can be promoted.

A feed of these events is made available for 3rd party tools built by the community, which is already being used to feed Drupical.com.

Local events are the heart of our community, so we hope that you'll help us by submitting your local events to this new tool!

Documentation updates

Led by community volunteer u/jhodgdon, Drupal.org's documentation tools have seen a variety of updates. In particular, the Drupal contributor guide is now much more complete, helping folks who are new to contribution in Drupal find a place to fit in and get started.

We've also deployed improvements that make it easier to understand whether the documentation you're reading is up-to-date, and how to report problems if you find them.

If you're looking for somewhere to contribute - helping to update documentation is a wonderful place to start!

Coming soon: Discover Drupal Portal

Coming up at DrupalCon is the announcement of a new program: Discover Drupal. This program is part of the Drupal Association's talent and education initiatives, and represents the Drupal Association's commitment to growing the Drupal talent pool and increasing diversity in our community.

With the official announcement just around the corner we won't spoil the details here, but very soon you'll be able to check out the new web portal for the Discover Drupal program and find out what it's all about.

Infrastructure Updates

Over the course of the last quarter the Drupal Association engineering team has provided a variety of feature updates for the Drupal project in terms of testing infrastructure: 

  • PHP8 Testing support - The Drupal Association provided PHP8 testing environments in DrupalCI, and so Drupal versions 9.1 and beyond are all fully PHP 8 compatible.Staying on the leading edge of compatibility gives Drupal the advantage of improved performance and security, and sets us up for success when it's time for Drupal 10.

  • Code Standards test for Drupal Core - Drupal Core tests now provide code standards testing results, saving a laborious manual step when reviewing core contributions.
  • GitLabCI/Pipelines - The Drupal Association has also enabled GitLabCI/Pipelines for these new general projects. This is a precursor to moving to GitLabCI for all Drupal CI uses. With direct maintainer control of the CI configuration for these projects, we can see automated workflows to support a wider variety of projects - allowing for more innovation. However, we need to be cognizant of cost controls as we open up this capability.

The year is off to a fast-paced, productive start and as always it is humbling and gratifying to see the great work that the community accomplishes with the tools the Drupal Association provides.

———

As always, we’d like to say thanks to all the volunteers who work with us, and to the Drupal Association Supporters, who make it possible for us to work on these projects. In particular, we want to thank: 

If you would like to support our work as an individual or an organization, consider becoming a member of the Drupal Association.
Follow us on Twitter for regular updates: @drupal_org, @drupal_infra

Apr 07 2021
Apr 07

How we jumped head-first into decoupling Drupal with a React-based design system built for performance and brand consistency.

Our latest corporate initiative is decoupling our website, upgrading to Drupal 9 and achieving the holy grail of web development — a CMS-driven back end, with a modern, decoupled javascript front end using a component-based design system.

Here is a breakdown of the project so far:

It’s funny how things go. As a company, we’re constantly working in Drupal: building, planning, and helping to maintain various modules and websites for both our clients and the Drupal community. While the large majority of our clients and work is in the latest version of Drupal, our site is still running Drupal 7. Shame on us, right! Like many businesses out there, it’s easy to push aside the upgrade when our internal systems and staff are comfortably using the existing platform and everything is working like a well-oiled machine. Well, we finally got the buy-in we needed from our internal stakeholders and we were off to the races. But, we didn’t want just another Drupal website. We wanted to explore the “bleeding edge” and see if we can achieve the holy grail of web development — a CMS-driven back end, with a modern, decoupled javascript front end using a component-based design system. Go big or go home!

Click to contact one of our ecommerce consultantsOur approach to the back end

After a solid planning phase, we settled on an approach for the new site build and it was time to get going. We decided on Drupal (of course) for the back end since it’s our CMS of choice for many reasons and we could leverage all of the great work that has already been done with the JSON:API. However, not all of our needs were covered out-of-the-box.

Exploring API-first distributions

When we were first getting started, we spent some time looking at using ContentaCMS for our back end. It’s an API-first Drupal distribution that already contains most, if not all, of the modules we needed. We think ContentaCMS is an interesting tool that will stay on our radar for future projects, but ultimately we decided against it this time due to the number of extra modules that were unnecessary for our particular build. We ended up just starting with a fresh Drupal 9 install with only the modules we needed.

Decoupled menus

Another complication we came across focused around decoupled menus. Obviously, to build out a menu on the front end we needed to be able to get menu items. JSON:API Menu Items was installed and gave us a good starting point by exposing the menus in JSON:API. Next, we needed to get around the fact that JSON:API relies on UUID for content but menus use paths. Content also likes to have pretty URLs to use for navigation via path aliases. To display these path aliases from the front end and be able to retrieve the correct node, we need some way to resolve the path alias to its correct content. In comes the Decoupled Router module to solve the problem for us! This module provided the endpoints we needed.

Simplifying the JSON output

When you first install JSON:API, you get ALL of the data. While this is great, the JSON output relies on the naming convention of fields either set by Drupal or the developer(s) configuring the backend. Though we have control over how we name newly added fields, we don’t have that control over existing fields. For example, the User entity's “mail” field, which is intended to be the user’s email address, is not easy to understand without knowing what the data is within the field. For a better developer experience, we renamed fields as needed by creating EventSubscribers that tap into the JSON:API response build events. We also installed the OpenAPI module to give our developers a better high-level look at the available endpoints and their structure, opposed to looking at gross JSON output.

Our approach to the front end

With our back end sorted out, it’s time to get to the front end. When going decoupled, the front end suddenly becomes a whole lot more interesting than just a standard Drupal theme with Twig templates, SASS stylesheets and jQuery. We’re in a whole different realm now with new possibilities. We were 100% on board with having better integration between design and development, where the end result of the design was more than static assets and a 1-hour handoff. Here’s a breakdown of our front end approach.

A new strategy for consistency between design in development

In the past, creative exercises would provide static assets such as style guides to try and capture the design principles of a web property or brand. While this concept is rooted in good intentions, in practice, it never really worked well as a project evolved. It’s simply too difficult to keep design and development in sync in this way. For web development, it’s now understood that the code is a better source of truth, not a style guide, but we still need ways to involve our designers and have them contribute their knowledge of design and UX into the code that is being developed. After all, if you leave these decisions up to developers, you’re not going to end up in a good place (and most developers will readily agree with that sentiment). Luckily for us, applications like Figma, Sketch, and Adobe XD, are leading the way to bridge this gap. While this is still very new territory, there is a lot of exciting progress happening that is enabling the creation of robust design systems that act as a rulebook and single source of truth that is both easily updated, modular, and readily available for product application development.

After an internal study of available technologies for design, we settled on Figma for our design system creative work. Figma runs in either web or desktop applications and is a vector graphic editor and prototyping tool. The team developing it has done an incredible job pushing the envelope on how creative and development can work together. With Figma, we found it was possible to accomplish the following:

Extracting design tokens into our application

With our tokens living in Figma, we still needed a way to bring those static design token values into our development process. This is where Figmagic comes in. Figmagic is a nice tool for extracting design tokens and graphic assets out of Figma and into our application. Once set up, all we need to do in our local development environment is to run yarn figmagic. This connects to Figma and pulls down all of our defined tokens into an organized set of ready-to-use files. From there, we then simply import the file we need into our component and use the values as required. If a value needs to change, this is done in Figma. Re-running Figmagic brings in any updated value which updates any component using it. It works like... magic.

Building reusable front end components

Going decoupled meant breaking away from Drupal’s Twig templating and theming layer. For our front end application, we decided on React for our replacement. React continues to be very popular and well-liked, so we didn’t see any technical advantage to picking anything else. This change brought on some additional challenges in that, as a Drupal development company, our focus has not been React. We undertook some initial training exercises to get our development team on this project up-to-speed with the basics. Between this team, our CTO, our CXO, and a senior technical lead, we quickly trained up and settled on a suite of tools to achieve our desired outcomes of a component-driven React frontend.

Component UI frameworks to increase velocity

For us, the approach to developing the many React components that we needed was to first settle on an established framework. Like Bootstrap is to HTML/CSS development, several React-based frameworks are available to use as a foundation for development. It’s always debatable whether this is necessary or not, but we felt this was the best way for us to get started as it greatly increases the development velocity of our project while also providing good reference and documentation for the developers creating our components. We researched several and tried a few, but eventually found ourselves leaning towards Material UI. There were several reasons for this decision, but mainly we like the fact that it is an established, proven, framework that is flexible, well documented, and well supported. With Material UI (MUI), adjusting the base theme using our design tokens from Figma already gave us a good start. Its framework of pre-built components allowed us to make minimal changes to achieve our design goals while freeing up time to focus on our more unique components that were a bit more custom. This framework will continue to be of great benefit in the future as new requirements come up.

Previewing design system component without Drupal

Without a standard Drupal theme available, we needed somewhere to be able to preview our React components for both development and UX review. A decoupled front end, and the whole point of the design system, is that the front end should be as back end agnostic as possible. Each component should stand alone. The front end is the front end and the back end could be anything. Since we haven’t yet connected the front end components to Drupal’s JSON:API, we still needed an easy way to view our design system and the components within it. For this, we used Storybook. Storybook was made for developing and previewing UI components quickly. As a developer working locally, I install and spin up an instance of Storybook with a single command within our project repo. Storybook then looks at our project folder structure, finds any story files that we include as part of all of the components we develop, and generates a nice previewer where we can interactively test out our component props and create examples that developers in the future may need when implementing a component. Storybook is our design system library and previewer as well as our developer documentation. When we are done developing locally and push code to our repository, our deployment pipeline builds and deploys an updated Storybook preview online.

Bringing it all together

At this point, we have our back end and API established. We also have our front end component library created. Now we need to bring it all together and actually connect the two.

Matching the Drupal UI to our React components

React components are standalone UI elements and are made up of props that determine their functionality. So, for instance, a Button component could have many variants for how it looks. A button could include an icon before or after the text, or it could be used to open a link or a dialogue window, etc. A simple component like this might have a whole bunch of different props that can be used in different ways. To be able to control those props through the Drupal UI, we decided to use the Paragraphs module. A paragraph in Drupal is essentially a mini content type for a specific use. In Drupal, we created paragraphs that matched the functionality we needed from our React components so that the Drupal UI would be, in the end, setting the component props. This is a bit confusing to set up at first and something that will probably not be nailed down first try, but, in the process of setting up the Drupal UI in the context of the React components, you can really start to see how the connection between the two is made. At this point, it’s pretty easy to see if a component is missing any props or needs to be refactored in some way.

We also went with Paragraphs because we wanted to give our content creators a more flexible way of creating content. A standard Drupal content type is pretty rigid in structure, but with Paragraphs, we can give content creators a set of building blocks that can be grouped and combined in many different ways to create a wide variety of pages and layouts in a single content type. If you’re not familiar with this style of creating content in Drupal, I suggest you take a look at this post I wrote a while back. Look at that and imagine React components rendering on the page instead of Drupal templates. That’s essentially what we’re aiming to do here.

An argument against Paragraphs is that it could potentially make page building more time-consuming given that you don’t have that typical rigid structure of a content type. This is especially true if pages on a site being built typically all follow a similar format. In this case, we still like to use Paragraphs anyway but we will typically build out unpublished pages that act as templates. We then install the Replicate module which lets content creators clone the template and use it as a starting point. This makes creating pages easy and consistent while still allowing flexibility when needed. Win-win.

Taking the Next.js step

Since we settled on React, we started our front end project as a standard react build using the built-in create-react-app command. But, after some additional investigation, we decided that a better option for our use case would be to use the Next.js framework. Given that the corporate site is, at its core, is a marketing and blogging website, Next.js allows us to still build the frontend using React but gives us some extra capabilities this type of website needs.

One of these capabilities is incoming server-side rendering which we found increases the performance of our application. This also has SEO benefits due to pages being rendered serverside and sent to the client, as opposed to the standard client-side rendering most React applications use where the client machine handles processing and rendering.

Component factories are key to interpreting the API data

We were also attracted to the structure and organization of the project when using a framework like Next.js, as well as the dynamic routing capabilities. This significantly simplified the code required to implement our decoupled menu and page routing. Using the dynamic routes provided by Next.js, we could create “catch-all” routes to handle the ever-growing content in the CMS. By querying the Drupal API, we can get all the available path aliases for our content and feed it to Next.js so it can pre-build our pages. It can use the path aliases to resolve the content specific to the page through the Decouple Router module, which will then feed that data to a component factory to handle the decision as to what high-level React page component is necessary to build a page. For example, if the data is for a basic page content type, the page factory component returns our Page component, if it’s a blog post content type, it returns the Blog Page component, etc. Each of these components knows how to handle the specific data fed to it, but the factory component is what connects the data to the right page.

The way Paragraphs can be added to a page for composing a piece of content also created a challenge on its own in reading that data and returning the right component. We decided to create another factory component for this. Similar to the page factory component, this one takes in the paragraph data and determines which React components it needs to render the content.

What’s next in our decoupled adventure

Believe it or not, what we’re building is still a work in progress. While we have most of the tech requirements figured out, we’re still actively putting all of the final pieces in place and fine-tuning the backend UI and modules requirements. All in all, we’re feeling really good about this progress and can see the value of what we’re building both for ourselves and the clients we serve. In our opinion that is based on experience and research, decoupled is the future, and we’re excited to walk this path.

With that said, even once our own decoupled site has launched, we still have a lot of work left to do. For one, we still need to get a method in place for managing Drupal blocks and regions. More factory components will be critical here to interpret that data. Given that our clients are primarily ecommerce retailers in one form or another, we still have the whole ecommerce side of web development to sort out, including product catalogues, add-to-cart forms, carts, wish lists, checkout flows, etc. The list is long. However, what we have is a framework that can be repurposed and added on to. It finally helps tie together many disciplines of web development, both creative and technical, that are traditionally siloed. It’s also blazing fast and just plain cool. This is an investment not only in our own online business front but in something greater that we hope to share with others through work, community and general knowledge.

Thanks for taking the time to read this. If you want to chat about this initiative further, drop us a line.

New call-to-action

Apr 07 2021
Apr 07

Switch view modes for all entity types editorially with our new Drupal module!

Interaction with the View Mode Switch Field Modul 

Separating content from layout, ensuring high flexibility for the editorial team when creating content, as well as a simple and consistent CMS - this all sounds absolutely reasonable and can also be implemented very well in Drupal. With its modular structure and the ability to extend its functions through various contrib modules, this is already possible in Drupal. Nevertheless, in our projects we have noticed over and over again that editors need even more predefined layouts (e.g. for different arrangements in text-image elements, teaser variants, etc.) from which they can select individually and thus determine the output.

Different view modesLayout variants of the configured view modes in the output

This idea is not a new one. There are and have been different approaches within the Drupal world for managing output options:

  • In Drupal 7, there were two major players Display Suite (ds) and Panels (panels) for layouting content. Both had their advantages and disadvantages, but both have lost their relevance in Drupal 8/9 due to the Layout Builder.
  • With the Layout Builder in Drupal 8/9, the editorial team can be extremely flexible in customizing the layout of content. Even too flexible, so that it is also up to them to take care of the consistency in the layout of the page.
  • For Drupal 8/9 there is a contrib module called "View Mode Selector", which provides a similar functionality as our new module. This gives the editors a choice of (only) one defined view mode, which in practice is usually not enough.

So why yet another new module?

Quite simple: We were missing versatility and flexibility for site builders as well as editorial teams. Especially for larger projects, when the Drupal site is extensive and many people are involved in the editorial team, this becomes more and more important.

This is when it is extremely helpful to be able to select different predefined view modes with different layouts/templates for all relevant entities and still maintain the layout consistency of the site. This is how the View Mode Switch Field module was born.

In a nutshell, the View Mode Switch Field module does the following: It allows site builders to provide different defined view modes for fieldable entities. This allows editors to choose between predefined view modes and thus control entity output more flexibly. For example, editors can highlight article teasers in a listing or change the arrangement of image text paragraphs.

Layout Builder View Mode Switch FieldConfiguration of the layout variants as view modes with the help of the layout builder

The simple magic behind the View Mode Switch Field module

Site builders can include any number of view mode switch fields per entity bundle, so that editors can independently switch one or more view modes per field. Of course, the created view modes can be subsequently adjusted, changed or even deleted - without affecting the content of the Drupal page itself. Any configuration change to the corresponding view modes will also be applied to existing content. In case of missing view modes the layout jumps back to the defined default setting.

To use the module, there are only a few simple steps for site builders:

  • Create and design the view modes.
  • Add and configure one or more view mode switch fields via the Field UI - here it is possible to allow any number of view modes to be switched per field and to define which view modes can be switched to.
Settings View Mode Switch Field ModulField configurations of the View Mode Switch field

A wide range of benefits

As mentioned before, the View Mode Switch Field module mainly improves versatility and flexibility for site builders and editors. This is still quite general and applies to many Drupal modules. So here we want to give you very specific points where the module will help you:

  • Content and layout are still considered separately. This means that both can be adjusted independently of each other.
  • The module strikes a good balance between freedom and flexibility for the editorial team and compliance with CI guidelines. The editorial team is only given really necessary options, so that a consist look and feel of the design is automatically preserved.
  • Data structures (e.g. the field set of a paragraph) only have to be defined once and can still use different output options. Instead of creating a new paragraph type for another display, e.g. an inverted text-image combination, this can be controlled by selecting the view modes.
  • By avoiding duplications in the data structure, the editing interface becomes and remains lean and clear.
  • The way the module works avoids possibly unperforming preprocesses and templates for the actual layout switching. In addition, the use of view modes ensures very good cache behavior and thus high performance.
  • Subsequent global layout changes affect all (new and existing) entities. For comparison: e.g. with Layout Builder, the layouts overwritten per entity are decoupled from updates.
  • The implementation based on the Drupal Core Field API enables site builders to perform all the functions already known for entity fields - for example, generating entity listings based on specific View Mode Switch field values (whether for editorial overviews or administrative information).

Last but not least

As an agency, we handle a wide variety of projects and like to use the View Mode Switch Field module for them. The module is particularly useful in Drupal projects that use a component-based layout/design approach. Editors can use it to select individual building blocks (entity bundles) from a ready-made construction kit (content types, paragraph types, etc.) and display or "paint" them differently (view modes with defined layouts).

Since it is extremely important to us that our projects run smoothly at all times, we equip them with automated tests by default. The View Mode Switch Field module also comes with extensive test classes that ensure the runability of the module code for various scenarios.

The View Mode Switch Field module is shared in the Drupal community and is available for anyone to download. Try it out and feel free to give us feedback in the Drupal issue queue!

Apr 07 2021
Apr 07

Agiledrop has officially joined the Acquia partner program as a Bronze Level Partner. Acquia invited us to join their ranks because of their goal to grow the business in the Central Europe region, where Agiledrop has already established itself as the leader when it comes to building enterprise-level Drupal solutions.

Acquia Bronze Level Partner Badge

More than 8 years of experience with Acquia

Even though the official partnership is new, Agiledrop’s cooperation with Acquia and working with their product line is not new to us. Agiledrop’s very first project that involved an Acquia product was the development of a website for an iconic North American performance art group, known for its stage productions which incorporate many different styles of music and art. This was in 2013, and Acquia already had the best-in-class hosting solution for Drupal (that later became Acquia Cloud).

Throughout the years our team has been involved in many projects that involved other Acquia products, such as Acquia Site Factory and Acquia Lift (now known as Acquia Personalization). Our team was and still is collaborating with teams of Acquia’s top-tier agency partners, delivering some of the flagship projects.

Why become an Acquia partner now?

Acquia’s reputation as a CMS leader has grown significantly since its foundation. The last few years in particular included multiple milestones that have had and will continue to have a huge impact on the future of Acquia and their standing in the industry.

In 2019, starting with the acquisitions of the MarTech platform Mautic and the CDP AgilOne, Acquia began establishing itself as a big player in the space and a true competitor to proprietary solutions such as Sitecore and Adobe. Moreover, they were themselves acquired by Vista Equity Partners for the hefty sum of $1 billion.

Things became even more interesting very early on in 2020, with Gartner abandoning its Magic Quadrant for Web Content Management and replacing it with the Magic Quadrant for Digital Experience Platforms, in which they positioned Acquia as a leader.

And 2020 had still more to offer. June saw the release of the long anticipated version 9 of Drupal, the open-source framework on which Acquia’s platform is based, which featured unprecedented improvements in all areas.

All this led to Gartner granting Acquia an even higher position in the 2021 edition of their Magic Quadrant for DXP, placing it as a top leader right behind Adobe. And, since Adobe is a proprietary platform, Acquia’s DXP is currently the number one choice among the open DXP.

Gartner Magic Quadrant for DXP 2021

As long time proponents of Drupal and open source software, we at Agiledrop have always been fans of Acquia and their products, and it’s thus only natural that the most open DXP would be the most appealing one to us.

Having ourselves also transitioned in mindset from content management to digital experience management, and realizing the advantages that a well-architected digital experience platform offers, a partnership with Acquia was a no-brainer for us, even more so considering all their recent developments.

What’s next?

With continuous determination towards helping enterprises deliver digital solutions and experiences, Agiledrop is now one step closer to achieving our purpose. 

By becoming an Acquia partner we now have access to solutions beyond Drupal (but deeply integrated with Drupal) that can help us serve enterprise clients. This is particularly important as so many businesses now need highly integrated omnichannel experiences due to the Covid-fueled digitalization.

On the other hand, Acquia gains a strong partner in the important up-and-coming Central European region, one which is strongly committed to supporting both the company itself and the Drupal project upon which it is based.

We’re looking forward to a long-standing and mutually beneficial partnership, and we’re very glad we get to be part of this journey with a company whose vision is this closely aligned with ours. 

Apr 07 2021
hw
Apr 07

I am going to keep today’s DrupalFest post simple and talk about the API to access content on drupal.org. The Drupal.org API is a public API that allows you to access content such as projects (modules, themes, etc), issues, pages, and more. The API returns data as a simple JSON structure and has only limited features with regards to filtering and gathering nested data. In this post, I will describe more about this API and various ways to access it. It has been a tough day and it is difficult for me to write long posts or go deep in my thoughts. Regardless, I hope this quick post still proves useful.

API basics

The base endpoint to access the drupal.org API (henceforth, d.o API) is https://www.drupal.org/api-d7/. In fact, you can probably convert any canonical URL on drupal.org to its API equivalent. Simply prefix the path with “api-d7” and suffix “.json”. By canonical, I mean URL’s that use Drupal’s internal path such as node/2773581 or user/314031. These endpoints return JSON responses which are practically the same as Drupal internal representation. This means you will notice weird field names (almost all fields would begin with “field_”) and nesting that you might not expect from any other API’s. If you have programmed for Drupal, chances are you will feel right at home with the response data structure.

The API’s that return listing of entities are simply named such as node.json or user.json (and so on). The listing endpoints accept a variety of filters and allow pagination with simple query parameters. Most of the field names can be directly used as query parameters to filter the list on that field value. For example, https://www.drupal.org/api-d7/node.json?type=project_issue would return all the issues on drupal.org. Whereas, the URL https://www.drupal.org/api-d7/node.json?type=project_issue&field_project=3158507 would return only the issues in the preloader project (preloader’s node id on drupal.org is 3158507).

Read the documentation page for examples and more details such as field names and values.

Shortcomings in the API

As you might have surmised from the description above, this API is not designed for common consumption. Drupal Association maintains this on a best-effort basis and more sophisticated use cases (such as gathering nested data in a single request) are not supported. There is a plan to improve the API on the whole in the future but I don’t know when that might happen.

Practically speaking, this means that you have to make multiple API calls if you want to collect all the information about any entity. The first API call would be to the main entity about which you want information. And then you have to parse it to gather all the referenced ID’s and make API calls for each of them. If you wanted to build an efficient parser that needs to deal with a lot of nodes, you would probably have to persist all information in your application (which is what I did with DruStats).

The problem is not limited to just normal relationships such as terms and users, but also to entity reference fields. For example, if you want to find out a user’s organization, you would have to read the “field_organizations” property and make a request under “field_collection_item” endpoint with that ID. In a normal consumer-grade API, you would probably expect the information to be embedded right in the user response.

Using the API in your code

The API endpoints are straightforward and you can request data with a simple curl request or just the browser. However, if you were writing an application, you might often get frustrated with dealing with the filters and nested queries. This is where libraries come in.

The d.o API page lists two such libraries at the end of the documentation page. The first one listed is by Kris Vanderwater (EclipseGc) and it seems simple enough to use. The second one was written by me at the time when I was building DruStats. I needed something more sophisticated and I decided to write my own API wrapper. Since then, I also used this library for Contrib Tracker, a project which tracks contributions to drupal.org by multiple users. This library is reasonably documented on the Github page but improvements are always welcome. You can also look at examples in DruStats and Contrib Tracker. I am currently in the process of moving Contrib Tracker to a new home and I am not linking to the current URL right now. I am also planning a post on contrib tracker soon.

Using the CLI tool

Matt Glaman has written a CLI tool to interact with drupal.org issues. If you only want to automate your Drupal contribution workflow, then this CLI tool might be what you need. This tool allows you to simplify working with Drupal.org patches, create interdiffs, and even watch CI jobs. As always, the documentation on Github can guide you with the installation and usage of this CLI tool.

Apr 06 2021
Apr 06

 This guide is an extension of the first ever published book with the step-by-step, technical details you need to search engine optimize a Drupal website. Originally written by Ben Finklea (Volacci's Fearless Leader) in 2017, it is the first step to digital marketing excellence that will reward you with increased ranking, traffic, customers, and sales.

While these instructions were written for marketers, developers can also benefit. The ability to provide a more easily SEO'd website to a client will always be in demand. Should you wish to partner with Volacci on SEO services for new websites, please feel free to reach out to us.

Bookmark this page!
We will keep this section updated with the latest Drupal SEO instructions,
but please be patient -- research and writing takes time.

What this guide is.

If you were sitting at the desk next to us right now and needed help with a Drupal SEO technical problem, we’d just tell you how to solve it, walking you through the necessary steps. That’s what this guide is.

What this guide isn’t.

We won't go into detailed, basic explanations on what SEO is and why it's important. There are many great resources online with full explanations of how SEO works, what Google is looking for, and how to win the online marketing game. We’ll link to some good ones so you can dig deeper when you need to. We’re especially fond of Moz.com, and always send people to their Beginner’s Guide to SEO if they’re just starting out.

We explain how we do the technical SEO on a Drupal website. It’s not the only way, but we’ve found it’s the way that works best for us. If you get through this guide (or get too busy to complete it), and your site is still not ranking, then seek professional help

How to read this guide.

It’s best to install the SEO Checklist module, and check the items off as you complete them. This guide details each section of that Checklist.

Throughout this guide, you’ll find various text styles to help make concepts clearer or to draw your attention to important aspects of a task. Here are some examples:

  • Italic. Warnings or critical terms.
  • Bold. New words or to draw attention.
  • Code. URLs or code snippets
  • "Quotes". Interface elements you’re interacting with.
     

Notes, Tips, Warnings

Extra information that helps you better understand a concept, avoid a misstep, or give additional functionality.


Sometimes, it can be helpful to know how hard a task is going to be, so we’ve included them to make things clear. Here’s what they mean:

normal and hard rating system

  • Easy: Straightforward and quick.
  • Normal: A bit more involved, maybe 2 or 3 separate steps but no heavy lifting.
  • Hard: It’s going to take some thought and time to do this. Still, most marketers should be able to knock it out with some effort.
  • Expert: This task is time-consuming, technical, or difficult. You may need to get some help from your Drupal developer to get it done.
Apr 06 2021
Apr 06

The Decoupled Menus Initiative is hosting a contribution hackathon where you can help us test both the response format of the proposed menu API, and the new General project type on Drupal.org for facilitating development of JavaScript libraries within the Drupal ecosystem.

What:

Join a team and contribute to one of the existing projects, or start your own and show off your ideas.

The goal of the hackathon is to create (or improve existing) projects on Drupal.org that leverage the proposed menu API in order to test the API itself and the new infrastructure for developing JavaScript libraries on Drupal.org.

There are a couple of existing projects, with well-defined issues, that would be a great place to jump in and help out.

Or you can start your own. This is your chance to share your experience from past projects, or get creative and dream up new ways of navigating a menu.

We’ve set up a demo API endpoint that you can use to test a menu provided by Drupal. Check it out here, and here.

Some inspiration to get the creative ideas flowing:

  • Have a favorite JavaScript library that's not already represented (Vue, Angular, Ember, Svelte, etc.)? Create a project that demonstrates how to consume a Drupal menu using that library.

  • What is the digital signage representation of a menu?

  • Help add tests to one of the existing components.

  • What would it look like to navigate a Drupal menu via voice commands like Alexa?

  • Can you play Doom via a Drupal menu?

If you want to start a team, or have ideas but aren't sure where to go next come find one of us and we'll help get you pointed in the right direction.

Who:

Anyone and everyone is welcome. Whether this is your first time, or you're an experienced contributor, we'll have mentors who can help answer your questions and guide you along the way. And whether you want to write code, create docs, design interactive UIs, or anything else, we'll do our best to put your unique skills to work.

Have an idea for a project and want to find others to collaborate with? Let us know and we can help create the space, and link you up with potential collaborators.

When:

Tuesday, 13 April is Decoupled Menus Day at DrupalCon. The morning will consist of a keynote and related sessions. And in the afternoon we’ll kick off the contribution hackathon. This is when we'll form teams, group newcomers with mentors, and generally provide the most hands-on guidance.

On Wednesday, Thursday, and Friday we'll schedule a time to hang out, answer questions, and help in any way we can. Expect this to be maybe about an hour each day. Though, many of us are in Slack (#decoupled-menus-initiative) and can be reached there asynchronously.

Throughout the rest of the week, you and your team are free to self-organize and work on your projects whenever it works for you.

Where:

The primary gathering space for the hackathon will be Open Social and Zoom.

We'll have a main Zoom call set-up where you can go for questions and guidance at any time. As well as individual Zoom calls for focused collaboration on specific topics. Think of these like how groups are often organized by table in a traditional code sprint.

The Open Social site contains a list of scheduled events and links to relevant Zoom rooms.

You find us in the #decoupled-menus-initiative on Slack.

All the links:

Apr 06 2021
Apr 06

Do these numbers seem shocking to you? They certainly were for me. And the more unfortunate fact is that these numbers will only grow in the future. So, what should be done? We cannot stop people from getting a disability, that is in no one's hand. However, we can ensure that that disability should not hold them back. We should endeavour for inclusion, wherein every person on this planet gets an equal opportunity, disability not being a criteria impeding on their life experiences. 

To that accord, accessibility was designed, for inclusion, for equality and for making the differently abled feel that their voices and their feelings value. Accessibility has expanded as a concept since its inception and now, it is also being rigorously practised on the web.

The web or the internet is for everyone, you cannot say that it was designed with a particular demographic in mind because it simply wasn’t. From 5-year-olds watching YouTube videos that are making them prepared for school to 70-year-olds watching a YouTube tutorial on how to update their WhatsApp status, the internet is for everyone and web accessibility ensures that it can be accessed by everyone without difficulty. 

This brings us to the meaning of web accessibility, which is to design something on the web that includes the needs of the differently abled. People with auditory, cognitive, visual and speech disabilities amongst others should be able to perceive, understand, navigate and interact with the web with ease. You should remember that accessibility is not just limited to people with disabilities, it also transcends to other aspects of life that may affect one’s ability to perceive what is right in front of them. Old-age, bright sunlight, the size of the device being used and the person’s mental and physical state at one point, all are included when we talk about accessible design on the web. Therefore, when businesses and organisations are able to build such experiences that cater to all of what I just mentioned, only then would they be truly accessible. 

With Tim’s words at the back of our minds, let’s find out what the fuss about accessibility is for. Here are three reasons that sum up the crux of accessibility and why it ought to be practiced down to the very of the web business.

The paramount reason for practising accessibility lies in the numbers we talked about in the introduction. The close to one billion differently-abled people in the world would be able to access your web project with ease. They won’t feel frustrated or undervalued by your business model, if it is accessible. And can you guess what that means? Yes, you’ll be able to target a market that your competitors might have overlooked. And that is enough to get you the revenue you endeavour for.

You know the United Nations? I’m sure you do. And when the UN says something is important and needs to be followed, you follow it. The United Nations Convention on the Rights of Persons with Disabilities clearly states that access to information and communications technologies is a basic human right. And when you make websites that are inaccessible to persons with disabilities, you are going against the UN and you won’t want that.

Even in the US, the Americans with Disabilities Act also establishes grounds for web accessibility and adherence to those guidelines is important to stay on the good side of the law, don’t you agree?

Then, there is the concern about brand image. If I had to describe accessibility’s essence, the only thing that would do it justice would be social inclusion. Including every section of the society and every scenario that may hamper their web experience, and building a web project that takes into account all of that would most definitely get positive feedback from the audience using it. And that is how you build a positive brand image. 
 
Now, tell me are you not on the side of accessibility? Are you not craving to make the entirety of your website truly accessible to the users, whoever they may be, whatever their physical or mental condition be, and wherever they may be? 
 
If that is the case, continue reading because I am going to be talking about accessibility tools that are found in Drupal, a leading CMS, so that you can use those tools and modules to make your site the epitome of accessibility.

Drupal has certain checklists that are used to evaluate the competence of a particular aspect of your project, these are called Drupal Core Gates. There are six in total, ranging from Content to Frontend and testing. And you would be glad to know that accessibility is one of these six parameters, this alone is explanatory enough to let you know how much Drupal prioritises this part of web designing. 

All of these are proof of Drupal’s compliance with accessibility, meaning that Drupal is incomplete without it. With the additional WAI-ARIA support, Drupal is becoming all the more proficient in building projects that are accessible and rich internet applications. 

With that said, let us look at the accessibility-centric features found in Drupal. 

The addition of WAI-ARIA landmarks, live regions, roles and properties has equipped Drupal to provide more semantic HTML5 elements that can be leveraged by assistive technology.

Let’s try to understand this, 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. So, HTML and WAI-ARIA help in achieving screen-friendliness and making the UIs more interactive.

Aural users play a major role where accessible design is concerned. To that accord, Drupal.announce() has been made a part of Drupal core so that timely messages can be delivered to these users relying on a screen reader with different tones as well; you can be assertive or polite, it is up to you. This is the Aural Alerts feature.

Users that are visually impaired and the ones who cannot operate a mouse can opt for the Tabbing Manager. This is a feature that would essentially become a guide for these users, so that they are able to access all the salient features and that too in a logical order. 

Your content can be displayed in multifarious ways; it is up to you to decide how you want it. With Drupal’s CSS classes, you can control the way your content is hidden or not. Would certain screen readers can view it or all of them, would hidden, visually hidden or focusable or entirely invisible, you would get to decide every single nuance.   

This is due to the centralised alternative to CSS display:none; and the standardisation of the HTML5 Boilerplate naming convention. 

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.

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 and checkboxes in the Form API. This helps towards additionally upgrading forms in Drupal. This feature is also being used in the advanced search option. 

The Alternative Text 

People with good eyesight can see the images, but what about the visually impaired? They won’t be able to see the images. And images are important in context to what you want to portray in your content. So, what is the solution?

It is an alternative text, this text describes everything going on in the picture, so that the people without sight are able to understand what the picture is about. 

Drupal has alternative text as default to make the content accessible to everyone and content creators understand its importance. However, the default can be overridden through CKEditor or Image Fields, if that is what you might prefer. 

The Bartik 

If you think about it, a link is like any other piece of content on a webpage, yet it is different because it has the power to take you to a different page for more information. This power should be highlighted properly. And Bartik is here to help in that. A Bartik underlines a link, which basically highlights it and makes it easily identifiable, aiding to enhance accessibility further. 

The jQuery UI 

Drupal’s autocomplete feature is quite useful and jQuery UI is helping in elevating its usefulness. Being implemented in Views UI and in other places, it is improving Drupal’s accessibility standards. With the involvement of jQuery UI community, the benefits are being experienced by both the projects in leaps.

Drupal Accessibility Also Transcends to Developers: D7AX

When we hear accessibility, we always go to the users. Accessibility has to be about them, right? We must ensure that everything on the site is totally accessible to every user, regardless of their physical condition. 

This notion is true, yet it is only half true. Yes, the majority of the accessibility guidelines focus on the users, however, the developers, the people who actually build a project from the ground up also need to prioritise in terms of accessibility. So, the development process has to be accessible for them to build something great that they are fully capable of doing.

And Drupal provides this as well. Drupal has focused on accessibility for developers and that is what makes me as a Drupalists proud of this platform. Developers can depend on Drupal for support when they are creating accessible sites and projects. 

The D7AX is shining glory of Drupal in this accord. It makes it extremely convenient for developers to find contributed modules and themes that support the development of accessible websites. 

So, what is D7AX? 

It is a kind of platform that lets other developers know that a module has been designed after following all the resources for developing accessible modules. When you see a hashtag saying D7AX on a module page, know that it is accessibility friendly. 

Whenever you use a D7AX module, you are contributing in making that module a success. Using it would mean any issues that were overseen before might be caught by you and resolved, making you a D7AX developer as well and a contributor in Drupal accessibility, 

What about themes? 

D7AX is not just limited to modules, it also works to resolve the accessibility challenges found in the theme layers. It works in similar fashion to that of modules and the hashtag lets the users know that a theme is compliant to the accessibility guidelines. The Accessibility handbook will help you further in this regard. 

Is there an accessibility group?

Yes, there is and it is the Drupal Accessibility Group. It would answer all your questions about Drupal accessibility and make accessibility come alive on your fingertips. With regular sessions and talks, you’ll get to know all the hints, tips and tricks about it. 

Your feedback is always going to be valued at Drupal, the accessibility group is no different. Even if you have concerns about Drupal lacking in an aspect of accessibility, you should raise it. Who knows maybe you end up making Drupal even better. 

This is the kind of indulgence by developers as part of one community that makes Drupal an ideal place for developers to build something that is universally accessible because they have access to the ideas and work of other developers and that gives Drupal an unparalleled edge. 

Modules Making Drupal Sites Universally Accessible

Knowing that Drupal caters to accessibility for the administrators and developers as well as the visitors does give a sense of relief that we are going on the right track with Drupal. However, is that enough? I don’t think so. 

Until you know how to effectively implement the aforementioned accessibility features into your project, you can’t sit back and relax. To help you in executing accessibility to the T, here is a list of the modules that will enable you to deploy a universally accessible project. 

#1 The CKEditor Family 

You cannot talk about Drupal accessibility modules without talking about the CKEditor. It is a WYSIWYG module that provides umpteen features like structured content and clean markup and convenient drag and drop features based on its UI along with pretty secure safety guidelines for your content creators.

The CKEditor in itself is pretty powerful when it comes to accessibility, however, when you bring five of its variants into the mix, it has the potential of making Drupal even more accessible. Let’s have a look at them now.

CKEditor Accessibility Auditor 

The HTML_CodeSniffer Accessibility Auditor comes in the package of CKEditor Accessibility Auditor with a button for the same that audits the source code of your current content. 

If you have a specific error; 
If you want a success criteria and suggestions of techniques; 
If you want to know what triggered the error; 

Everything would be found by these modules and the results will be in front of you almost as soon as you run the auditor.

CKEditor Accessibility Checker 

The CKEditor Accessibility Checker provides a plugin with a creativeness for accessibility inspection of your WYSIWYG body created in the CKEditor itself. Of course, the inspection would lead on to immediate solutions of any problems found. You should know that this innovation plugin is the Accessibility Checker, hence the name of the module.

CKEditor Balloon Panel 

This module is used in relation to the previous one to create floating panels that have accessibility tips. These floating panels are a courtesy of Balloon Panel plugin that make it possible for you to present as content at whichever specific position you want to, 

CKEditor Abbreviation 

The CKEditor Abbreviation’s purpose is quite simple. If you want to add a button to the CKEditor to help you insert and edit abbreviations, it will do that for you. The addition of a link to edit the abbreviation is an added bonus.

USWDS CKEditor Integration

Like the name says, the USWDS CKEditor Integration module integrates the US Web Design System to the CKEditor, which has become a requirement for government websites. You can use the USWDS classes and components and inject them into the CKEditor, all without opening the source even once.

#2 Automatic Alternate Text 

Did you know that there is an API that can actually process images through its state-of-the-art algorithms and return with an output that is quite on point? It can sense the content of the image, its maturity levels and even the prominent colours in it. 

The Microsoft Azure Cognitive Services API is able to do this with ease. Drupal’s Automatic Alternative Text module utilises the competence of this API and provides alt text to images your users did not. 

However, you must be aware of the fact that the way we perceive images and the technology would perceive it may not be similar, so the produced alt text can be different to what you may have expected. 

#3 A11Y:Form Helpers 

Remember the accessible forms I mentioned as a Drupal feature, the A11Y: Form Helpers helps in achieving that. It aims to fix the accessibility issues found in Drupal forms. 

This module’s features are quite impressive. 

  • You do not require any HTML validation; 
  • You can include readable inline error messages for screen readers; 
  • You can even put in pre-filled attributes to certain form elements, which is always a winner.

#4 Block ARIA Landmarks Role

People usually prefer when you come straight to the point and skip all the small talk. And ARIA landmarks are just the means for that; it allows users to skip the unnecessary and switch to the main content. 

With the Block ARIA Landmarks Role, you can add extra elements to the block configuration forms and users can allocate an ARIA landmark role or label to a specific block. Having been created with inspiration from the Block Class, this module does cater to accessibility.

#5 Editoria11y

Editoria11y is a module that caters to the accessibility needs of the content creators and editors. Being a user-friendly checker, it focuses on the accessibility concerns of content authors and rectifies them. 

  • It ensures that speckcheck is always on and corrects the content mistakes as and when they happen.
  • It ensures that errors never happen in relation to Views, Layout Builder, Media and similar modules. This is because it runs in context with them and its checkers are always running.
  • Lastly, it ensures that content issues get fixed by prioritising them. Its exclusive focus on them ensures page editors don’t miss anything that is easily fixable by them.

#6 Fluidproject UI Options 

A web page has a lot of different elements that might need modifications to make them aligned with the accessibility standards set by Drupal and W3C. The Fluidproject UI Options tends to make these modifications easy for you. 

Be it; 

  • the page’s font size;
  • the page’s font style; 
  • the page’s height; 
  • the page’s contrast ratios; 
  • the page’s link style; 

everything can be sorted and the changes can be retained using cookies. However, it does come with certain limitations, using CSS gradients for contrast settings is one of them. 

#7 High Contrast 

You will have a theme that you are currently using, then there will be a theme that would be a high contrast version of the same. Reading this along with the name of the module, you must be able to guess what this module is all about. 

With High Contrast, you will be able to switch between your theme and a high contrast version of the same. All you would need to do is press tab on the keyboard after installing the module and you’ll get the high contrast pop-up link on your screen and the work is done.

#8 Siteimprove

Aiming for high quality content along with higher traffic and a higher level of digital performance is not unreasonable. And doing all of this by adhering to the regulatory compliance is what Siteimprove is known for. 

Being a comprehensive cloud-based Digital Presence Optimisation software, it offers a smooth integration through its Drupal module, wherein  you can capitalise Siteimprove efficiency in content creation and editing process.

Be it testing the content; 
Be it fixing what was found; 
Be it optimising the perpetual work; 

You will have the analytics and content insights at your disposal to make this happen. Siteimprove’s plugins ability to lessen the gap between Drupal and the software’s Intelligence Platform is the sole reason for these amazing benefits. 

#9 Style Switcher 

Have you ever found yourself in a conundrum wherein creating themes and building sites seems like a mammoth task? If you have, you most likely would have been facing issues with the alternate stylesheets. 

The Style Switcher module makes all of this a breeze by focusing on the themer as well as the site builder. It provides an alternate stylesheet for both in the admin section. These styles are presented in a list of links in a block to your site visitors. 

And there is more, with the module making use of cookies, these styles are always remembered and when someone returns to a page, he is welcomed by the same style he chose in his previous visit. Pretty amazing, right?

#10 Text Resize 

Have you ever squinted your eyes to read a piece of text that is too small? Did you get frustrated by it? Now, imagine you have a weak eyesight and focusing is always an issue. Would you be able to read a small font size? I don’t think you will and now you know how the visually impaired feel.

The Text Resize module helps in making the visually impaired feel less frustrated. Using jQuery and jQuery Cookie, it creates a Drupal block that allows users to change the font size of the text, making your pages more accessible. You would be glad to know that it can also resize images. However, you have to remember to enable the Text Resize block of your theme, only then would the block appear. 

#11 Civic Accessibility Toolbar  

Civic Accessibility Toolbar has a pretty similar principle to the previous module. Unlike the Text Resize module, it not only aids changes in the font size of the text, but it also helps users in switching to a theme version that has a higher contrast. 

Now, much like Text Resize, this module also operates on the creation of blocks for the utilities being implemented for accessibility with the visually impaired in mind. 

Bartik, Garland, Zen Starterkit, Stark and Oliveiro are all the themes in which the Civic Accessibility Toolbar has been trialed and tested.

#12 HTML Purifier

Auditing your site with a thorough and secure whitelist as well as ensuring that your documents are compliant to the standards of W3C’s specification will keep you on the good side of accessibility. Drupal’s HTML Purifier module does just that through the HTML filter library of the standard stringent HTML Purifier

With this module you can say goodbye to all malicious code.

Custom fonts; 
Inline styles; 
Images and tables; 
Restricted tags; 

All of these are possible when you combine the HTML Purifier with your WYSIWYG editors. You will hit the standard compliant ball out of the park with a home run through this module. 

Now that we have discussed all the necessary modules that aid in making your Drupal site universally accessible, let’s listen to what one of our frontend developers at OpenSense Labs has to say about Drupal and its part in accessibility.

“Drupal Core on its own takes care of the accessibility in the site. Since many accessibility challenges are confined to Frontend (Theme) Layer, it is better to have good practices in place for frontend development to ensure accessibility compatible sites.” 

I personally feel that he is right. There are hundreds of modules in Drupal and you can use as many of them when building your site. With so many modules at work, your site is bound to be extremely functional and impressive. However, it still might not be accessible, if you don’t keep accessibility as an imperative parameter during the building process. 

I’ll explain this with a few modules for better understanding. 

If you look at all of these modules, they are not blatantly related to accessibility, but all of them are somehow adding to your site’s accessibility appeal. Now, if you developers are constantly building with accessibility at the back of their minds, they would use these modules without any hesitation. 

Therefore, like our frontend developer said, Drupal accessibility is all about good practices throughout the building process and throughout the life of the web project. 

Are You Certain Your Project is Accessible, Let’s Review!

Up until now we have discussed the accessibility features found in Drupal and the modules that support the implementation of those features. Do you think that is enough? Do you think the installing and running a bunch of modules makes all your accessibility work done and now you can sit back and relax? If you think so my friend, you are utterly wrong. 

By running modules, you cannot be certain that your site is truly accessible, that it checks all the accessibility boxes. You have to run a thorough review on all the parameters that can affect your site’s accessibility and after reviewing the results and rectifying them, you can sit back and chill as much as you want. 

So, let’s start the review.

Review through Automation 

You need to start your reviewing process with Drupal’s automated tools that are designed to assess your project’s accessibility levels and issues arising out of it and consequently resolving them. 

Some of these tools are; 

WAVE;
Tenon;
Accessibility Insights;
Google Lighthouse;
Siteimprove;
And Siteimprove Accessibility Checker.

With axe-core, you can automate some of them and sit back while they do their work.

Review the Keyboard

Keyboard navigation is of great significance when it comes to web accessibility, so you cannot afford to go wrong with it. Everything and every element on your screen must be accessible through a keyboard and with a tab order that makes sense.

When making your assessment, look for things like these; 

  • The tab should work forwards and backwards; 
  • The interactive elements should be highlighted from others; 
  • The document object model should be followed in the tabbing progression, making it natural; 
  • The skip option is available for content that is repeated; 
  • The user should be able to skip overlays, modals and autocomplete widgets; 
  • The hovering mouse content should be accessible through the keyboard as well. 

Pointers like these amongst others would make your project keyboard friendly. One more thing, you should remember to review this on mobile and tablets as well to avoid any responsive breakpoints.

Review the Colour and Contrast 

Next comes the colour and the contrast, which should be prioritised too. The foreground and the background need to be quite distinguished from each other. 4.5:1 is the ideal ratio of text to the background. Anything lesser than that would be in direct contradiction to the accessibility guidelines. 

You also need to remember that colour cannot be the only way to relay information. Think of your audience, who might be colour blind; would they be able to gather what you are trying to say?

There are two boxes with the same kind of figures differentiated with colour, but the second has the addition of numbers as a desciption


The second demonstration in this image is what you should always go for. 

Review the Content 

You also need to review your content. By content, I don’t exactly mean the words you use, although the language should be easy to understand. 

Apart from that, there is also the changing content such as the list of search results, which keeps updating all the time. This is called the dynamic content and you must announce these changes through assistive technology; ARIA Live Regions help in this regard.

Headings are a part of the content as well. In this regard, you have to make sure that your headings are not only prominent enough, but also descriptive enough to ensure that something reading it understands its entire context. 

Then there are the icons, which cannot just be the icons because the users would not be able to know their functionality without a proper description. Give labels to all your icons, if you haven’t already. 

Review the Sound and Video 

This one is for the deaf community and people who have hard hearing problems. The elements on your site that are relaying information through sounds and videos should have accompanying textual transcripts and captions so that people who cannot hear what is being said and read it. This would automatically make your site more accessible. 

I used both captions and textual transcripts because this review also focuses on the users with visual impairments. This is because for a complex video, captions alone may not be enough. There may be a need to textually describe the scene to people who cannot see what is happening and captions would only provide context to some degree. 

Review the Animations and Autoplay 

There is a high chance that your project might have animations, audios and videos. Obviously, there would be a purpose for their presence on your site, but you have to consider the user as well and that means avoid autoplay. 

Videos that autoplay and don’t pause by themselves are a nuisance to me, frankly, if I want to watch, I’ll press play myself. So, you should also turn the autoplay option off and even if it is on, the animations, audios and videos should stop playing after a couple of seconds. 

You should also think about adding easy controls to play and pause these media items. 

Review the Screen Reader 

You are going to have users that would completely rely on a screen reader, so ensuring that there are no issues with that has to be on your review checklist. 

For this, 

  • You should assess that the same information is being relayed to users using assistive technology and the sighted users. 
  • You should check the flow of information, ensuring that it is logical much like the tabbing order in keyboard accessibility. 
  • You should see that all your links make sense; something like ‘click here’ won’t really help the screen reader user. 
  • Finally, you should ensure that all the images have alternative text describing them in a clear and concise way. 

Conclusion 

Web accessibility has become quite popular today. If you adhere to the W3C’s guidelines on accessibility, you could achieve wonders for your brand image and enhance your consumer base to a great deal. However, if you do not, your image would downgrade and so would your revenue. The aim of accessibility should be to create a web project that is accessible to someone without any disability, someone with a physical disability and someone with cognitive disabilities on an equal without a shadow of bias.

Accessibility features in Drupal are so comprehensive and whole that they would not let the latter outcome be even an option. I have tried covering all of Drupal’s accessibility modules and tools and I really hope that you will take a note of them and build a project that gets universal attention. Good luck!

Apr 06 2021
Apr 06

It seems that with each passing year there is a new paradigm for how content can be arranged and organised in Drupal. Over the years a number of approaches have moved in and out of being in vogue: Panels, Displya Suite, IPE, Bricks and Paragraphs to name a few. Some change has been positive, providing leaps forward in flexibility or control. Other developments have not lived up to their promise.

In February 2021 I presented a new module, Layout Paragraphs, to the Sydney Meetup. The slides and video have been provided below. This presentation demonstrates Layout Paragraphs in action and how offers some advanced layout options for Paragraphs. Conceptually it is similar to Layout Builder in many respects, however, it performs its magic on the Node Edit page, integrating with the natural content editing environment for site editors.

Layout Paragraphs offers a new way forward for the following reasons:

  • Editing happens on node edit, rather than the layouts page. Better for editors.
  • Paragraphs can be placed into Layout regions to bring more flexibility to Paragraphs. This is similar to what Bricks was doing.
  • Nicer UI for Paragraph selection.
  • Nicer UI for Paragraph display - no need for Preview view mode any more.

A bit of history

It is worth reviewing a little history to see where Layout Paragraphs fits in. The presentation takes a look at some of the popular combinations over the years and gives them over all scores, weighted by functionality and editor experience. Here is a spoiler of what is covered in the video:

Recipe Year Score Pure template 2010 65 Display Suite 2010 58 Panelizer 2012 69 Panelizer and Paragraphs 2014 73 Panelizer and IPE 2016 39 Panelizer, Bricks and Paragraphs 2017 63 Layout Builder and Blocks 2018 70 Layout Builder and Paragraphs 2019 78 Layout Builder, Layout Paragraphs, Paragraphs 2021 81

The scores were calculated from a weighted average of various aspects of the techniques: flexibility, control, editor experience, etc. Watch the video for the details.

Conclusion

You can see that Layout Paragraphs is the latest in the line of approaches and that it is scoring quite well. A recioe based around Lout Builder, Layout Paragraphs and Paragraphs seems to work quite will. Layout Builder remains the domain of the sitebuilder, using it to define the basic layouts for the page. With Layout Paragraphs, a new set of simpler layouts can be used by the editor for their paragraphs.

I think that the approach holds a lot of promise moving forward and it is good enough for Morpht to be considering it as a standard part of our editor toolkit. All up we have found the module to be usable and a definite improvement on editor experience. We are adopting it into projects where we can.

Watch the video and let us know what you think in the comments below.

Watch the video

Apr 06 2021
Apr 06

How does it stack up

Those of you who work with Drupal, you are probably familiar with the combination of using Search API with a search backend such as MySQL or Solr. A pluggable architecture makes Search API a good choice for indexing content in Drupal.

For a long time MySQL and Solr were the popular choices. MySQL was an easy choice as performance was good and results were OK. For those working with large datasets and many concurrent facets, Solr made more sense. Most Drupal hosting companies provide it as a service for this reason. As the search market has matured, other backends have become available, including one for Sajari.

The table below compares these three options and highlights the strengths and weaknesses of each.

Feature Database Solr Sajari

Separate service

No

Built into Drupal.

Yes

Drupal hosting companies provide a Solr as SaaS.

Yes

Sajari is available as a SaaS.

Full text search

Yes

Yes

Yes

Facets

Yes

Yes

Yes

More like this

No

Yes

A useful feature for providing item recommendations based on similarity.

No

Result quality

OK

Good

Very good

Performant

Partial

Slow with many filters over large datasets with facets.

Yes

Yes

Easy install

No

Requires a module such as Search API Database to push data across to Solr.

No

Requires a module such as Search API Solr to push data across to Solr.

Yes

We can configure Sajari in the Sajari UI to run from metadata on the page. Sajari provides an embeddable widget.

We recommend the Search API Sajari module approach.

Search API Integration

Yes

Search API Database module

Yes

Search API Solr module

Yes

Search API Sajari module

Federation

No

No

Yes

A site parameter can be passed into the index for easy filtering.

ReactJS components

No

No

Yes

Interface is faster than Search API as server round trips are not needed.

Result tracking

No

No

Yes

Built-in metrics understand page trends and poorly performing keywords to help you see what searches led your users to individual pages, or which content visitors are searching for but can’t find.

Reporting

No

Reports can be set up in analytics software.

No

Reports can be set up in analytics software.

Yes

Sajari provides logs and charts of search requests.

Autocomplete - suggestions

Yes

Extra module can be installed.

Yes

Extra module can be installed.

Yes

Synonyms

No

No

Yes

Libraries of synonyms can be uploaded via Sajari UI.

Typos

No

No

Yes

Support for misspelled words.

Boosting

Limited

Limited

Yes

Advanced rules can be defined on certain plans.

Machine learning

No

No

Yes

Sajari will learn which results are more or less relevant, promoting the best results to the top.

Pricing

Free

Database comes with Drupal hosting.

Included

Solr server comes built in with typical Drupal hosting.

Free and up

Starts free for smaller sites and then increases.

https://www.sajari.com/pricing

Summary

An easy, low cost search solution.

A more scalable solution with handy features such as “more like this”.

A fast system with smart results helpful for those looking for synonyms, results boosting, tracking and reporting.

Sajari is a viable alternative for clients who are looking for more insights into how their audience use the search on their site and more control over the delivery of the results. This is the case for content driven sites as well as for ecommerce configurations where preferences play a big role.

Integrating Sajari with Drupal

The Sajari Widgets

It is possible to implement Sajari search into any website without the need for the addition of modules or custom code in the backend. Sajari provides a set of widgets which will allow search to operate without the need for much technical knowledge.

Firstly, a Javascript tracking code will allow for “instant indexing”. When a user visits a page, the code fires up and tells Sajari about the page. Sajari can then visit and index the page to update its index. This approach is simple to set up but has its downsides - freshly updated or deleted content will not make it into the index immediately. If this is a concern, then using Search API Sajari, below, would be an alternative.

Secondly, Sajari offers a tool in the admin UI to define a search form and results. It covers things such as the search query, filters, tabs, result counts and result display. It is very easy to configure. The result is a snippet we can embed onto your search page. A set of ReactJS components drive the search and return results in lightning speed, leading to a good experience for users.

Drupal Module: Search API Sajari

For those looking for a tighter integration between their Drupal site and Sajari, it is possible to use their API to push updated content across. The Search API Sajari module , authored by the developers at Morpht, provides a backend to the venerable Search API module  This will update Sajari when content is updated on your Drupal site.

The main advantages of this approach are:

  • Content is indexed instantly, even when no one views it;
  • Deleted content is removed from the index immediately;
  • The tools within Search API allow for the fine tuning of the various fields;
  • There is support for sending a site name across in the result, allowing for federation of results.

Drupal Module: Sajari

The widgets provided by Sajari offer a quick way to get up and running with a search page. However, there are some limitations in the way they work. At the time of writing (early 2021) the widgets did not support the definition of facets.

In order to overcome this shortcoming, Morpht developed a ReactJS library which sits on top of the components provided by Sajari. It has quite a number of configuration options for queries, result counts, filters, tabs and facets. It even has the ability to customise the results through the provision of a callback function which can convert the JSON result to HTML. This code is available at Sajari Configuartor.

The Sajari module makes use of Sajari Configuartor to power the way search is implemented. The module provides a block for defining how the search will operate. The configuration is then passed through to the Sajari Configurator and the UI and results are then shown.

The Sajari module also makes use of the JSON Template module which allows for different handlebars templates to be defined by the themer. These templates can then be selected by an editor during the block creation process. The select template then forms the basis for the callback which is passed into the Sajari Configuartor. The result is that editors can select how to show results. There is no need to alter the ReactJS templates which are in the library.

A recipe

If you are looking to get up and running with Sajari, we recommend this process:

  • Sign up for a free account at Sajari;
  • Set up an initial collection in Sajari, but add no fields;
  • Install JSON Template, Sajari and Search API Sajari;
  • Configure Search API Sajari with your collection details in a new Server;
  • Define your Node Index and assign it to the Sajari server you have just created. The schema will be updated automatically in Sajari with the changes you make in Drupal;
  • Confirm that content is being indexed properly;
  • Add a Sajari search block to your search page and configure it. Be sure to use the correct pipeline and get the field names right;
  • Test the search and confirm it is working.

Conclusion

Sajari is an up-and-coming search provider offering a new breed of search which can utilise human behaviour to improve the results it shows. It's useful for content heavy and ecommerce sites which have a strong need for good search results. There are now integration modules for Drupal to get you up and running with Sajari easily.

Is Sajari right for you?

If you currently have a Drupal site based on a different engine and are interested in what Sajari can offer you, please get in touch with us to discuss it further.

Apr 06 2021
Apr 06

A case study on how we configured GovCMS8 SaaS platform to handle bulk uploads and the assignment of metadata. 

The Attorney-General’s Department supports the technical and content management for several Royal Commissions. A common request is for the timely publishing and management of numerous documents tendered before or at public hearings - 200 documents or more in some instances. With a series of hearings taking place all around Australia, the pressure on the publishing team to manage these loads presents challenges.

The Bulk Upload solution addresses some key requirements:
    

  • Classify and sort documents in one bulk upload process,
  • Manage different file formats of the same document,
  • Run a publishing workflow to gain legal sign off before publishing,
  • Handle the versioning of files when a legal update is required,
  • Display those documents in different views on different pages: hearings, document library, and
  • Make the complex simple and work around limitations.
     
Apr 06 2021
Apr 06

Morpht is located on the traditional lands of the Gadigal people of the Eora Nation as the traditional custodians of this place we now call Sydney. We pay our respects to Elders both past and present and recognise Aboriginal and Torres Strait Islander people as the Traditional Custodians of the land.

Apr 06 2021
Apr 06

Drupal 8 is built on PHP, but using new architecture paradigms that can be difficult to grasp for developers coming from a Drupal 7 background. The Typed Data API lies at the core of Drupal 8, and provides building blocks used throughout the Drupal 8 architecture. In this presentation, Jay Friendly, Morpht's Technical Director, dives into the Typed Data API, what it is, how it works, and why it is so awesome!

Apr 06 2021
Apr 06

Guzzle makes HTTP requests easy. When they work, it's like magic. However, as with all coding, getting something to work requires debugging, and this is where the Drupal implementation of Guzzle has a major usability problem - any returned messages are truncated, meaning that with the default settings, error messages that can help debug an issue are not accessible to the developer. This article will show developers how they can re-structure their Guzzle queries to log the full error to the Drupal log, instead of a truncated error that does not help fix the issue.

Standard Methodology

Generally, when making a Guzzle request, it is made using a try/catch paradigm, so that the site does not crash in the case of an error. When not using try/catch, a Guzzle error will result in a WSOD, which is as bad as it gets for usability. So let's take a look at an example of how Guzzle would request a page using a standard try/catch:

try {
  $client = \Drupal::httpClient();
  $result = $client->request('GET', 'https://www.google.com');
}
catch (\Exception $error) {
  $logger = \Drupal::logger('HTTP Client error');
  $logger->error($error->getMessage());
}

This code will request the results of www.google.com, and place them in the $result variable. In the case that the request failed for some reason, the system logs the result of $error->getMessage() to the Drupal log.

The problem, as mentioned in the intro, is that the value returned from $error->getMessage() contains a truncated version of the response returned from the remote website. If the developer is lucky, the text shown will contain enough information to debug the problem, but rarely is that the case. Often the error message will look something along the lines of:

Client error: `POST https://exaxmple.com/3.0/users` resulted in a `400 Bad Request` response: {"type":"http://developer.example.com/documentation/guides/error-glossary/","title":"Invalid Resource","stat (truncated...)

As can be seen, the full response is not shown. The actual details of the problem, and any suggestions as to a solution are not able to be seen. What we want to happen is that the full response details are logged, so we can get some accurate information as to what happened with the request.

Debugging Guzzle Errors

In the code shown above, we used the catch statement to catch \Exception. Generally developers will create a class that extends \Exception, allowing users to catch specific errors, finally catching \Exception as a generic default fallback.

When Guzzle hits an error, it throws the exception GuzzleHttp\Exception\GuzzleException. This allows us to catch this exception first to create our own log that contains the full response from the remote server.

We can do this, because GuzzleException provides the response object from the original request, which we can use to get the actual response body the remote server sent with the error. We then log that response body to the Drupal log.

use Drupal\Component\Render\FormattableMarkup;
use GuzzleHttp\Exception\GuzzleException;
try {
  $response = $client->request($method, $endpoint, $options);
}
// First try to catch the GuzzleException. This indicates a failed response from the remote API.
catch (GuzzleException $error) {
  // Get the original response
  $response = $error->getResponse();
  // Get the info returned from the remote server.
  $response_info = $response->getBody()->getContents();
  // Using FormattableMarkup allows for the use of

 tags, giving a more readable log item.
  $message = new FormattableMarkup('API connection error. Error details are as follows:
@response
', ['@response' => print_r(json_decode($response_info), TRUE)]);
  // Log the error
  watchdog_exception('Remote API Connection', $error, $message);
}
// A non-Guzzle error occurred. The type of exception is unknown, so a generic log item is created. catch (\Exception $error) {
  // Log the error.
  watchdog_exception('Remote API Connection', $error, t('An unknown error occurred while trying to connect to the remote API. This is not a Guzzle error, nor an error in the remote API, rather a generic local error ocurred. The reported error was @error', ['@error' => $error->getMessage()));
}

With this code, we have caught the Guzzle exception, and logged the actual content of the response from the remote server to the Drupal log. If the exception thrown was any other kind of exception than GuzzleException, we are catching the generic \Exception class, and logging the given error message.

By logging the response details, our log entry will now look something like this:

Remote API connection error. Error details are as follows:

stdClass Object (
  [title] => Invalid Resource
  [status] => 400
  [detail] => The resource submitted could not be validated. For field-specific details, see the 'errors' array.
  [errors] => Array (
    [0] => stdClass Object (
      [field] => some_field
      [message] => Data presented is not one of the accepted values: 'Something', 'something else', or another thing'
    )
  )
)

* Note that this is just an example, and that each API will give its own response structure.

This is a much more valuable debug message than the original truncated message, which left us understanding that there had been an error, but without the information required to fix it.

Summary

Drupal 8 ships with Guzzle, an excellent HTTP client for making requests to other servers. However, the standard debugging method doesn't provide a helpful log message from Guzzle. This article shows how to catch Guzzle errors, so that the full response can be logged, making debugging of connection to remote servers and APIs much easier.

Happy Drupaling!

Apr 06 2021
Apr 06

Background

We live in an age of Drupal complexity. In the early days of Drupal, many developers would have a single Drupal instance/environment (aka copy) that was their production site, where they would test out new modules and develop new functionality. Developing on the live website however sometimes met with disastrous consequences when things went wrong! Over time, technology on the web grew, and nowadays it's fairly standard to have a Drupal project running on multiple environments to allow site development to be run in parallel to a live website without causing disruptions. New functionality is developed first in isolated private copies of the website, put into a testing environment where it is approved by clients, and eventually merged into the live production site.

While multiple environments allow for site development without causing disruptions on the live production website, it introduces a new problem; how to ensure consistency between site copies so that they are all working with the correct code.

This series of articles will explore the Configuration API, how it enables functionality to be migrated between multiple environments (sites), and ways of using the Configuration API with contributed modules to effectively manage the configuration of a project. This series will consist of the following posts:

This article will focus specifically on how developers can manage, declare, and debug configuration in their custom modules.

Configuration Schema

Configuration schema describes the type of configuration a module introduces into the system. Schema definitions are used for things like translating configuration and its values, for typecasting configuration values into their correct data types, and for migrating configuration between systems. Having configuration in the system is not as helpful without metadata that describes what the configuration is. Configuration schemas define the configuration items.

Any module that introduces any configuration into the system MUST define the schema for the configuration the module introduces.

Configuration schema definitions are declared in [MODULE ROOT]/config/schema/[MODULE NAME].schema.yml, where [MODULE NAME] is the machine name of the module. Schema definitions may define one or multiple configuration objects. Let's look at the configuration schema for the Restrict IP module for an example. This module defines a single configuration object, restrict_ip.settings:

restrict_ip.settings:
  type: config_object
  label: 'Restrict IP settings'
  mapping:
    enable:
      type: boolean
      label: 'Enable module'
    mail_address:
      type: string
      label: 'Contact mail address to show to blocked users'
    dblog:
      type: boolean
      label: 'Log blocked access attempts'
    allow_role_bypass:
      type: boolean
      label: 'Allow IP blocking to be bypassed by roles'
    bypass_action:
      type: string
      label: 'Action to perform for blocked users when bypassing by role is enabled'
    white_black_list:
      type: integer
      label: 'Whether to use a path whitelist, blacklist, or check all pages'
    country_white_black_list:
      type: integer
      label: 'Whether to use a whitelist, blacklist, or neither for countries'
    country_list:
      type: string
      label: 'A colon separated list of countries that should be white/black listed'

The above schema defines the config object restrict_ip.settings which is of type config_object (defined in core.data_types.schema.yml).

When this module is enabled, and the configuration is exported, the filename of the configuration will be restrict_ip.settings.yml. This object has the keys enable, mail_address, dblog etc. The schema tells what type of value is to be stored for each of these keys, as well as the label of each key. Note that this label is automatically provided to Drupal for translation.

The values can be retrieved from the restrict_ip.settings object as follows:

$enable_module = \Drupal::config('restrict_ip.settings')->get('enable');
$mail_address = \Drupal::config('restrict_ip.settings')->get('mail_address');
$log = \Drupal::config('restrict_ip.settings')->get('dblog');

Note that modules defining custom fields, widgets, and/or formatters must define the schema for those plugins. See this page to understand how the schema definitions for these various plugins should be defined.

Default configuration values

If configuration needs to have default values, the default values can be defined in [MODULE ROOT]/config/install/[CONFIG KEY].yml where [CONFIG KEY] is the configuration object name. Each item of configuration defined in the module schema requires its own YML file to set defaults. In the case of the Restrict IP module, there is only one config key, restrict_ip.settings, so there can only be one file to define the default configuration, restrict_ip/config/install/restrict_ip.settings.yml. This file will then list the keys of the configuration object, and the default values. In the case of the Restrict IP module, the default values look like this:

enable: false
mail_address: ''
dblog: false
allow_role_bypass: false
bypass_action: 'provide_link_login_page'
white_black_list: 0
country_white_black_list: 0
country_list: ''

 

As can be seen, each of the mapped keys of the restrict_ip.settings config_object in the schema definition are added to this file, with the default values provided for each key. If a key does not have a default value, it can be left out of this file. When the module is enabled, these are the values that will be imported into active configuration as defaults.

Debugging Configuration

When developing a module, it is important to ensure that the configuration schema accurately describes the configuration used in the module. Configuration can be inspected using the Configuration Inspector module. After enabling your custom module, visit the reports page for the Configuration Inspector at /admin/reports/config-inspector, and it will list any errors in configuration.

The Configuration Inspector module errors in configuration schema definitions

Clicking on 'List' for items with errors will give more details as to the error.

The 'enable' key has an error in schema. The stored value is a boolean, but the configuration definition defines a string

Using the Configuration Inspector module, you can find where you have errors in your configuration schema definitions. Cleaning up these errors will correctly integrate your module with the Configuration API. In the above screenshot, then type of data in the active schema is a boolean, yet the configuration schema defines it as a string. The solution is to change the schema definition to be a boolean.

Summary

In this final article of this series on the Drupal 8 Configuration API, we looked at configuration schema, how developers can define this schema in their modules and provide defaults, as well as how to debug configuration schema errors. Hopefully this series will give you a fuller understanding of what the Configuration API is, how it can be managed, and how you can use it effectively in your Drupal projects. Happy Drupaling!

Apr 06 2021
Apr 06

Background

We live in an age of Drupal complexity. In the early days of Drupal, many developers would have a single Drupal instance/environment (aka copy) that was their production site, where they would test out new modules and develop new functionality. Developing on the live website however sometimes met with disastrous consequences when things went wrong! Over time, technology on the web grew, and nowadays it's fairly standard to have a Drupal project running on multiple environments to allow site development to be run in parallel to a live website without causing disruptions. New functionality is developed first in isolated private copies of the website, put into a testing environment where it is approved by clients, and eventually merged into the live production site.

While multiple environments allow for site development without causing disruptions on the live production website, it introduces a new problem; how to ensure consistency between site copies so that they are all working with the correct code.

This series of articles will explore the Configuration API, how it enables functionality to be migrated between multiple environments (sites), and ways of using the Configuration API with contributed modules to effectively manage the configuration of a project. This series will consist of the following posts:

Part 1 gives the background of the Configuration API, as well as discusses some terminology used within this article, and Part 2 describes how the API works, and Part 3 explains how to use functionality provided by core, so they are worth a read before beginning this article. 

Read-only configuration

In some situations, site builders may want to prevent any configuration changes from being made on the production environment, preventing changes that may cause unexpected issues. For example, clients with admin access could log into the production server, and make what they think is an innocent configuration change, that results in unexpected and drastic consequences. Some site builders consider it to be a best practice to prevent configuration changes on the production server altogether, under the idea that only content should be editable on the production server, and configuration changes should only be made in development and/or staging environments before being tested and pushed to production.

The Config Readonly module, allows for configuration changes through the UI to be disabled on a given environment. It does this by disabling the submit buttons on configuration pages. The module also disables configuration changes using Drush and Drupal console.

A configuration form that has been disabled with the Configuration Readonly module

Note: some configuration forms may still be enabled when using this  module. Module developers must build their forms by extending ConfigFormBase for the Configuration Readonly module to do its magic. If the developer has built the form using other means, the form will not be disabled, and the configuration for that form can be changed through the admin UI.

To set up an environment as read-only, add the following line to settings.php, then enable the module:

$settings['config_readonly'] = TRUE;

After an environment is set as read-only, changes to configuration can only be made on other environments, then migrated and imported into the active configuration on the read-only environment.

Complete split (blacklist) configuration

Sometimes configuration needs to exist on some environments, but not exist in other environments. For example, development modules, like the Devel module, or UI modules like Views UI (Drupal core) and Menu UI (Drupal core) should not be enabled on production environments, as they add overhead to the server while being unnecessary since the production server should not be used for development.

A problem arises when configuration is exported from one environment, and imported into the production environment. All the configuration from the source environment is now the active configuration on the production environment. So any development modules that were enabled on the source environment are now enabled on the production environment. In the case of development modules like Devel, this may only add some overhead to the server, but imagine a module like the Shield module, which sets up environments to require a username and password before even accessing the site. If this module is accidentally enabled upon import on production, it will block the site from public access - a disaster!

The solution to this situation is to blacklist configuration. Blacklisted configuration is blacklisted (removed) from configuration upon export. This functionality is provided by the Configuration Split module. This module allows for black-listing configuration either by module, by individual configuration key(s), and/or by wildcard.

Note that more detailed directions for creating blacklists can be found on the documentation page. The following is meant to give an overview of how black lists work.

Blacklists are created as part of a configuration profile. Configuration profiles allow for 'splitting' (a divergence in) configuration between environments. Profiles may be created for environment types such development, staging and production allowing for configuration specific to those types of environments. Or profiles could be set up for public non-production environments, that would have the Shield module enabled and configured. While a development profile may apply to all development environments, not all development environments are on publicly accessible URLs, and therefore may not need the Shield module enabled.

When setting up a configuration profile, note that the folder name must be the same as the machine_name of the profile.

Configuration split profile settings

Note that you must manually create the folder specified above, and that folder can and should be tracked using Git, so it can be use on any environment that enables the profile.

Configuration can then be set up to be blacklisted either by module, by configuration key, or by wildcard:

Complete split (blacklist) can be set by module, configuration key, or by wildcard

Finally, environments need to be set up to use a given profile. This is handled by adding the following line to settings.php on the environment:

$config['config_split.config_split.PROFILEMACHINENAME']['status'] = TRUE;

Where PROFILEMACHINENAME is the machine_name from the profile you created.

Although blacklisted configuration does not become part of the exported archive, it is not ignored altogether. When an environment has the profile enabled, upon export, blacklisted configuration is extracted, then written to the folder specified in the profile. The remaining configuration is written to the default configuration directory. When importing configuration, environments with the profile enabled will first retrieve the configuration from the default configuration directory, then apply any configuration from the folder specified in the profile. Environments not set up to use the profile ignore the configuration in the blacklisted directory altogether on both import and export.

This means that a developer can enable the Devel module on their local environment, blacklist it, then export their configuration. The blacklisted configuration never becomes part of the default configuration, and therefore the module will not accidentally be installed on environments with the configuration profile enabled.

Conditional split (grey list) configuration

Grey lists, also provided by the Configuration Split module, allow for configuration to differ by environment. With a blacklist (previous section), the configuration only exists in the active database configuration for environments that are set up to use the configuration profile containing the blacklisted configuration. With a grey list, the configuration exists in the active configuration in all environments, but the configuration profiles can be set up to allow environments to use differing values for the configuration.

Imagine an integration with a remote API requiring a username, password, and endpoint URL. The production server needs integrate with the remote API's production instance, while other environments will integrate with the remote API's sandbox instance. As such, the values to be used will differ by environment:

Production Environment:

remoteapi.username: ProductionUsername
remoteapi.password: ProductionPassword
remoteapi.endpoint: https://example.com/api

Other Environments:

remoteapi.username: SandboxUsername
remoteapi.password: SandboxPassword
remoteapi.endpoint: https://sandbox.example.com/api

A grey list allows for the setup of these values by configuration profile.

You may be remembering that Part 3 of this series of articles discussed overriding configuration in settings.php, and thinking that a grey list sounds like the same thing. After all, the default values for the sandbox instance of the API could be set up as the configuration values, and the production values could be overridden in settings.php on the production environment, with the same end-result.

The difference is that with a grey list, the remote API values are saved to the configuration profile folder, which is tracked by Git, and therefore can be tracked and migrated between environments. When grey listed configuration is exported, the grey listed configuration is written to the configuration profile folder, in the same manner as blacklisted configuration. When configuration is imported, the default values are retrieved, and the grey list values are used to override the default values, after which the configuration is imported into active configuration.

With the configuration override method using settings.php, site builders need to store the various configuration values somewhere outside the project, communicating environment-specific configuration values to each other through some means, to be manually entered on the relevant environment(s). With a grey list, the configuration values are managed with Git, meaning site builders do not need to record them outside the project, nor communicate them to each other through some other means. Site builders simply need to enable the relevant configuration profile in settings.php, and the environment-specific values can then be imported into active configuration from the configuration profile directory. This means that the sandbox API values can be set up as the values used by default on all environments, and a production configuration profile can be enabled on the production environment using the values to connect to the production instance of the remote API.

Conditional split items can be selected either from a list, or by manually entering them into the configuration profile:

Conditional split (grey list) settings can be selected or manually entered

Finally, note that grey lists can actually be used in conjunction with configuration overrides in settings.php. Grey lists are applied during import and export of configuration from the database. Values in settings.php are used at runtime, overriding any active configuration. So a developer could choose to set up their local instance of the system to connect to an entirely different instance of the remote API altogether by overriding the values in settings.php.

Ignoring configuration (overwrite protection)

Sometimes developers will want to protect certain configuration items in the database from ever being overwritten. For example imagine a site named Awesome Site, with a module that supplies the core of the site, named awesome_core. Since this module provides the core functionality of the site, it should never be disabled under any circumstances, as that would disable the core functionality of the site. In this case, the configuration for this module can be set to be 'ignored'. Any attempts to import ignored configuration from the file system to the active configuration in database will be skipped, and not imported.

Configuration can be ignored using the Config Ignore module. The functionality this module provides is similar to the functionality provided by the Config Readonly module discussed earlier, however the Config Readonly module covers the entire configuration of an environment, while the Config Ignore module allows for choosing configuration that should be protected. This configuration is protected by ignoring it altogether on import.

Configuration can be ignored as follows:

  1. Enable Config Ignore module on all environments.
  2. Navigate to the config ignore UI page, and set the configuration item to be ignored. In the case of preventing the awesome_core module from being disabled, the following would be added:
    core.extension:module.awesome_core Configuration to be ignore is entered one item per line. Wildcards can be used.

This setting will ensure that any attempts to change or remove core.extension:module.awesome_core upon configuration import will be ignored. So if the module is enabled on production, and a developer pushes configuration changes that would uninstall this module, those changes will be ignored, and the module will still be set as enabled after import.

Summary

In this article, we looked at various modules that extend the Configuration API, use cases behind these modules, and how the modules worked. We looked at the Config Readonly module, the Configuration Split module, and the Config Ignore module, and how to use these modules to manage configuration differences between environments. In the next, final fifth part of this series, we will look at configuration management for module developers, and how developers can define the schema for the configuration in modules they develop.

Apr 06 2021
Apr 06

Background

We live in an age of Drupal complexity. In the early days of Drupal, many developers would have a single Drupal instance/environment (aka copy) that was their production site, where they would test out new modules and develop new functionality. Developing on the live website however sometimes met with disastrous consequences when things went wrong! Over time, technology on the web grew, and nowadays it's fairly standard to have a Drupal project running on multiple environments to allow site development to be run in parallel to a live website without causing disruptions. New functionality is developed first in isolated private copies of the website, put into a testing environment where it is approved by clients, and eventually merged into the live production site.

While multiple environments allow for site development without causing disruptions on the live production website, it introduces a new problem; how to ensure consistency between site copies so that they are all working with the correct code.

This series of articles will explore the Configuration API, how it enables functionality to be migrated between multiple environments (sites), and ways of using the Configuration API with contributed modules to effectively manage the configuration of a project. This series will consist of the following posts:

Part 1 gives the background of the Configuration API, as well as discusses some terminology used within this article, so it's worth a read before beginning this article.

Active configuration is in the database

In Drupal 8, configuration used at runtime is stored in the database. The values in the database are known as active configuration. In Drupal 7, configuration was known as settings, and stored in the {variable} table. In Drupal 8, configuration is stored in the {config} table. The active configuration is used at runtime by Drupal when preparing responses.

Configuration is backed up to files

The Configuration API enables the ability to export the active database configuration into a series of YML files. These files can also be imported into the database. This means that a developer can create a new Field API field on their local development environment, export the configuration for the new field to files, push those files to to the production environment, then import the configuration into the production environment's active configuration in the database.

The configuration values in the database are the live/active values, used by Drupal when responding to requests. The YMLfiles that represent configuration are not required, and are not used at run-time. In fact, in a new system the configuration files don't even exist until/unless someone exports the active configuration from the database. The configuration files are a means to be able to back up and/or migrate configuration between environments. Configuration files are never used in runtime on a site.

Configuration architecture

Let's look at the Configuration API on a more technical level, using a real-world example. The Restrict IP module allows users to set a list of rules that whitelist or blacklist users based on their IP address. Upon visiting the module settings page, users are presented with a checkbox that allows them to enable/disable the module functionality.

From a data standpoint, checkboxes are booleans; they represent either a true or false value. When exporting the configuration of a site with the Restrict IP module enabled, the relevant configuration key will be saved with a value of either true or false to a .yml file. Modules are required to define the schema for any configuration the module creates. Developers can look at the configuration schema declarations to understand what file(s) will be created, and what values are accepted.

Modules declare the schema for their configuration in the [MODULE ROOT]/config/schema directory. In the case of the Restrict IP module, the schema file is restrict_ip/config/schema/restrict_ip.schema.yml. This file contains the following declaration:

restrict_ip.settings:
  type: config_object
  label: 'Restrict IP settings'
  mapping:
    enable:
      type: boolean
      label: 'Enable module'

Schema declarations tell the system what the configuration looks like. In this case, the base configuration object is restrict_ip.settings, from the first line. When this configuration is exported to file, the file name will be restrict_ip.settings.yml. In that file will be a declaration of either:

enable: true

Or:

enable: false

When the file restrict_ip.settings.yml is imported into the active configuration in another environment's database, the value for the enable key will be imported as defined in the file.

On top of this, enabled modules are listed in core.extension.yml, which is the configuration that tracks which modules are enabled in a given environment. When the Restrict IP module is enabled in one environment, and configuration files exported from that environment are imported into a different Drupal environment, the Restrict IP module will be enabled due to its existence in core.extension.yml, and the setting enable will have a value of either true or false, depending on what the value was exported from the original environment.

Note that if you were to try to import the configuration without having the Restrict IP module in the codebase, an error will be thrown and the configuration import will fail with an error about the Restrict IP module not existing.

Summary

In this article, we looked at how the Drupal 8 Configuration API works on a technical level. We looked at how active configuration lives in the database, and can be exported to files which can then be imported back into the database, or migrated and imported to other Drupal environments. In part 3 of the series, Using the API, we will look at how to actually use the Configuration API, as well as some contributed modules that extend the functionality of the Configuration API, allowing for more effective management of Drupal 8 projects.

Pages

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web