Tutorials

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

Reposted with permission from Pantheon.io. ## Automating the Process of Keeping Your Local Environment Up-to-date DDEV is a Docker-based local development environment solution that allows developers to run local copies of all their Drupal and WordPress projects in a personal development environment. Much like similar Docker-based solutions, DDEV hides most of the complexity of Docker — allowing Drupal and WordPress developers to focus on what they like best. ## What Problem Are We Solving? One of the typical challenges that a developer faces when working on their local development environment is keeping their local database and content files up-to-date with

Having a basic understanding of caching is a requirement of being a professional Drupal developer. Unfortunately, there can be many layers of caching which can make it challenging to figure out exactly how best to configure cache settings and troubleshoot potential caching issues. Web page caching can be thought of as moats around the castle, where each moat is a caching layer and the castle can be thought of as the site's web, database, and other origin servers. HTTP headers provide a mechanism for the client (usually a web browser) and a server (usually a web server) to exchange information

If you're a Drupal developer who designs information architecture (IA) for your organization and/or clients, then hopefully by now you're thinking in terms of entities, bundles, and fields, not limiting your thinking to only content types. This article isn't going to dive into a lesson explaining what entities, bundles, and fields are as there is plenty of great documentation about that. Back in the Drupal 7 and earlier days, it was common to look at an organization's data and map it almost exclusively to only content types (maybe a few vocabularies as well). With Drupal 8's and 9's Entity API