Tech News

We talk with DrupalEasy Podcast co-founders Ryan Price and Andrew Riley about what we'd want for Drupal Christmas - or maybe what we'd like to see evolve in the Drupal community in time for next Christmas!

• Drupal planet
• Drupal marketing at Web Summit 
• Project browser
• Automatic updates
• Funding project

After we recorded this episode, one of Andrew's wishes was granted! Drupal 10 will be supported until the release of Drupal 12 in mid-late 2026.

Professional module development - 15 weeks, 90 hours, live, online course.  
Drupal Career Online - 12 weeks, 77 hours, live online, beginner-focused course.

Audio transcript

We're using the machine-driven Amazon Transcribe service to provide an audio transcript of this episode.

Subscribe to our podcast on iTunes, Google Play, iHeart, or Spotify. 

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.
 

Recently, Randy Fay of the DDEV project blogged about two new Docker providers available (and supported by DDEV) for MacOS: Rancher Desktop and OrbStack. Both of these join Colima and Docker Desktop as supported Docker providers for DDEV on MacOS. 

I know that I certainly have asked this question - more times than I care to admit. As Randy explains in the blog post:

All of the Docker Providers on every platform (except Linux) are actually wrappers on the open-source Docker/Moby project, which is supported by Docker, Inc.

In other words, in order for DDEV to talk to Docker, it needs a provider. But, not all Docker providers are created equal. Neither Docker Desktop nor OrbStack are open-source - both have free versions (with restrictions); for most commercial use cases, there is a cost involved. Colima and Rancher Desktop are both open-source.

Features vary between Docker providers as well, so it only makes sense that performance differences also exist. Fortunately, Randy has written another blog post summarizing the performance differences between the various Docker providers on MacOS.

tl;dr if you have Mutagen enabled with DDEV, then they're all pretty fast, with OrbStack having the edge.

While Colima is (IMHO) heads-and-tails better than Docker Desktop for Mac, upgrading Colima itself has been a bit of a rocky road. I have learned to never assume that my databases will remain intact during a Colima upgrade. This usually isn't a deal-breaker, but for me, it is squarely in the inconvenience category.

I'm hoping that the situation is smoother with Rancher Desktop.

As I (currently) use DDEV on MacOS with Colima (and Mutagen enabled,) I decided to give Rancher Desktop a try, as it is an open-source option. 

Using the instructions provided by the DDEV project, I downloaded Rancher Desktop from the official site. A bit surprisingly, the recommended installation method was not Homebrew, but rather a bit of an old-school MacOS .dmg file.

After downloading Rancher Desktop (but before installing it,) the steps I took to install and change over from Colima began with:

Next, I double-clicked to install Rancher Desktop - making sure to uncheck the "Kubernetes" checkbox as the DDEV instructions suggested. I didn't touch any other settings during the Rancher Desktop install.

Once that was installed, I restarted my Terminal app, then navigated to one of my DDEV projects.

If you haven't used it before, the docker context use rancher-desktop bit basically tells Docker which provider to use. In other words, you can have multiple providers installed (like I do with Colima and Rancher Desktop) and switch between them using the docker context use command.

With that, installation was complete. 

In short: uneventful (in a good way)

I didn't have any issues at all - it all went very smoothly. From a performance standpoint, Drupal 10 sites feel a little bit snappier than with Colima, but this is purely qualitative, not quantitative. 

When switching Docker providers, while project code isn't touched, unfortunately, project databases don't automatically come along. In his blog post, Randy suggests using ddev snapshot --all as an initial step in the process to back up all databases. I tend to take a more piecemeal approach - individually exporting databases while using Colima, then importing them while using Rancher Desktop. For example, here's my process for moving a database from Colima to Rancher Desktop (assuming my system is currently using Rancher Desktop):

Granted, it's a bit wordy, but it works for me.

At the present time, I have no plans to test-drive Orbstack. While Randy's blog post does indicate I would experience a minor performance boost, at this time, I'd rather just stick with an open-source solution.

One of our Professional Module Development course graduates, Jay Volk, recounted his recent experience with Orbstack:

