How We Contributed a Quality-of-Life Improvement to DDEV
We’re big supporters of open-source software at Velir. Over the years, we’ve written extensively about Drupal and implemented lots of Drupal projects. We’ve also contributed many modules and a few vanilla PHP packages to the community.
We recently contributed a change to another open-source project, DDEV. DDEV makes creating local development environments with Docker easy and is our preferred tool for Drupal development.
For a little background on DDEV, you can check out these two articles we wrote on it:
The Problem
DDEV does a great job at auto-networking and the dynamic port assignment of all your Docker services. It also includes a command that will give you a readout of everything that is running for your project, where it’s located, and what network port was assigned:
Each service is listed along with its public URL and the port. If you wanted to access Apache Solr for example, you would type that URL into your browser and add the port (:8983) on the URL.
This is great, but there are some cases where we prefer to have a service accessible by a subdomain without needing a port number (as developers, we must often remember many URLs and port numbers while juggling several projects, so it’s easier when we can avoid using them).
I thought it would be great to access Apache Solr in this example at just a subdomain of solr.(project_name).ddev.site so it’s easier to remember. Since DDEV is built on Docker, it’s simple to pass an environment variable along to change the virtual hostname of a container. You can do that by passing “VIRTUAL_HOST=solr.$DDEV_HOSTNAME” and restarting the DDEV project. However, there was a problem — it would not reflect that change to the user when running the ddev describe command, so it was unclear if anything had changed at all.
The Solution
I began by reviewing the code that ran with the ddev describe command. It became clear that the implementation didn’t account for customization to the “VIRTUAL_HOST” environment variable when building its output, which is why it didn’t reflect the change to the user.
DDEV is written in Go, a language from Google. I had not written any Go before, but the language is designed to be simple and effective. After a couple of hours of reading, I started making code modifications with guidance and encouragement from the project lead Randy Fay, and one of the lead DDEV maintainers, Stas. Before long, I had a working pull request that solved the problem I set out to tackle.
Now, when I run the ddev describe command, the correct URL is displayed:
This will work for any service you want to customize in DDEV. You can see this in the article we mentioned, where we set customized URLs for Next.js websites in DDEV. This small quality-of-life improvement made its way into a DDEV release earlier this summer! Things are certainly busy, but we hope to contribute more to the DDEV project where we can in the future.
Want to know more about how you can leverage DDEV in your Drupal development? Reach out. Our team can share more about DDEV’s benefits and our tips for using it more effectively.
Get the Drupal 10 Development Cookbook
Drupal just released version 11, but if you’re not ready to upgrade yet, you should make the most of the current version by picking up a copy of the “Drupal 10 Development Cookbook.”
The "Drupal 10 Development Cookbook" is co-authored by Matt Glaman and me, Kevin Quillen. We cover a wide variety of topics with hands-on examples so you can get up and running with Drupal 10 in no time. These topics include running Drupal locally with Docker-based tools, content modeling, creating custom modules, how to do automated testing, and migrating data into Drupal from various data sources. The book will help you understand how to develop and build modules just like the ones we talk about often at Velir.