Tutorials

Like many folks, I've been fascinated by the incredible evolution of AI tools in 2023. At the same time, I've been working to figure out exactly where AI fits into my various roles as a Drupal developer, trainer, and business owner. In this blog post, I detail a recent exploration I made into using AI ( GitHub Copilot, to be precise) to generate a PhpUnit test in a Drupal contrib module that I maintain. tl;dr I was impressed. Prerequisites For this exercise, I used Visual Studio Code with the GitHub Copilot extension installed. I am using the Copilot Business plan

As a Drupal module developer, if you're as big of a fan of PHPStan as I am, then you'll no doubt have run across the Unsafe usage of new static() error that PHPStan throws when analyzing code at level 0. In this article I will describe what causes this error and provide four possible solutions, weighing the pros and cons of each.

DrupalPod is a browser extension and GitPod configuration that allows Drupal contributors to quickly and easily spin up a personal development environment in their browser without pre-installing anything. Before we go any further, let's break down some of these concepts a bit more… GitPod is a cloud development platform - meaning that everything necessary for development is installed in the cloud and the only thing that needs to be installed on one's local machine is a modern web browser. Developers can customize their cloud development environments virtually any way they see fit depending on the nature of their project. GitPod

Earlier this year, the Drupal Association (DA) and various community contributors announced the general availability of GitLab CI (Continuous Integration) for Drupal contributed modules . The goal of this project is to replace the existing, bespoke, Drupal CI for running automated tests for both Drupal core and contributed projects with GitLab's existing CI tools, thus saving community and DA resources in the long-term. For contributed module maintainers, this means being able to specify more flexible tests and code validations, depending on the module's unique needs. Much of this functionality will be made readily available to module maintainers via GitLab templates

Over the past few years, we've published a couple of blog posts about setting up Xdebug for Drupal module development. But, like all things in tech, there's always more to learn as tools and technology evolve. The setup I was recently working with one of our Professional (Drupal) Module Development students trying to determine why she wasn't able to use Xdebug to debug a PhpUnit-based functional test. To be clear, the breakpoint wasn't set in the actual test class, the breakpoint was set in some custom module code that was called by the test class. In functional tests, Guzzle is

Introduction If you use Visual Studio Code and DDEV, there's a new extension that may increase your efficiency. The DDEV Manager extension provides a user interface within Visual Studio Code for just about every conceivable DDEV command. As I am a user of both tools, and I often teach and present on the topic of maximizing one's efficiency related to Drupal development when using DDEV and Visual Studio Code, a thorough review of this new extension was a no-brainer for me. Installation Installation of the extension is typical of any other Visual Studio Code extension - from the "Extensions" sidebar

I've been a big fan of the Termcase module for a long time - it is my go-to module for sites that employ free-tagging taxonomies. Termcase allows site-builders to force consistency on tag names (all lowercase, all uppercase, first-letter uppercase, etc…) It's one of those modules that I was surprised that not everyone used (or had even heard of.) While working to update a Drupal 9 site that uses Termcase to Drupal 10, I became curious if free-tagging was still a commonly-used technique on modern Drupal sites. In an effort to satisfy my curiosity, I performed a 100% not scientific

I learned a valuable lesson last week. First, some context. One of DrupalEasy's clients is a large international industry association that is currently running a large Drupal 9 site with about a dozen custom modules and well over 150 contributed modules. We were brought onto the project a couple of years ago to do some custom module development, but until recently weren't all that involved in the overall site maintenance and development. As part of a recent task we've been working on, I stumbled on an issue that was occurring only on my local, and not in a way that

Ever since it was announced, I've been itching to play with the new OpenAI / ChatGPT / AI Search Integration contrib module. From what I had read about it from Kevin Quillen , it was being written in a way that was going to make it flexible and with an eye toward customization. On a self-serving note, one of our clients is interested in an AI-based solution for a task we're working on for them, so I had an agenda; test-driving this module for content-related tasks. My initial impressions came from using version 1.0.0-alpha10 and within the first 20 minutes

A client recently asked me to figure out how to allow additional authors to not only be listed on a single node, but also to let them have the same edit and delete permissions as the main author of the node. I thought it might be helpful to put together an article that details one potential solution to this not completely uncommon task. This is not something I have implemented in any modern version of Drupal (8, 9, or 10), so I took a fresh look at the problem by reaching out to my Drupal network via Slack and social

When writing Drupal custom modules, best practice dictates that the module should be written in the project root's /modules/ directory - so that composer require can be used add the custom module as a dependency to the project (with a little help from the composer/installers plugin, of course). In most cases, the module's code is then symlinked from the /modules/ directory to the /web/modules/custom/ directory. One potential pitfall of this approach is that both PhpStorm and Visual Studio Code will see both the "copies" of the files in the custom modules, leading to duplicates in IDE search results, code quality

This article is a slightly-edited excerpt from DrupalEasy's 90-hour Professional Module Development course. When writing a custom Drupal module that requires authentication with a 3rd party service, many new developers struggle with finding an easy and secure method to store the API keys. Storing API keys in the database is usually not a good idea - nor is hard-coding them or saving them in the files directory 😱 A better solution would be to store the credentials outside of the docroot - which is a more secure location. When using this method, if possible, it is recommended to not commit

Most folks in the community who are responsible for maintainting Drupal sites know that it’s important to keep them up-to-date with bug fix and (especially) security updates for both Drupal core and contributed modules. But what about the tools we use every day to build and maintain all those Drupal sites? As a general rule, I don't recommend updating things when you are near a task deadline, so as a new year begins, this might be a good time to take a look at your development tools and get things updated. This process can lead to improved performance, add new

Most Drupal back-end developers, regardless of their skill level, have at least a passing knowledge of the role of services.yml files in Drupal development. While writing the curriculum for our upcoming, long-form Intermediate Module Development course, we realized that it only makes sense that we provide not only the purpose of a services.yml file when writing custom service classes, but also the role of both the sites/development.services.yml file and the sites/default/default.services.yml files. If you are already familiar with the process for creating a custom service class, then you know that the module_name.services.yml file serves to not only define the service

Back in March, 2022, the DDEV team announced support for Colima, an open-source Docker Desktop replacement for Mac OS X. Based on the fact that Colima is open-source, Docker Desktop's new license terms, and the apparent performance gains of using Colima it seems like a no-brainer to give it a spin. First off, it's almost a drop-in replacement for Docker Desktop. I say almost for one reason, as any existing DDEV projects will need to have their databases reimported. In other words, if you have an existing project up-and-running in DDEV, then add Colima, then restart the project, your database