My experience is that OrbStack is really fast and while not open source (it's $8/mo.) it seems well worth the cost and I'm happy to support this project.  Orbstack will take your existing Docker settings and move them to Orbstack when starting up (it asks your permission.) This proved to be no problem for DDEV but occasionally causes problems with the other solution I sometimes need, Lando.  Easy enough, Docker can reclaim settings back from OrbStack and with a Docker restart you're good to go again with that (albeit slower) solution.

I wrote the first draft of this blog post about 2 weeks ago - since then I've stuck with Rancher Desktop and have no plans to go back to Colima. I'm pretty sure the performance is a bit better than Colima and I've had absolutely zero issues. The real test (for me at least) will be when it comes time to update Rancher Desktop - assuming it is a smooth experience, I doubt I'll be returning to Colima. 

Header image generated by ChatGPT-4 using the prompt: "Create a cartoon image of a cowboy lassoing a giant laptop computer using 2:1 aspect ratio". If someone could identify the two flying objects to the right of the laptop, I'd be most appreciative.

We talk with Luca Lusso, author of Modernizing Drupal 10 Theme Development, published in August, 2023 by Packt Publishing. 

• Modernizing Drupal 10 Theme Development book
• WebProfiler module
• Storybook 
• Single Directory Components (SDC)
• Google Lighthouse

• Professional Module Development - 15 weeks, 90 hours, live, online course.  
• Drupal Career Online - 12 weeks, 77 hours, live online, beginner-focused course.

Audio transcript

We're using the machine-driven Amazon Transcribe service to provide an audio transcript of this episode.

Subscribe to our podcast on iTunes, Google Play, iHeart, Amazon, YouTube, or Spotify. 

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Podcast edited by Amelia Anello.
 

We talk with Andy Giles about GitHub Copilot and his experience with it in Drupal development.

• GitHub Copilot
• Visual Studio Code extension 
• PhpStorm plugin
• Official Microsoft video on getting started with GitHub Copilot in Visual Studio Code 

Professional module development - 15 weeks, 90 hours, live, online course.  
Drupal Career Online - 12 weeks, 77 hours, live online, beginner-focused course.

Audio transcript  

We're using the machine-driven Amazon Transcribe service to provide an audio transcript of this episode.

Subscribe to our podcast on iTunes, Google Play, iHeart, Amazon, YouTube, or Spotify.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Podcast edited by Amelia Anello.
 

We talk with Kevin Quillen, author of Drupal 10 Development Cookbook, published in February, 2023 by Packt Publishing. 

• Drupal 10 Development Cookbook 
• Open AI / ChatGPT integration module
• Velir 
• Kevin's blog 
• Drupal Test Traits 
• Drush's generate command 

• Professional module development - 15 weeks, 90 hours, live, online course.  
• Drupal Career Online - 12 weeks, 77 hours, live online, beginner-focused course.

Audio transcript 

We're using the machine-driven Amazon Transcribe service to provide an audio transcript of this episode.

Subscribe to our podcast on iTunes, Google Play, iHeart, Amazon, YouTube, or Spotify.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Podcast edited by Amelia Anello.
 

We talk with Jim Birch about the Recipes strategic initiative for Drupal. 

• Distributions and Recipes strategic initiative 
• Core patch to test recipes
• Config actions contrib module
• NEDCamp presentation on Recipes from Erik Volkernick
• Roadmap
• #distributions-and-recipes Slack channel 

• Professional module development - 15 weeks, 90 hours, live, online course.  
• Drupal Career Online - 12 weeks, 77 hours, live online, beginner-focused course.

Audio transcript 

We're using the machine-driven Amazon Transcribe service to provide an audio transcript of this episode.

Subscribe to our podcast on iTunes, Google Play, iHeart, Amazon, YouTube, or Spotify.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Podcast edited by Amelia Anello.

A very special episode of the DrupalEasy Podcast - an episode two years in the making.

I was recently reminded of a Drupal core feature that I hadn't used in a long time - and was pleasantly surprised at how useful it is.

The Combine fields filter Views filter allows a site-builder to quickly and easily set up an exposed filter that searches multiple fields for a given search term. Think of it as a way to combine multiple exposed search filters into a single search box.

Setting it up is quite easy - just include all the fields that you want to search in the Fields section, marking them with Exclude from display as necessary (Unfortunately, Combine fields filter doesn't work with view modes.)

Then, add and expose a Combine fields filter to the view, and configure it to use all the fields you want searchable in the Choose fields to combine for filtering section of the filter's configuration:

I created a simple example of a Movie content type with example fields including Title, Image, Plot summary, Spoilers, Year of release, Short description, Taglines, and Trivia. I added all of these fields to the Fields configuration of the view - with all of them hidden except for Title and Image.

Next, I added a Combine fields filter as described above, selecting all of the fields to be combined for filtering. Finally, I added a few sample Movie nodes.

To test things out, I searched for terms that were added as part of the various Movie content type fields (but purposely not words in the Title fields). The results were exactly what I was expecting!

There are a few caveats when using Combine fields filter with one of the more impactful being that when utilizing a multivalued field (as the Trivia and Taglines fields are in the previous example), the Multiple field settings configuration cannot utilize the Display all values in the same row option. Fortunately, these fields are usually excluded (hidden) from search views like this. 

While preparing the recent Markdown Easy 1.0.1 release, I utilized a couple of tools that I hadn't used before in order to help improve code quality as well as the quality of the release notes.

cspell is a Node.js spell-checker for code that was made available to the default Drupal GitLab templates in February, 2024. There is a new SKIP_CSPELL variable that can be set if you'd like your project to completely ignore cspell (it is enabled by default.) Documentation on using cspell in Drupal GitLab pipelines is available. I'd wager that most Drupal contrib maintainers will have the need for a custom word list (as I did,) so I took a few minutes to learn a bit more about it.

Cspell uses its default wordlist along with a few add-on dictionaries related to Drupal development (anecdotally, words like "mglaman," "gloop," "skynet," and "vampirize" are included) for checking the spelling of both variable names as well as code comments, but luckily, additional words (and patterns) can be added on a per-project basis in order to achieve a clean cspell report in GitLab pipelines. While there are several methods to add a list of custom words, the way I felt was most elegant (and easy for me to remember in the future!) was to add a .cspell-project-words.txt file on the project root (in this case, the contrib module is the project.) This file then includes a list of words that cspell should not flag as misspellings. For the Markdown Easy project, I went with "Anello," "~commonmark," and "~ultimike" (possibly for obvious reasons.) The ~ modifier indicates those words are case-insensitive (additional modifiers are available.) With that change, Markdown Easy now earns a passing score from the cspell pipeline. 

drupalorg is a command-line interface maintained by (who else?) Matt Glaman. I actually learned about this tool a few years ago after Matt blogged about it, but for whatever reason, I only thought about installing and (finally) using it recently. The general idea is to provide a command line tool for contributors to interact with drupal.org. It's available commands are:

The maintainer:release-notes command is especially helpful to automatically generate release notes for a new version of a Drupal contrib project. Here's how I installed and used this tool to generate the release notes for Markdown Easy 1.0.1:

1. I downloaded the drupalorg.phar to a new ~/sites/drupalorg/ directory on my local, and renamed the file to just drupalorg.
2. I then gave execute permission to this file via chmod u+x ~/sites/drupalorg/drupalorg

3. I use zsh, so I added the following to my ~/.zshrc file and then restarted my terminal:

   # drupalorg command line tool export PATH="/Users/michael/sites/drupalorg:$PATH"
4. Here's the important part - I then navigated to my local, working copy of the Markdown Easy module. In my case cd ~/sites/d10/web/modules/contrib/markdown_easy 
5. I then ran the following command to generate the release notes: drupalorg maintainer:release-notes 1.0.0  

I assumed at first that I should use the current release (1.0.1) as the argument, but after reading the documentation, I discovered that the command will generate release notes from the tag provided in the argument.

I also originally assumed that the command would take a contrib module's machine name as an argument, but after a few minutes of poking around the documentation, I realized that the command must be run from the module's directory.

You can see the automatically generated release notes here.

Both of these tools were rather easy to implement (once I read just a little bit of documentation) and seem like they'll be useful for just about any Drupal contrib maintainer. 

Image used with permission from Michael Richardson from Ironstar.io.

I took a lot away from DrupalCon Portland 2024, and while one of my lasting memories from the main keynote (the Driesnote) will be the introduction of Starshot, something that has occupied a good amount of space in my brain is what happened just prior to Dries’ Starshot announcement.

At the start of his presentation (the 21:15 mark of this video,) Dries asks everyone with at least one year of Drupal experience to stand up. He then asked everyone with less than three years of experience with Drupal to sit down. The results were scary. As Dries reacted:

Oh wow. Almost nobody sat down.

This really shouldn't surprise anyone who has been developing Drupal sites for more than a few years. Drupal 8+ (modern Drupal) was considerably more difficult to get started with, and definitely geared toward more experienced developers.

The 2024 Drupal Developer Survey results were recently announced (thanks to Ironstar.io for the huge effort in making this happen) and while there's a ton of great data in there, I'd like to focus on the Age and Experience section, which shows that only 9.1% of the 648 respondents were under the age of 30, with no respondents under the age of 21 (insert standard disclaimer about survey size and sample and this not necessarily being a scientific survey.) This is troublesome.

Maybe we shouldn't be focusing on age, but rather experience. However; the How long have you been working with Drupal question results didn't make me feel any better. Only 9.6% of the respondents have been working with Drupal for less than 4 years. Yikes.

I really don't know the answer to this question. Both of the data points listed above are somewhat anecdotal. The first can be mitigated by the fact that you're probably much less likely to attend a DrupalCon if you're new to Drupal. The second can be accounted for by the assumption that only folks who are experienced enough with Drupal to be on the right mailing lists and/or follow the right social media accounts would know about the survey in the first place.

All that being said, I don't think the trend that the data is showing us is wrong: Clearly Drupal needs new developers.

Obviously, there's not a single solution. I think there are a few things that we (yes you,) the Drupal community, can do to help entice new developers to Drupal.

1. Keep Drupal's code modern - we do a pretty good job of this, but we can definitely do better by better integrating with front-end developer/designer tools like Storybook and whatever the cool Javascript front-end tools are this month (mostly kidding, of course.) These efforts are critical, but these types of solutions tend to be longer-term.
2. Get more people using Drupal - the more people using Drupal, the more likely they'll become invested in the platform and likely to become full-time Drupal developers. We don't need to convert all Drupal users to developers, just a portion. Clearly, Drupal Starshot is a well-placed effort to do this, but again, I think it'll be a bit of time before this has a significant effect.
3. Create programs that introduce Drupal to students - as a Drupal trainer who is active in the community, I've heard about a few attempts at this in local communities, but nothing at scale. This is definitely a long-term goal, and will take time, money and leadership from the Drupal Association, including a hopefully re-imagined and more ambitious Discover Drupal program. 
4. Entice organizations that build Drupal sites to hire new developers - Money (in this case job opportunities) talks. If there are entry-level jobs in Drupal, then new developers will come. Of course, there are plenty of jobs in Drupal, but not the kind of entry level positions that are going to provide an on-ramp for aspiring Drupal developers. If jobs for those new to Drupal aren't there, then the effect of the first two items above will be muted. There is an exciting, thoughtful short-term solution to this called the Drupal IXP community initiative, which will (hopefully later this year) begin to incentivize organizations to hire new, inexperienced ("IXP") Drupal developers in exchange for Drupal community contribution credits. You can get involved with IXP today by completing this survey to help us figure out which skills a new Drupal developer should have (survey closes June 1, 2024). 
5. Attract good Drupal developer candidates with a leg up  - Companies (like Palantir.net,)  who have become involved in scholarship programs, including (the currently dormant) Discover Drupal (which aimed to not just build the Drupal talent pool, but do it with an eye toward diversifying our ranks,) and providing their own training scholarships, initiating internship programs and providing mentors for newbies have had success in building their talent benches over time by training up the people that are a good fit their organizations. It takes a bit of investment and patience, but the returns are usually worth it.  

If this nagging issue of too few new Drupal developers is becoming a growing concern for you, like it is for me; then perhaps you’d like to get involved in one of the above efforts to help move things forward and, maybe even spread the word to help inspire others to get involved as well.