DrupalEasy Tutorials, News, Quicktips, Video, and Podcasts.

The challenges of launching the Drupal IXP program at this moment in time

drupaleasy@gmail.com (Michael Anello) — Mon, 09 Jun 2025 06:27:20 -0400

The Drupal IXP program officially launched a couple of months ago, marking a significant step in our community's effort to build future talent. Modeled after traditional apprenticeship approaches (with the Drupal-y twist of 250 contribution credits,) the program aims to connect newcomers at the beginning of their Drupal journey with organizations willing to hire and mentor them. While the initiative is poised to address a critical talent gap, its launch occurs during a challenging period for the Drupal community, prompting a reflection on the timing and rationale.

A challenge, and an opportunity

The primary challenge is the current landscape where many experienced Drupal developers are suddenly seeking employment. It is not unreasonable to assume that some percentage of these people will find non-Drupal jobs. Combine this potentiality with the fact that the Drupal developer community is getting older and that fewer and fewer new Drupal developers have been joining us suggests a long-term need for new talent. The single goal of the IXP program is to cultivate new Drupal developers so that we can maintain a community hearty enough to carry Drupal Core and Drupal CMS into the future.

Despite the external market conditions, the decision to launch the IXP program now was driven by the significant volunteer effort and organizational support from the Drupal Association. It just didn't make sense to not launch the program with the pending need so great, and while it had momentum. The program has reached a stage where it is ready to provide tangible opportunities for newcomers and benefits for participating organizations.

Advantages for new developers and businesses

The IXP program focuses on individuals with less than three months of paid Drupal experience, specifically targeting that crucial transition point between learning and professional practice to bridge the gap between learning Drupal and securing the first professional role. It serves as a structured pathway and a "safe learning environment" to help new developers navigate this complexity and build their skills under the guidance of experienced mentors. By providing paid experience in real-life use cases with structured mentorship (at least one hour of mentorship for every ten hours worked,) the program directly addresses the difficulty newcomers face in gaining practical experience.

IXP developers are expected to have knowledge about Drupal (either gained on their own or via courses like Drupal Career Online or Professional Module Development) - the program isn't asking hiring organizations to provide basic Drupal knowledge.

For businesses, hiring new Drupal developers through the IXP program presents potential advantages including the fact that they are not entering the workforce with the same level of expertise or salary expectations as seasoned developers. The program allows organizations to shape talent according to their specific practices and needs, representing a strategic investment in future talent. IXPs gain paid work experience and build a portfolio, while organizations benefit from fresh perspectives and enthusiasm.

IXPs can also be a low-cost way for organizations to invest in learning about and leveraging new developments in the Drupal community, including Drupal CMS as well as Drupal AI modules and techniques. Other potential tasks that IXPs can perform for hiring organizations include Drupal core and module updates, Drupal site-building, and quality assurance. These tasks can be foundational for various projects, including those potentially for smaller clients.

Make the choice

Yes, launching the Drupal IXP program now comes at a time with challenges. However, we really can’t afford putting off such a sound solution to address the long-term health of the community by creating structured pathways for new talent. Supported by a dedicated community of volunteers as well as the Drupal Association, we reached a point where launching was the necessary step to start building the future talent pipeline, offering paid experience and mentorship to new developers while rewarding organizations for their investment in the ecosystem.

If you're a hiring organization and want to get involved, start here.

AI was used for the initial outline of this blog post.

Drupal Back-to-Basics - looking for a leader

drupaleasy@gmail.com (Michael Anello) — Tue, 27 May 2025 13:39:09 -0400

In early April, 2025, I was a guest on the Talking Drupal podcast discussing Back-to-Basics, an idea I had to get more beginner-level presentations at Drupal events as a way to better support (and retain) our newer community members. As I am currently a bit overcommitted, this, regretfully, is not something that I have the bandwidth to lead.

I do feel that the idea, and getting it up and running as soon as possible, is a good one that can contribute greatly as one solution to the declining pool of Drupal developers that will sustain us into the future. So, here is my call: I am looking for someone inspired by the growing need to attract and retain Drupal newbies who is interested in taking the lead with the idea, adding their flair, and moving it forward.

As an incentive, know that I've talked with plenty of people who are willing to help, including the folks from the Drupal Open University Community Initiative. In addition, I'm more than willing to provide assistance, make introductions, and help where I am able to ensure success.

Genesis

The idea for Back-to-Basics came from one of our Drupal Career Online alum during our weekly office hours. It was shortly after Florida DrupalCamp 2025 that the alum asked me if "there were any good Views-related sessions" from the event that they could watch. The answer was "no," unfortunately, and over the next few days this bugged me more-and-more. How are we expected to grow the community with new developers and contributors if our events offer little-to-nothing for them?

Goal

The goal of Back-to-Basics is to make it easy for Drupal event organizers to include solid beginner content for their new-to-Drupal attendees. The strategy makes available 6-8 Drupal pre-prepped event presentations that can be delivered by a vetted pool of experienced Drupal presenters. The presentations will be readily available to any Drupal event organizers along with the names of willing presenters.

A sustainable solution

As a developer of curriculum, I know how challenging and time-consuming it can be to not only develop, but also (and, perhaps, more importantly) maintain training materials. Creating, maintaining and then donating 6-8 45-minute Drupal event presentations is a big ask. However, It also occurred to me that finding 6-8 Drupal trainers and organizations who would be willing to create and/or donate and maintain a 45-minute presentation in exchange for some promotion makes a bit more sense. This was quickly validated by the first 4 trainers that I spoke with.

The final element is ensuring that the actual presentations serve to not just educate, but inspire. It is critical then, that every presentation should be delivered by the best presenters available at each event. As the old adage says, we have only one chance to make a first impression. The most experienced Drupal developers and presenters providing beginner content is the kind of impression we want to make to newer Drupalists whom we want to get excited about Drupal. It just feels right. Again, this idea was validated by every single one of the experienced presenters I approached.

Challenges

I have identified two main challenges that will need to be overcome:

Available presentation slots at Drupal events. Not many Drupal events have the luxury of open rooms or slots in their schedule. Putting some priority on these beginner sessions would need to be part of the event planners’ insights in that it would not only be in our community's long-term interest, but contribute to growth of their event in the future, if they made room for beginner content.
Presenter/session selection. Presenters who participate in the Back-to-Basics program (or develop their own) shouldn't be penalized for presenting beginner-level content when it comes to session selection. If the maintainer of a core subsystem wants to present beginner-level content, that shouldn't count against them if they are proposing an advanced session as well, in the normal flow of session selection for the same event.

Is building Back-to-Basics your bailiwick?

If you are inspired, and considering making a go of leading the charge on this, I am sure you have some ideas on how to proceed. Some fuel for thought; here are the basics of what I envision you'll need to do:

Reach out to Drupal trainers to confirm their participation. (I can help with that!)
Determine the list of 6-8 beginner-level topics that should be covered (the Open Curriculum folks can help with this!)
Develop guidelines for presentation slide decks, including promotion guidelines and common slides.
Figure out where the presentations will be stored.
Develop the list of Back-to-Basics presenters.
Develop an informal written agreement with trainers for presentation maintenance.
Work with the Drupal Event Organizers working group to help spread the word.

I'm sure you have more ideas to enhance the program, (like nifty t-shirts) and there will surely be some additional tasks as well, but I think this list covers the big ones.

Finally, know that I envision my role as that of a mentor for whoever decides to take this on. I'll be more than happy to provide guidance, answer questions, and make introductions.

Interested? Have questions? Connect with me (ultimike) on the Drupal Slack workspace or use our contact form.

Choosing the right modern Drupal Bootstrap base theme

drupaleasy@gmail.com (Michael Anello) — Wed, 07 May 2025 15:18:05 -0400

A high-level comparison of some of the most-widely used Bootstrap framework-focused base themes, including feedback from some of their maintainers.

With more than 150 Bootstrap compatible Drupal 10 contributed themes on Drupal.org, selecting the best Bootstrap-powered base theme for you, your development team, and your project can sometimes come down to a superficial popularity contest. The lack of a clear comparison between the most widely-used and/or most well-known options is frustrating.

Rather than attempting the futile task of comparing all 150+ themes, based on my experience and conversations, I have selected the six (of what I consider to be) leading Bootstrap 5 compatible base themes for this task.

As someone who is not a dedicated front-end or theme developer, but is somewhat comfortable with the Bootstrap framework, I've used several of the options included in this comparison. This very site uses the Bootstrap base theme, our DrupalEasy Academy curriculum site and the Drupal Career Online theming lessons uses Bootstrap Barrio, and our Single Directory Component workshop utilizes Radix.

Despite my experience with several of the Bootstrap 5-powered base themes, I still didn't have a clear understanding of which one I should use or recommend based on different projects and teams. Gaining clarity in this area is the goal of this blog post.

In addition to my own experiences and research, I also contacted the most active maintainer(s) of each base theme and asked each to provide some feedback about their projects.

The base themes I decided to compare in this blog post were based on previous experiences, usage numbers on drupal.org and comments on a social media post about this topic that I posted in early April, 2025.

*Note: It is not lost on me the potential confusion between the three base themes with "Bootstrap" in their name!

Name	Latest release	Usage	Commits*
Artisan	2.0.0-alpha2 released 7 May 2025	196	36
Bootstrap	5.0.1 released 16 September 2024	98,505	0
Bootstrap 5	4.0.3 released 7 August 2024	19,504	0
Bootstrap Barrio	5.5.19 released 6 December 2024	39,844	0
Radix	6.0.1 released 18 January 2025	8,682	38
UI Suite Bootstrap	5.1.0-beta1 released 9 April 2025	259	35

*Commits on current release branch in 2025

From the data above, it is clear to see that Bootstrap has (by far) the most usage, half have had a release in the last six months (November 2024 - April 2025,) with the other half having no commits on the listed branch in 2025 yet.

Front-end tools

One of the first things I do when evaluating a base theme is to take a look at how they handle CSS compiling. Generally, this falls into one of three categories:

no built-in support (meaning the base theme is primarily designed for CSS, not Sass)
Sass files provided along with CSS compilation tools (usually in the form of a package.json file)
Sass files provided, but un-opinionated about compiling CSS (meaning it is up the developer)

Note: a developer or team's front-end tool chain can take many different forms, so this section is mostly geared towards folks not comfortable setting up their own toolchain.

For our contenders, here's what I found:

Artisan: recommended subtheme includes Sass files and package.json featuring Laravel Mix.
Bootstrap: provides both a CSS-only subtheme and a Sass-based subtheme that includes a package.json featuring Gulp.
Bootstrap 5: recommended subtheme includes Sass files and a package.json file.
Bootstrap Barrio: provides both a CSS-only subtheme and a Sass-based subtheme that includes a package.json featuring Gulp.
Radix: recommended subtheme includes Sass files and package.json featuring Laravel Mix and BiomeJS
UI Suite Bootstrap: recommended subtheme includes Sass files

Single directory components

With the Drupal community's love affair with single directory components (SDCs) not looking to wane anytime soon, it is becoming more-and-more common for base themes to include a useful set of components that can be utilized.

Ideally, (IMHO) SDCs should be entirely self-contained, not relying on libraries or Sass source files that don't reside in the SDC. Unfortunately, this is not always possible, but it is something that I definitely consider when doing my evaluation. Here's how our contenders incorporate SDCs:

Artisan: includes components both in base theme and recommended subtheme
Bootstrap: includes components in base theme
Bootstrap 5: no components included
Bootstrap Barrio: includes components in base theme
Radix: includes components in base theme
UI Suite Bootstrap: includes components in base theme

Drupal's Appearance theme settings

I honestly didn't consider this aspect until one of the base theme maintainers I interviewed mentioned it. Some base themes expose a lot of configuration options through Drupal's Appearance admin UI settings pages and some do not. Different theme developers might have different preferences - often those newer to theme development (or those for whom it is not a full-time job) prefer more configuration options exposed in the Drupal admin UI.

Artisan: Many configuration options including colors, fonts and column widths. Many configurations utilize CSS variables.
Bootstrap: Some configuration options including Color module and Bootswatch integration.
Bootstrap 5: Few configuration options.
Bootstrap Barrio: Many configuration options including Bootstrap grid classes.
Radix: Very few configuration options.
UI Suite Bootstrap: Very few configuration options.

Documentation

For base themes, I find that a little bit of documentation goes a long way. I don't expect base theme contributors to document every single possible use case, but I do hope that enough documentation exists for a developer to understand the theme's pros and cons and provide enough step-by-step instructions to demonstrate (with examples) best practices when building out a subtheme.

Artisan: Limited to project page and project README file.
Bootstrap: Drupal.org doc pages
Bootstrap 5: Limited to project page and project README file.
Bootstrap Barrio: Many links from project page, but not all are up-to-date
Radix: Dedicated documentation site
UI Suite Bootstrap: Limited to project page and project README file.

What do the maintainers say?

About half-way through my research for this blog post, I realized that without direct experience with all of them (which I do not have,) it would be best if I gave each project's maintainers a chance to provide some feedback.

I contacted the most active maintainer(s) for each project (based on number of commits over the past six months) and asked them the same three questions:

What are the advantages of (your base theme) over other modern Drupal Bootstrap-based base themes?
What are the disadvantages?
Is your base theme designed for a particular level of front-end developer (beginner, intermediate, advanced?)

I considered asking an additional question about how well positioned each base theme is for integration with Experience Builder, but I decided against it as we're still at least 5 months away from its initial release and didn't think it was an entirely fair question.

I received responses from maintainers of Bootstrap, Bootstrap Barrio, Radix, and UI Suite Bootstrap, and have included summaries of each of their responses here.

Artisan

Unfortunately, the maintainer didn't respond to my message.

Bootstrap and Bootstrap Barrio

Alberto Siles (hatuhay on drupal.org) is one of the maintainers of both Bootstrap and Bootstrap Barrio. He mentioned that he took over maintenance of Bootstrap after it was abandoned - originally only to provide updates to it, "but now it depends on the community if they embrace the new code or not." He will continue to maintain both base themes (wow!) and improvements to each will depend on feedback (and help) he receives in each issue queue.

About Bootstrap Barrio's advantages, he wrote, "Long term stability, proven code, but mostly, the theme is designed in a way that makes it easy to upgrade in both Bootstrap and Drupal major versions seamlessly. Now, the code is constantly updated for both Drupal and Bootstrap enhancements, this is also a modern theme in every aspect."

He also mentioned that Bootstrap Barrio is designed for developers of all skill levels, as it is the "subtheme that discriminates. The basic subtheme will let you work with predefined color pallets, Google fonts and other backend configuration and some css, while the Sass version will setup, in minutes, a custom compiled version of Bootstrap."

Bootstrap 5

Vladimir Roudakov (vladimiraus on drupal.org) replied, "Janna (jannakha on drupal.org) and I created the Bootstrap 4 and consequently Bootstrap 5 themes as simple, non-prescriptive, and very flexible Bootstrap themes. At the time, 2020-2021, there were no lightweight Bootstrap-based themes, and the original Bootstrap theme was heavily outdated."

He also mentioned that this base theme is geared towards intermediate-level developers and requires "minor tweaking for Sass setup."

Radix

Sohail Lajevardi (doxigo on drupal.org) said that some of Radix's advantages include being one of the first Drupal base themes to include SDCs, the use of modern front-end tools (including Laravel Mix and BiomeJS), its own command-line utility, very good documentation (including YouTube videos), and an effort to minimize Drupal-isms.

Interestingly, he also mentioned that, "I always considered Radix to be a theme and not a configuration vehicle, so we do everything where it needs to be, in the theme. No configuration mix up." I found this an especially interesting contrast to several of the other contenders, notably Bootstrap Barrio and Artisan, both of which utilize a good number of configuration options in Drupal's Appearance settings.

He did mention a disadvantage being "Not easy to understand all the tools and bells of the theme for a newcomer." But he did reiterate Radix's documentation being a solution for this - especially for those new to it.

UI Suite Bootstrap

This base theme is a bit of an outlier, as it is very closely tied to the UI Suite project. I don't have a good handle on how likely it would be for a team to decide to use this base theme if they aren't UI Suite module users as well.

Florent Torregrosa (grimreaper on drupal.org) stressed that this project is a "production ready, design-system-oriented-first theme." He went on to say that together with UI Suite, the base theme provides "tools to allow site builders to configure how they want the design system artifacts (components, styles, Icons, CSS variables, etc.) to fit their business needs. And so we have nothing hardcoded for specific content types or other content entities, bundles, or fields."

Michael Fanini (g4mbini on drupal.org) added that it "packages in one place all Bootstrap specification & designs artifacts (components, style utilities, icons, forms, …) with modern tools from core (SDC, Icon API)" and together with other UI Suite modules provides a no/low-code method for Site-builders to connect Drupal fields to Bootstrap components.

In fact, as I've learned more and more about the UI Suite eco-system of projects, the more it is evident that one of its primary goals is to make it as "design-system-oriented" as possible, as well as prioritize no/low code field-to-component mapping. Much of this means that rather than the Drupal developers providing the Drupal-y templates to the non-Drupal-y front-end developers, it is the front-end developers who provide the components to the Drupal developers to wire to Drupal entities, bundles, and fields. The UI Suite ecosystem maintainers refer to this concept as "inverting the workflow."

As for disadvantages, he notes that its current dependencies on other UI Suite ecosystem modules is less-than-ideal, but as each of the dependencies are at different stages of being added to Drupal core, this is likely a short-term issue.

Conclusions?

Ugh - I figured I'd have to write this section, even though I knew it would not be possible to have a single "I recommend using base theme X" statement. Instead, here's my one-line opinion for each:

Artisan: With so many configuration options, this might be the best option for beginners or lower-budget sites. It is, however, not used by very many sites (yet?) and the documentation could be better.
Bootstrap: Nothing compelling over any of the other contenders.
Bootstrap 5: Less prescriptive than Bootstrap Barrio - could be a solid choice for more intermediate-level theme developers.
Bootstrap Barrio: A comfortable and solid choice for me, despite a few annoyances (probably due to the fact that I currently use this project the most.) But, moving forward, I'd like to see this base theme leading the way into a no-Sass future. (One that utilizes PostCSS instead, perhaps?)
Radix: I'm a sucker for good documentation and do appreciate the opinionated nature of Radix minimizing the configuration options. I like the fact that it is SDC-forward and will definitely consider using this for my next custom theme project.
UI Suite Bootstrap: A very compelling option for those projects that are design-system first. The close ties to the UI Suite of modules could complicate things though. Finally, it's installation requires a few more manual steps than the other contenders.

AI was used in the authoring of this blog post for the social media share image.

Drupal development using Visual Studio Code connected directly to DDEV's web container

drupaleasy@gmail.com (Michael Anello) — Tue, 29 Apr 2025 14:17:12 -0400

As part of DrupalEasy's Professional Module Development (PMD) course, I teach students how to configure an efficient development environment using either DDEV or Lando combined with either PhpStorm or Visual Studio Code. We go rather deep into this topic, often devoting 4-5 hours of class time in getting everyone set up.

As the material is part of our proprietary curriculum for which our clients/students pay tuition , I've been reluctant to share it directly: However, over the past couple of years, the DDEV + Visual Studio Code combination has been more and more common in Drupal development and I've been persuaded to share a summary of my recommended setup.

(I have also, for quite some time, been providing a summary of this material in various free Drupal camp workshops as well as Drupal camp presentations.)

The goal of this blog post is to guide you through maximizing your Drupal development environment by integrating Visual Studio Code with DDEV by connecting it directly to the DDEV web container's filesystem.

While this is not the most common method of using Visual Studio Code with DDEV, I have found (and many of our PMD students agree) that this provides the easiest access to full IDE integration with tools like PhpStan and phpcs (among others.)

Much of the content in this document is also valid for other Docker-based local development environments (including Lando, Docksal, custom Docker). The main differences are related to directory paths.

Prerequisites

Before you can fully leverage the information in this document, be sure that:

You are comfortable using DDEV on a daily basis.
Your Drupal project includes the core development dependencies (via https://packagist.org/packages/drupal/core-dev).
Your project is configured to run phpcs, phpcbf, phpstan, and phpunit from the command line within the DDEV web container, including all relevant configuration files.
Finally, it is strongly recommended to use a settings.local.php file for your local development environment (here's why!)

Unleashing the power of remote development

A key aspect of this setup is leveraging Visual Studio Code's Remote Explorer and Dev Containers extensions. The general idea is to connect Visual Studio Code directly to your project's code base within the DDEV web container instead of accessing the files on your host operating system.

The primary advantage of this approach is that it allows other Visual Studio Code extensions to easily access and execute command-line tools that reside within the container. For instance, extensions for code quality like phpcs and PhpStan, which are typically installed within your Drupal project via the drupal/core-dev dependencies, can be directly invoked by Visual Studio Code without requiring complex configurations or path mappings to your host system's executables. This ensures that the code quality checks are performed using the exact tools and versions defined in your project's container.

Essential Visual Studio Code extensions

To achieve this integration as well as provide an efficient Drupal development environment, the following Visual Studio Code extensions are recommended:

Remote explorer: ms-vscode.remote-explorer
Dev Containers: ms-vscode-remote.remote-containers
PHP Debug: xdebug.php-debug
PHP DocBlocker: neilbrayfield.php-docblocker
PHP Intelephense: bmewburn.vscode-intelephense-client
PHP Sniffer & Beautifier: ValeryanM.vscode-phpsab
phpstan: SanderRonde.phpstan-vscode
PHPUnit: emallin.phpunit
Drupal Smart Snippets: andrewdavidblum.drupal-smart-snippets
Twig Language 2: mblode.twig-language-2

Note that when using this technique, the excellent DDEV Manager extension is not used as it normally operates from the host OS, and not inside the DDEV web container.

Making the connection

The key to making all this work is having Visual Studio Code connect directly to the project files in the DDEV web container and not in the host operating system. To do so, after launching Visual Studio Code, click on the Remote Explorer icon in the sidebar, then select Dev Containers from the select list, then select the web container for your project.

Once connected, click the Extensions icon in the sidebar, and install in the container any of the extensions listed above that require it (not all extensions need to be installed in the container.)

Finally, click the Explorer icon in the sidebar and navigate to the project root - usually /var/www/html.

At this point, while Visual Studio Code is running in your host OS, it only "sees" the DDEV web container. Which means that when you open the Visual Studio Code Terminal, you are executing commands in the DDEV web container by default.

From this command line, Drush, Composer, Git, npm, and other installed binaries can be run directly - without the need to prepend them with ddev or ddev exec (ddev .)

Understanding Visual Studio Code settings

In order to configure everything effectively, it is important to understand that Visual Studio Code supports two types of settings:

User settings: These are global settings that apply to all your Visual Studio Code projects unless overridden by workspace settings.
Workspace settings: These settings are specific to a particular project and will override any conflicting user settings. These settings are typically stored in a .vscode/settings.json file within your project's root directory.

Recommended workspace settings

Here is the recommended .vscode/settings.json configuration for DDEV in your project root. Note that if you already have settings in this file, you'll likely want to combine what is provided below with your current settings.

{
   /* DDEV web container */
   
   /* PHP Intelephense */
   "intelephense.environment.phpVersion": "8.3",
   
   /* PHP Linting */
   "php.validate.executablePath": "/usr/bin/php",
   
   /* PHP Sniffer & Beautifier */
   "phpsab.executablePathCS": "/var/www/html/vendor/bin/phpcs",
   "phpsab.executablePathCBF": "/var/www/html/vendor/bin/phpcbf",
   "phpsab.standard": "/var/www/html/phpcs.xml",
   "phpsab.snifferEnable": true,
   "phpsab.fixerEnable": true,
   "phpsab.snifferMode": "onType",
   "phpsab.debug": false,
   "phpsab.fixerArguments": [],
   
   /* phpstan */
   "phpstan.enabled": true,
   "phpstan.showProgress": true,
   "phpstan.binPath": "/var/www/html/vendor/bin/phpstan",
   "phpstan.configFile": "/var/www/html/phpstan.neon"
}

Some notes:

intelephense.environment.phpVersion: Specifies the PHP version used in the DDEV container, aiding PHP Intelephense with accurate code intelligence.
php.validate.executablePath: Defines the path to the PHP executable within the DDEV container, used for basic PHP linting.
phpsab.executablePathCS and phpsab.executablePathCBF: Point to the phpcs and phpcbf executables within the DDEV container's vendor directory, used by the PHP Sniffer & Beautifier extension for code standard checking and fixing.
phpsab.standard: Specifies the path to your project's PHPCS ruleset file (e.g., phpcs.xml) within the DDEV container.
phpsab.snifferEnable, phpsab.fixerEnable, phpsab.snifferMode, phpsab.debug, phpsab.fixerArguments: Configuration options for the PHP Sniffer & Beautifier extension, controlling its behavior for real-time code analysis and formatting.
phpstan.enabled, phpstan.showProgress, phpstan.binPath, phpstan.configFile: Settings for the phpstan extension, specifying whether it's enabled, whether to show progress, and the paths to the phpstan executable and configuration file within the DDEV container.

Recommended user settings

For some of the previously mentioned extensions, there are some user-level settings you might want to merge into your existing Visual Code Studio User settings.

To ensure the PHP Sniffer & Beautifier is the default formatter for PHP files, add the following:

"[php]": {
   "editor.defaultFormatter": "valeryanm.vscode-phpsab"
}

To prioritize Drupal Smart Snippets for code completion suggestions, add the following:

"editor.snippetSuggestions": "top"

To ensure PHP Intelephense uses the correct Drupal document root for code intelligence, add the following (this assumes your docroot is web):

"intelephense.environment.documentRoot": "web/index.php"

Summary

By following these recommendations and configuring your Visual Studio Code environment as described above, you can significantly enhance your Drupal development efficiency by taking full advantage of your local development environment's capabilities directly within Visual Studio Code.

Thanks to Randy Fay and Stas Zhuk (DDEV maintainers) for reviewing this blog post prior to publication.

AI was used to create the initial outline for this blog post using DrupalEasy's Professional Module Development curriculum as the source material. We support AI disclosure statements on all content that is posted to Drupal Planet.

The new IXP program: Ushering in needed fresh Drupal talent with bona fide incentives for employers

drupaleasy@gmail.com (Michael Anello) — Thu, 24 Apr 2025 10:51:38 -0400

Organizations can now be rewarded with Drupal contribution credits (among other enticements) for hiring new, inexperienced (IXP) Drupal developers.

After many months (years?) of planning, the Drupal IXP program is open and accepting applications for hiring organizations. From now forward, any participating organization that hires a new Drupal developer (with less than 3 months of paid experience) can earn 250 contribution credits upon successful program completion.

I'm super proud to have been working with Carlos and Anilu (A Drupal couple) and a number of other volunteers on this effort and am really happy to see it launched.

Why?

The Drupal developer community is getting older. With modern Drupal being more challenging to learn for new developers (especially compared with Drupal 7), fewer and fewer new Drupal developers have been joining our ranks. In order to survive, we need to build up the pipeline of new, fresh-minded, Drupal talent.

How does the program work?

Interested organizations can apply to participate at Drupal-IXP.site. After a quick manual review, accepted organizations will be provided with a coupon code to post an IXP position on jobs.drupal.org for free.

We have worked with the Drupal Association on creating a dedicated area for IXP positions on jobs.drupal.org.

Interested IXP developers apply for positions, and upon an offer from one of the participating organizations, both parties notify the Drupal-IXP site that the engagement has begun.

Both the IXP developer and hiring organization are required to submit periodic reports to Drupal-IXP to ensure all program requirements are being met (including a minimum number of mentoring hours.)

Once the minimum program length has been met (160 hours of paid work,) the hiring organization is eligible to receive 250 contribution credits upon a final review by IXP program volunteers.

What types of tasks are IXP developers suited for?

Keeping in mind that individual IXP’s will have diverse backgrounds, and, based on research we've done, IXP developers may be well-suited for tasks like:

Drupal core and module updates
Drupal site-building
Quality assurance

Depending on the non-Drupal background, IXPs might also be well-positioned to take on more complex or specific tasks.

We realize that the more guidance we can provide hiring organizations, the more successful this program will be; so we’ve started a Best practices for hiring organizations document and plan on collecting data from more organizations to help provide additional information (and case studies) to help with the IXP hiring process.

What are the program requirements?

The complete Drupal IXP requirements for interested parties are available at https://www.drupal.org/ixp

The IXP for new developers page details the minimum recommended skills level (although hiring organizations are welcome to hire at any skill level) as long as the IXP developers being hired have less than 3 months of paid experience.

The IXP for organizations page details mandatory program requirements including, but not limited to, at least 160 hours of paid work and a minimum of 1 hour of mentoring for every 10 hours of work.

Moving forward

This is only the beginning of the Drupal IXP program. We are looking forward to learning valuable lessons along the way, and fully expect the program to evolve as more and more organizations get involved.

Have questions? Fee free to use our Contact page or ping us in #ixp-fellowship channel of the Drupal Slack workspace.

DrupalCon Atlanta 2025 sessions not to be missed - according to me (ultimike)

drupaleasy@gmail.com (Michael Anello) — Sat, 22 Mar 2025 19:47:02 -0400

As part of weekly office hours for DrupalEasy students and alumni, I am often asked to suggest sessions at upcoming Drupal events that I think are worthwhile. During one our our most recent DrupalEasy Office Hours, I was again asked to run down the list of my picks from all the sessions at DrupalCon Atlanta 2025, and afterward I thought that it might make a fun blog post.

Of course, I can't in good conscience suggest that my picks are the best for anyone else to attend among the ginormous volume of sessions available. I can share only sessions that interest me. My selection of sessions have been made, with the only criteria being my logical or illogical and sometimes silly reason to listen to them. It is not a list of sessions targeted at beginners, project managers, those just getting into module or theme development or that I specifically recommend for those attending their first or even their twenty-first DrupalCon. (Although many of the sessions may be interesting to all of those folks.)

It is rather a simple (but not short) list of sessions that I will either watch in-person (not likely) or watch a recording of in the coming weeks (most likely.) It doesn't include keynotes (sorry, Dries), summits, the 10-minute mini sessions held in the expo hall, or anything other than standard 50-minute sessions. I won't even mention the session I'm co-presenting 😉.

So here goes; in chronological order, the list of sessions I am attending, and why:

Tuesday sessions

4 Big Ideas in UX and Content Strategy - I am always up for any session presented by Suzanne Dergacheva - one of Drupal's clearest thinkers and best presenters.

Documentation Initiatives for Starshot and Drupal.org - I don't contribute a whole lot to documentation, but Joe Shindelar knows his stuff and always presents well. I'm sure I'll pick up a nugget or two of useful information from this session.

Meet the AI Automators that power everything in Drupal CMS - CKEditor, AI Agents, no code required! - I have no doubt that this session will have more information about AI that will fit in my brain in a single sitting. Marcus is one of the leading minds behind Drupal's AI stuff. This is definitely one to watch later, rather than see in person (I need a pause button so I can take notes for this session.)

Recipes: It's About Time! - I'm a big fan of recipes, and I'll watch anything Martin presents. No-brainer for me.

The Future of Drupal Theming: AI, Experience Builder, and Beyond - I admit that I'm mainly anticipating the sophomoric humor Mike Herchel can't help to weave into his sessions 😃, but I guarantee that I'll learn a bunch from his deeply Floridian (in only the best ways) brain.

AI is the new UI - how we are building AI into Drupal CMS - Jamie is another of the leaders of Drupal's AI efforts and is a fantastic presenter and I always learn something from his presentations.

Creating Composer aware modules with Drupal core's new Package Manager module - Ted is a good friend, so I have to include this on my list or he won't let me pet his dog anymore.

Design systems, the Drupal way - I am not a designer, nor am I familiar with the speaker, but I am interested in how design workflows will flow into Drupal in the future, so I'll be checking this session out.

Security team panel - I always watch security team presentations from DrupalCon events. Not planning on stopping now.

Drupal Association Public Board Meeting - I'm a bit of a Drupal governance nerd, I never miss one of these.

Drupal Next-Gen Navigation: Enhanced Admin UI and better UX - Cristina is a fantastic speaker (I don't know Pablo); I don't miss too many of her sessions. Plus, I think the new Drupal core Navigation module is cool and I want to see what's next.

Drupal Recipes Initiative Update - Jim Birch is among the best Drupal presenters around (nobody tell him I said that, we need to keep him humble.) Plus, it's recipes (see above.)

Drupal Workspaces: Revolutionizing Content Staging and Workflows - I don't use Workspaces, but the presenter's name is Matt Danger, so how can I not give this one a listen?

Experience Builder is coming. Are you ready? - it's about Experience Builder by one of the leaders of the project. It's not hyperbole to say that this project is one of, if not, the most important projects in the Drupal community.

Mixing the Schema.org Blueprints module into a Drupal Recipe to bake a sweet content model - Jacob is an A+ presenter and I'm a big fan of Schema.org Blueprints module.

Working with the AI Agents in Drupal CMS - Create your own agents and AI powered migration - more AI content with a solid presenter who knows his stuff.

Accessible Slideshows - Button, button, who's got the button? - I'm not sure why this is, but if I don't include this in my list, I'll have to buy AmyJune a drink.

Building A Better Authoring Experience - I'll watch anything Greg Dunlap presents. Clear, concise, knowledgeable, A+ communicator.

Wednesday sessions

Drupal CMS now and beyond - A topic I care about by two of its leaders? Easy decision.

Drupal CMS: Golden standard for privacy and data protection - Jurgen is quickly becoming another presenter that I'll watch present on almost any topic.

From Figma to Function: Bridging Design and Development with Storybook & Drupal - I am not familiar with either of the presenters, but this is a topic I'm interested in (especially any SDC angles.)

Paragraphs and Single Directory Components: A dynamic duo - again, I'm not familiar with the presenters, but SDC…and, as you may have figured out, I do spend a lot of time with presenters I know and love, so a good reason to experience some others.

The future of Drupal core in the age of Drupal CMS - it's Gábor talking about the future! I'm in.

The Neurodivergency SuperPower - How Diverse Teams Function Better - Matthew presented this (or something similar) at Florida DrupalCamp https://www.fldrupal.camp/ a couple of months ago and people were raving about it.

Driesnote Followup Discussion - Dries talking about Drupal is almost always interesting to me.

DrupalCon as a Game - Ryan Price is one of my original Drupal friends and I didn't realize he was presenting until a few days ago. Gotta check this one out.

Supply Chain Security in Drupal and Composer - this will be a deep dive by some really smart people. I'll be doing my best to follow along.

What Do Marketers Really Want? Unpacking the User Research for Drupal CMS - another session that Suzanne is involved with. Can't not watch.

Creating Opportunities: From Internships to Drupal Careers - a topic near-and-dear to my heart co-presented by an alum of our Drupal Career Online course that I teach. (I'm not crying, you're crying! 😭)

Drupal Commerce's Starshot Roadmap - I don't use Drupal Commerce all that often, but Ryan Szrama is another top-notch Drupal presenter and I tend not to miss his presentations.

End-to-end collaboration in Drupal with EditTogether - this is a fantastic project from a fantastic group of human beings, presented by fantastic presenters. Fantastic

Following Drupal core development: Is it possible to understand every added change? - the answer is "no", but I still might watch this one.

From Community Initiative to a Drupal CMS Track: the Dashboard Module - Matthew Tift is a fantastic speaker - any presentation he's involved with is going to be solid.

Planning a Takeover: A Success Story in Implementing Storybook, Drupal 10, and Layout Builder - this checks several boxes for me: design workflow and a solid speaker (Mike Miles.) I'm hoping there will be some SDC in this one as well.

Distributions are dead, long live distributions: a Drupal CMS story - two fun speakers and a topic involving the "d" word? Should be fun.

Drupal.org Engineering Panel - I never miss one of these - always good info, especially if you're a project maintainer.

The Best (and Worst) Themes, Modules, Widgets, Extensions, and AI tools for ADA Compliance - I like opinions and I hope Alyssa Panetta doesn't hold back on the "worst."

What the WordPress Conflict Means for Open Source Businesses - George DeMet is a friend and who doesn't love a little bit of schadenfreude?

No, not "Claro", but "Klaro" (Cookie & Consent Management)

drupaleasy@gmail.com (Michael Anello) — Mon, 30 Dec 2024 07:00:00 -0500

In our previous Inside Drupal CMS blog post, we mentioned that the Klaro Cookie & Consent Management module was being used for privacy functionality.

What exactly is "privacy functionality" and how does Klaro help with it? That's the question that this article aims to answer.

The absolute basics

The Drupal Klaro module implements the open-source Klaro Privacy Manager Javascript library.

The library provides web sites an easy way to be transparent about the third-party applications on the site, as well as provide a mechanism for users to opt-in or -out of said services.

It is designed to help sites be compliant with privacy standards including GDPR and ePrivacy.

The module's documentation provides this easy-to-understand list of the main three objectives of the module:

User's data is not passed on to third parties without consent.
Tracking only takes place after consent.
No changes are made to the browser (cookies, local storage, session storage) without consent.

It should be noted that if you are using the EU Cookie Compliance module, the maintainers of that module suggest that you switch to Klaro, as their development efforts will focus on maintaining a stable release of EU Cookie Compliance while encouraging modern Drupal sites to switch to Klaro.

It should also be noted that Klaro provides a paid version at Klaro.org that includes "additional server-side functionality."

Installation

The Klaro module can be installed and enabled using standard Drupal best practices (Composer, Drush.) The Klaro module does not contain any submodules.

One interesting bit is that the module has a dependency on the Klaro JS module. This is of Composer type drupal-library, which means it will be automatically installed by Composer in your site's libraries/ directory (assuming that your composer/installers Composer plugin configuration includes a mapping for drupal-library.) This library contains the files from the Javascript library that are necessary for the Klaro Drupal module.

The module's documentation on drupal.org is better than most contributed modules, and goes into a reasonable amount of detail for each of the available configuration options. For this article, I'll focus on some of the highlights.

The real installation

In order for the Klaro Javascript library to do its thing, third-party HTML script tags must be slightly modified with different attributes.

Luckily, the Klaro Drupal module provides an Automatic Attribution Drupal Javascript behavior that attempts to automatically update third-party script tag attributes. Script libraries added via Drupal libraries, page attachments, and preprocess fields should work out-of-the-box. The module also includes experimental support for processing the final HTML of each page request for any third-party script tags that don't fall into one of the standard categories (iframe tags added directly to body fields, for example.)

As an example, here's a script tag from DrupalEasy.com before using Klaro:

<script async="" src="https://www.googletagmanager.com/gtag/js?id=G-WYJ99ZQTFR"></script>

Here's the same tag after Klaro is installed and configured:

<script async="" data-src="https://www.googletagmanager.com/gtag/js?id=G-WYJ99ZQTFR" type="text/plain" data-type="text/javascript" data-name="unknown_app"></script>

By modifying all of a page's third-party script tags, their loading can be controlled by Klaro's consent dialog. This is the basic functionality that the module provides.

It is also important to note that this Automatic Attribution functionality has some configuration options - on DrupalEasy.com, we needed to enable all options, including the experimental Process final HTML.

But, there's a big caveat - you might have some third-party script tags on your site that Klaro's Automatic Attribution doesn't catch; and this could leave your site always loading those third-party javascript files despite what Klaro is telling you. To help find any of these missed tags, the module provides a handy Log unknown resources option - I found this extremely useful when configuring the module.

On DrupalEasy.com, for example, we use analytics from AdRoll and marketing automation from Mautic and neither of these were automatically picked up by Klaro due to their implementation details.

For both, we had to manually adjust the way their script tags were written - see details about how Mautic's code was modified in this issue.

Basic configuration

Once the module is installed, the next step is to manage permissions for the module. Most sites will want to configure the module so that all users, including anonymous and authenticated ones are presented with the Klaro UI via the Use Klaro UI permission.

Its main configuration page, via Configuration | User interface | Klaro! (/admin/config/user-interface/klaro) contains a slightly-intimidating number of configuration options spread across six vertical tabs.

Perhaps the most important is the Klaro! dialog mode - four options are presented:

Silent (no dialog, only modify attribute and block sources) - in this mode there is no "global" dialog box to decline/accept/customize consent, and all third-party sources are blocked. Instead, there are individual accept links inline for 3rd-party content (from YouTube, for example.) This is the default setting that is currently used in Drupal CMS.
Notice dialog - displays a dialog asking the user to decline/accept/customize third-party cookie data. This is the option currently being used on DrupalEasy.com.
Notice dialog as modal - displays a modal dialog asking the user to decline/accept/customize third-party cookie data.
Consent dialog modal - displays the Customize version of the modal dialog.

Other functionality available on the default General vertical tab include options for various buttons and availability of the consent dialog.

Additional configuration options allow you to customize the styling of the Klaro dialog boxes as well as controlling the Klaro cookie data and some advanced options.

Final thoughts

As of the publishing of this article, the most recent version of the Klaro module is a release candidate, but based on the issue queue, it seems that work is actively moving toward a full release in the near future.

I can't overstate how much I appreciate that it is built on a well-supported open-source library that appears to have the momentum and financial backing to keep it updated.

After spending a few hours with the module, I recognize the value of how it works and have a good deal of confidence that it is working correctly.

Thank you to Jürgen Haas (jurgenhaas,) contributor to the Klaro Cookie & Consent Management module and Drupal CMS Privacy track lead, for reviewing this article prior to publication.

Inside Drupal CMS

drupaleasy@gmail.com (Michael Anello) — Thu, 12 Dec 2024 11:20:40 -0500

There's been more than a few articles written over the past year about the promise of Drupal CMS, but not a whole lot of articles about what Drupal CMS will specifically include. This article will attempt to fill in the gaps, by providing a bit of a high-level synopsis of what the 1.0 version of Drupal CMS will currently include. It is meant to provide an overview of most of the specific modules, information architecture, and functionality that you can expect out-of-the-box.

Note: This article is based on a pre-release version of Drupal CMS from December 8, 2024. Drupal CMS 1.0 is scheduled to be released on January 15, 2025.

Before we get started, it is important to set expectations for the initial version, as it will not include everything that many folks may be expecting. The best-of-breed Experience Builder and perhaps some additional in-browser styling functionality will come in a future release. It might be best to think of the 1.0 release as a next-generation, community-supported "distribution" that is well on its way to meeting the needs of no-code site-builders.

I hesitated to use the word "distribution" because of its previous history in the Drupal community. I'm open to suggestions as to what we call something that includes Drupal core and a collection of recipes.

All of the contrib modules I mention in this article are included with Drupal CMS. There are no additional downloads or command line commands that need to be run in order to utilize any of the functionality mentioned in this article.

Recipes all the way down

Drupal CMS is a collection of recipes that build on each other as well as on Drupal core. While there is a custom profile (more on that in a bit,) it doesn't include any contrib modules or configuration since everything is in the various recipes that come with Drupal CMS.

There are (tentatively) three types of recipes:

Foundational
Kit
Site

The recipes discussed below generally are of type Site, but most include recipes of type Foundational and Kit as dependencies.

Drupal CMS Installer

The installer for Drupal CMS is quite different from previous Drupal installation profiles as one of its main goals is to provide users the ability to select zero or more optional recipes to be applied and streamline some of the other normal installation steps (setting the site name and root admin user account.)

Currently, the installer exposes six Site recipes that can be applied during site installation:

Blog
Case studies
Events
News
Person profiles
Projects

Drupal CMS installer recipe selection screen

If not applied during the installation process, recipes can be applied to a site at a later time either via Project Browser or the command line.

Installing recipes after site installation

As alluded to, Project Browser comes with Drupal CMS. If one of the recipes mentioned in the previous section are not applied during site installation, they can be applied via Project Browser at any time afterward. In addition, there are several other recipes included with Drupal CMS that are not available during site installation:

Forms
SEO tools
Accessibility tools

Partial display of recipes in Project Browser

There are also several other Site recipes that do not appear either on the installation page nor Project Browser (yet) and can be applied via the command line:

AI support
Analytics
Multilingual
Search

Both AI support and Analytics require input when the recipe is applied (API keys) while Multilingual and Search are not yet complete recipes.

Recipe details

In the following sections, highlights of what each of the Site recipes include is outlined. Note that all of the recipes included below also include some level of configuration that is applied to the site when the recipe is applied.

Drupal CMS base recipe

The mother of all Drupal CMS recipes, this is automatically applied during site installation for all Drupal CMS sites. It includes much of the base level functionality including (but definitely not limited to:)

Page content type
Tags vocabulary
Various media types
HTML emails (via Easy email and Symfony mailer lite modules)
Anti-spam functionality (Antibot, Honeypot, Friendly captcha modules)
Privacy functionality (Klaro module)
Basic SEO functionality (Redirect, Pathauto, Easy breadcrumbs modules)
Automatic updates
Project browser
Dashboard module
Autosave form module
Coffee module
ECA module
Search API module

Blog recipe

Blog content type (with tagging)
Selective better exposed filters module

Case study

Case study content type (with tagging)

Subset of fields from a Case Study content type's Add case study page.

Events

Event content type (with tagging)
Address and Geofield-related modules
Smart date module
Event-related views

Subset of fields from Event content type's Manage form display page.

News

News content type (with tagging)
News-related views
Selective better exposed filters module

Person profiles

Person content type (with tagging)
Telephone (core) module

Subset of fields from Person content type's Manage fields page.

Projects

Project content type (with tagging)

Forms

Webform module

SEO tools

SEO-related fields added to most bundles (title, image, description)
Field group, Focal point, Metatag, RobotsTxt, SEO checklist, Simple sitemap modules

SEO-related fields added to content types by the SEO Tools recipe.

Accessibility tools

Editoria11y module

Editoria11y in action on sample Drupal CMS content.

AI support

Drupal Agent Chatbox
AI image alt text module
AI module as well as several supporting AI-related modules
See https://www.drupaleasy.com/blogs/ultimike/2024/12/first-look-drupal-cms-ai-recipe for details

Analytics

Google tag module

A quick word about recipes

If you're new to the world of Drupal recipes, there are a couple of things you should know:

Recipes are applied to a site, not installed. This is a subtle, yet very important difference from the Drupal of yore. Once a recipe is applied, there is no way to "un-apply" it. Modules and configuration that a recipe applies can only be removed by traditional Drupal methods (as if you created the recipe's configuration yourself.)
Recipes cannot be updated. If a new improved version of a recipe is provided in the future, it is not currently possible to "upgrade" your recipe to the new one.

While at face value both of these points might seem initially discouraging, they are designed to eliminate lock-in with the recipe author(s) and provide you with the flexibility to tweak a recipe's configuration and keep your site up-to-date with zero reliance on the recipe's author(s.)

Where is Drupal CMS 1.0 lacking?

The initial version won't be a truly no-code solution unless you want your site themed with Olivero. Until Drupal CMS includes tools to create and style pages from the browser, it really isn't valid to call it a no-code site-building tool. Luckily, this is being worked on by many of the brightest minds in the Drupal community.

There is still room for improvement for in-browser "guidance" for those new to Drupal, although we're setting a nice foundation with both the Dashboard module and a documentation track for Drupal CMS development.

Elephant in the room: Experience builder

Experience builder will be the next-generation page-builder for Drupal that will allow no-code site-builders and authors to create and style customized layouts using best-of-breed tools. Experience builder has often been mentioned as one of the key aspects of Drupal CMS and it will be, just not in the 1.0 version.

Final thoughts

As I mentioned at the top of this article, this isn't meant to be a comprehensive list of all the functionality that will be included in Drupal CMS 1.0. There are plenty of other contrib modules and configurations that will be part of this release that I didn't manage to squeeze into the narrative. Make no mistake about it, though: Drupal CMS 1.0 will be jam-packed with Drupal best-practice goodness.

However:, Without Experience Builder, who is Drupal CMS 1.0 for? I would argue that the initial version is more of a statement of intent from the Drupal community that we're taking no-code solutions seriously and are perhaps better prepared than any other open (or closed-)source solutions to take advantage of current and emerging technologies.

First look: Drupal CMS AI recipe

drupaleasy@gmail.com (Michael Anello) — Tue, 10 Dec 2024 05:58:33 -0500

The initial version of the Drupal CMS AI recipe was merged into Drupal CMS on December 3 and I couldn't wait to check it out…(well, I guess I could wait just until the end of my vacation last week 😀.) Anyway, the first chance I had, I updated my local development copy of Drupal CMS and got right to it.

Quick sidenote

The first thing I noticed is that the installer had changed since I last updated my local copy (about three weeks ago.) It has a much cleaner look, but it also appears that the AI recipe hasn't been deemed "installer worthy" just yet: not a big deal.

I verified that the recipe was in my local codebase (/recipes/drupal_cms_ai) and went about applying the recipe via the command line. I also reviewed the recipe.yml file to discover that this initial release includes two main bits of AI functionality:

The Drupal Agent Chatbot - this is an admin-only chatbot that knows how to create some Drupal entities, bundles, and fields.
The AI Image Alt Text module - this generates alternate text for uploaded content images.

I also noticed that the recipe included the AI Simple Provider Installer module (which provides a form to easily select a provider and enter your API keys), but there is no link (yet) directly to the form, so instead I navigated directly to /admin/config/ai/simple_provider_wizard and entered my OpenAI API key.

Drupal Agent Chatbot

Once the recipe was applied and my API credentials entered, I immediately noticed the Drupal Agent Chatbot in the admin area. I did not waste any time, as I wanted to know what it could do:

Prompt: What do you know how to do?

Response: I can help you perform a variety of tasks on your Drupal site, including:

Content Types: Create, edit, or gather information about content types.
Fields: Add or configure fields on content types or other entities.
Taxonomies: Create and manage vocabularies and terms, which are essentially categories or tags for organizing content.
Nodes: Assist in content creation, though this would often require configuration of content types and fields first.

If you have a specific task in mind, feel free to ask, and I can let you know how I can assist or even perform the task for you directly!

Oh my! This was very exciting! I decided to challenge it right away with the creation of a content type that I often use in our beginner-focused Drupal Career Online course:

Prompt: Create a new content type named "Movie" with fields for box office gross, a movie poster, a link to a YouTube video for a trailer, the year of release, and the director's name.
Response:
I've created a new content type named "Movie" with the following fields:

Box Office Gross: A decimal field.
Movie Poster: An image field.
YouTube Video Trailer: A link field allowing both internal and external links.
Year of Release: An integer field.
Director's Name: A text field.

The response also contained links to each field's config page as well as the Drupal configuration that was used to create the above.

Holy mackerel!

The only change I wanted to make was due to my lack of specificity in the prompt - I actually wanted the YouTube Video Trailer field to be of type Media: Remote video. Since the agent isn't allowed to delete things, I manually deleted the existing YouTube Video Trailer field from the Movie content type and went back to the chatbot:

Prompt: Please add a YouTube Video Trailer field as a Media (remote video) field.
Response:
I've added a new YouTube Video Trailer field as a Media (remote video) field to the "Movie" content type. You can now add videos to be displayed as media items from remote sources, like YouTube.

The response also contained a link to the field's config page as well as the Drupal configuration that was used to create the above.

A-maze-balls.

Image alt text

Next, I wanted to test the ability to generate alt(ernate) text for uploaded content images. I figured it would be a bit anticlimactic compared to the Drupal Agent Chatbot example I had just completed, but the fact that this worked out-of-the-box without any manual configuration on my part (other than my OpenAI API key) is really slick.

I simply went to create a new Basic page, navigated directly to the image field, uploaded an image of my dog, and clicked the Generate with AI button. After a few seconds the results populated the Alternative text field.

Summary

This initial version of the Drupal CMS AI recipe is super-impressive and really demonstrates the power of not just AI, but also of the Drupal APIs and the amazing work of the AI contrib module maintainers.

I can't wait to see how this progresses!

While writing this article, I spent a total $0.18USD on OpenAI API calls.

Handling Drupal core's oEmbed warning

drupaleasy@gmail.com (Michael Anello) — Fri, 29 Nov 2024 14:04:18 -0500

If you manage a modern Drupal site with the Media module enabled, then you're probably not a stranger to the "potentially insecure to display oEmbed content" warning that greets you whenever you visit your site's Status Report.

In this article, I'll tell you what this means, and what you can do to update your site to remove this warning.

What does it mean?

When you enable the Drupal core Media module, one of the media types that is automatically created is Remote Video. This media type allows you to add a link to a YouTube or Vimeo video which then is embedded on your site - super duper!

This is accomplished via an HTML iframe - normally something like this:

<iframe src="https://drupaleasy.com/media/oembed?url=https%3A//youtu.be/EYiI0QhDqPg&amp;max_width=0&amp;max_height=0&amp;hash=ykZPEBJjHVy-lIEmdlods4FTRZRt3mZuYOzawp_Ti6g" width="200" height="113" class="media-oembed-content" loading="lazy" title="Inline Entity Form basics in under 4 minutes"></iframe>

Note that the URL to the video is passed as an argument to the https://drupaleasy.com/media/oembed path - this means that any content loaded in the iframe has access to cookies from the drupaleasy.com domain.

To keep this from happening (and to further bolster security from XSS and other attacks,) it is recommended to set up a different domain (or subdomain) from which to serve the iframe; in other words:

<iframe src="https://SOME-OTHER-SUBDOMAIN.drupaleasy.com/media/oembed?url=https%3A//youtu.be/EYiI0QhDqPg&amp;max_width=0&amp;max_height=0&amp;hash=ykZPEBJjHVy-lIEmdlods4FTRZRt3mZuYOzawp_Ti6g" width="200" height="113" class="media-oembed-content" loading="lazy" title="Inline Entity Form basics in under 4 minutes"></iframe>

Step 1 - set up a new subdomain with your host

I normally begin by setting up a new subdomain with the hosting provider. This new subdomain points to the same place as the main domain. For example, I set up oembed.drupaleasy.com to point to drupaleasy.com.

Step 2 - add the new subdomain to your DNS records

From wherever your DNS settings are managed (Cloudflare, GoDaddy, etc…,) add the necessary records to your main domain's DNS settings. Normally, your hosting provider will tell you exactly what you need to add to your DNS settings. I use Pantheon hosting and this information is readily available on my live site's "Domains" area.

Step 3 - modify response headers to allow the new subdomain

While there's (at least) a couple of ways to do this, the easiest is perhaps with a modification to your site's main settings.php file. For example:

// Modify content security policy for oembed.drupaleasy.com
if (isset($_SERVER['HTTP_HOST']) && $_SERVER['HTTP_HOST'] === 'oembed.drupaleasy.com') {
    header("Content-Security-Policy: frame-ancestors https://www.drupaleasy.com;");
}

This allows embedded content from oembed.drupaleasy.com to be displayed on www.drupaleasy.com pages.

This type of change can also be made in your site's .htaccess file (assuming your web server uses this file) using the mod_headers Apache module.

Step 4 - configure Media module to use the new subdomain

The final, and easiest, step is to let Media module know about your new subdomain via the Configuration | Media | Media settings page (/admin/config/media/media-settings.)

Conclusion

Once complete, the potential security threat will be neutralized and your Status Report will have one less warning 😃.

Fundamental topics like this are an important part of a modern Drupal site's day-to-day maintenance tasks. In our 12-week, 2x/week Drupal Career Online program, we cover this and many other helpful site maintenance tasks.

DrupalEasy Podcast S17E4 - Ted Bowman - Experience Builder

drupaleasy@gmail.com (Michael Anello) — Thu, 21 Nov 2024 08:15:33 -0500

We talk with Ted Bowman from Acquia about Experience Builder, one of the main features of the upcoming Drupal CMS.

URLs mentioned

Wim's blog posts

DrupalEasy News

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, 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.

Credits

Podcast edited by Amelia Anello.

Why Drupal module developers should be excited about object-oriented hooks

drupaleasy@gmail.com (Michael Anello) — Tue, 29 Oct 2024 12:14:54 -0400

It's not super-often that a Drupal core change record stops me in my tracks, but recently, one did exactly that.

With so much of Drupal core written using modern, object-oriented PHP, there was still one place where we needed to use plain-old PHP functions: hook implementations. Drupal hooks have been with us since before I started with Drupal (over 18 years ago,) and I had long hoped that with the advent of "modern" Drupal (Drupal 8+,) eventually hooks would be converted over to Symfony events.

Much to my surprise, a recent change record for Drupal 11.x-dev (to be included in Drupal 11.1) has virtually all hooks (there are some exceptions) now being available as "object oriented hook implementations." 😀

The change record that put that smile on my face:

Support for object oriented hook implementations using autowired services

The short version

Classes can now be written that include methods that can act as hook implementation via a PHP attribute.

Click on the change record link above for a code sample.

Just as cool - there's backward compatibility built-in so that you can start writing OO hooks today.

The longer version

Go read the entire change record. 👍🏼

Why is this such a good thing?

First, less plain-old PHP functions + more classes = more modern PHP.
Secondly, these hook classes are services, which makes them more performant than plain-old PHP functions.
Thirdly, you can organize related hooks in their own classes.

Where can I see this in action?

Together with students from our current Professional Module Development class, we put together a quick module that:

Implements hook_user_login() using this new technique to display a welcome message to the user.
Includes the backwards compatibility stuff so that it works in Drupal 10.3+
Is written with both Drupal coding standards and PHPStan level 6 compliance.

Feel free to download or clone the no_more_hooks module from GitHub and check it out on your Drupal 10.3 or 11 site!

Navigation core module, Admin Toolbar contrib module, Gin contrib admin theme - I just want to rebuild caches!

drupaleasy@gmail.com (Michael Anello) — Fri, 25 Oct 2024 15:13:13 -0400

With the new Drupal core Navigation module introduced in 10.3.0, the long-standing Admin toolbar contrib module may finally have some competition.

The Admin toolbar module includes the Admin toolbar tools module that provides easy access to commonly-used functionality, including Flush all caches. The new core Navigation module does not provide the option for these, and the other options provided by Admin toolbar tools.

Both Navigation and Admin toolbar provide dynamic, fly-out menus for easy access to various levels of admin configuration pages. Similarly, the Gin contrib admin theme also includes functionality for a fly-out admin menu.

With several options available, together with some of the DrupalEasy alumni during DrupalEasy Learning Community office hours, I created the following quick summary of the various ways to get both a fly-out admin menu as well as the extra items like Flush all caches. This guide is appropriate for both Drupal 10.3+ and 11 sites.

Horizontal admin menu options

Admin toolbar module + Admin toolbar extra tools module

Vertical admin menu options

Navigation core module + Navigation extra tools contrib module
Admin toolbar + Admin toolbar extra tools + Gin admin theme
Gin admin theme + Navigation core module + Navigation extra tools contrib module
1. Note that Gin disables its own navigation options when the Drupal core Navigation module is enabled.
2. Note that the Gin Toolbar module has no effect when the Drupal core Navigation module is enabled.

A couple of extra notes:

The Drupal core Navigation Top Bar module crashes the latest Drupal core 11.x-dev (as of October, 2024) when attempting to enable it.
The Gin admin theme’s Show Secondary Toolbar in Frontend option adds a horizontal top bar to the site with a “Rebuild cache” link unless the Drupal core Navigation module is enabled in which case it has no effect.
The Navigation extra tools contrib module is authored by a DrupalEasy alum, James Shields!

Who will move Drupal forward?

drupaleasy@gmail.com (Michael Anello) — Fri, 18 Oct 2024 12:13:15 -0400

With Drupal Starshot on the horizon, the possibilities of expanding the market share for Drupal through Drupal CMS and building further on the power of Drupal Core creates a new vision, new opportunities and hopefully a renewed path of growth for our beloved community. So, while we all look to fully understand the Starshot initiative and its implications for our businesses and the way we market Drupal, it seems like a good time to also reflect, and perhaps begin to really address, the dwindling Drupal talent pool as well as lack of available Drupal jobs. We need to take a hard look at how we can attract those who will help to multiply and diversify our legions across the globe to support the project into the future.

The lack of Drupal talent and non-existent formal workforce pipeline for now and the future is a topic that, even having been constantly, at least casually discussed for years, has had no real community-wide solutions implemented to overcome it. Perhaps this is largely because resources (bandwidth & funds) tend to flow to areas that have immediate priority, have clear goals and can show immediate results. Experienced talent deficits are not easily, clearly, nor quickly fixed.

Additional challenges are that Drupal, at least what will be known as Drupal Core, has a relatively lengthy learning curve, and most companies tend to exclusively hire experienced developers. Since time is a required component of creating experience there is no speedy way to improve the flow rate of the Drupal talent that comes into the community. It doesn’t help that those new to Drupal struggle to find sustainable work and compensation to propel their journey through the novice years.

We must look at the supply of talent in the same way we look at our potential markets.

Consider that as people who are just starting out, changing or shifting their careers look to options, those with the foundations to take on web developer careers have a pretty good outlook. The US Department of Labor, Bureau of Labor Statistics (BLS) anticipates that, in the US alone, web developer careers will grow 8% (faster than average for most careers) from 2023 to 2033; with an estimated 16,500 new jobs every year. BLS explains, “Many of those openings are expected to result from the need to replace workers who transfer to different occupations or exit the labor force, such as to retire.”

Good news for attracting job seekers who would like to be web developers, but it also demonstrates that there is competition among the various web development platforms to attract them. This is not so great news for Drupal, with a conspicuously aging talent pool; an awareness problem among the general, (even tech-savvy) career-seeking populations and really no overall effort in place to mitigate either issue. It would be comforting to think that the workforce issue is with web development in general; but data reflects otherwise. This is a Drupal problem.

According to The 2024 Drupal Developer Survey, (Of which ~700 people responded) 36% of respondents have less than 10 years of experience. Compare that to the Wordpress Developer survey (which touts 90,000 respondents) that indicates about 48% have less than 10 years in. And, although age is not a true representation of experience, it can’t be ignored especially when thinking long-term and realizing that (audible gasp) less than 10% of Drupal respondents are under the age of 30.

The Wordpress survey tiered the age question differently, but ~25 % of the Wordpress respondents are under 25 (more than double the Drupal <30 respondents and 5 years less (& lower) in the tier!) while (second audible gasp) 65% are under 35 years old.

It is clear that a concerted, well-supported movement to help create a scalable workforce pipeline to nourish the future of Drupal CMS & Drupal Core would be a smart action item to run in tandem with the development and introduction of the Starshot initiative. It’s true that there has not historically been ongoing, consistent, widespread efforts to do this; but new tracks for growth and added market share need to be supported, so we at least have to solve our current lack of a workforce pipeline to keep the project moving.

Of course, it’s not usually easy to get broad participation for efforts with mostly long-term results, even with widespread sentiment recognizing the need. But honestly, we have to at least do better for the new talent we have.

Consider a snapshot of the last 9 months (1 day of jobs statistics/month) of Drupal jobs posted on jobs.Drupal.org.

Since January, the highest number of entry level positions open per month is two, and this is with two months of none being posted at all. This is a problem, perhaps The problem because the beginners are already struggling the most just learning Drupal.

Those who are not employed and seeking to learn, need to support themselves while they do so; and without any jobs to provide experience, they may never gain the experience needed to even be considered for the majority of positions that are open.

Without the opportunity or support to gain experience, people often seek other careers. Perhaps the shorter learning curve promised by Starshot through Drupal CMS will help, but we still need to address the lack of new and young talent coming into, and staying with the community.

With some time and resources from at least a few like-minded organizations, and eventually a meaningful shift in hiring practices from forward-thinking organizations; there is a way forward. Consider the IXP-Fellowship, a community initiative for onboarding inexperienced developers that hopes to create incentives for companies to guide new developers through the very beginning of their career in Drupal. There are also strategies that, taking into account individual organizations’ time and funding constraints, can leverage outside resource streams that can be combined with these types of community efforts. The key is recognizing the issue, and working on efforts that can help to build a Drupal workforce pipeline. These are a great start because, somehow, companies need to start showing some love to beginners in hiring.

Successful efforts would include outreach, training, and most importantly, placement opportunities in entry-level positions that will support, and in turn retain, novice developers through the various stages (years) of gaining experience and skill. This last bit may be the hardest to make happen, but it is key to success.

We’ve begun an effort to start collecting Drupal jobs data so that we can track, on a quarterly basis, the status of entry level and more advanced positions that are open. We’ll start sharing our Drupal Jobs report at the end of every quarter in an effort to keep the issue top of mind.

If you’ve been inspired or at least have become a bit interested in how you might contribute to sustaining and building Drupal talent for the future, check out:

Drupal Association IXP Fellowship program

Scholarship sponsor page

Internship/Apprenticeship Host page

Mentor application page

Discover Drupal information page

Feel free to also send me your ideas and thoughts: gwendolyn@anelloconsulting.com

DrupalEasy Podcast S17E3 - Ryan Price - Modernizing a Legacy Integration

drupaleasy@gmail.com (Michael Anello) — Sat, 21 Sep 2024 06:14:25 -0400

We talk with Ryan Price from ICF about a recent project he worked on involving updating a legacy Drupal 7 install with modern Drupal 10 techniques.

URLs mentioned

IES Abroad
Study Abroad Foundation
Pacific Northwest Drupal Summit - October 11-13, 2024.

DrupalEasy News

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, iHeart, Amazon, YouTube, or Spotify.

Credits

Podcast edited by Amelia Anello.

How to step down successfully as a Drupal leader

drupaleasy@gmail.com (Michael Anello) — Thu, 05 Sep 2024 15:33:06 -0400

In my 15+ years in the Drupal community, I've been fortunate to have been able to lead a few Drupal-related groups and I sometimes find myself in the position of encouraging other leaders - who are experiencing burnout - on how to gracefully step down from leadership positions after multiple years of service.

When I say "groups," I'm talking about things like:

Drupal event organizers
Drupal module/theme/project maintainers
Drupal initiative leaders
Drupal working group leaders

It seems counter-intuitive to encourage folks to step away from things they have successfully led, but I'm very fond of the concept that the true sign of a healthy organization is a successful change in leadership to make way for new perspectives, insights and ultimately fresh ideas.

In this article, I'll share some of my thoughts on my experiences in doing this exact thing with two prominent Drupal groups: the Florida DrupalCamp organizing team and the Drupal Community Working Group.

Being a leader in the Drupal community comes with responsibilities, but it also comes with prestige. Leaders tend to be more visible and therefore able to promote themselves or their organizations to their advantage.

Background

My leadership positions were gratifying, and I was still committed to them, but from my perspective, I had remained in them longer than was good for the organization or for me. But, I had an incredibly strong drive to ensure that I left the group in better shape than when I joined.

I was one of the original organizers of Florida DrupalCamp and ended up being the leader of the team by attrition. The other original organizers became less involved as the years went on, and I ended up taking on more-and-more duties. There wasn't a breaking point, but I realized that things weren't heading in the right direction.

For the Drupal Community Working Group, I was added to an incredibly strong team dealing with really difficult issues, but without a structured plan for length of terms or any other way to protect the mental health of its members.

In both cases, I was incredibly proud of the work we were doing, but didn't see a clear path to roll over leave either team in a healthy manner.

The good news

From my perspective, there are two things people need to do in order to successfully step down from leadership positions:

Train your replacement(s).
Codify roles and responsibilities.

The bad news

Neither of these two steps can be done overnight.

The details

Train your replacement(s)

You (yes, you) need to make a concerted effort to identify, approach, and ask someone (or in many cases, "someones") to fill your role when you leave. Once you find these magical people, then it is (again) up to you to train them in what you do. It is important that you communicate not only the work involved in being a leader, but also the advantages that come with the role.

For Florida DrupalCamp, I made it known well in advance that I was looking to step down as its leader (but willing to stay on in a lesser capacity). I knew it would be good for the event and community if there was new leadership. I told the other organizers as well as mentioning it during the event's opening and closing sessions. Most importantly, I did it early and spoke about it often. This directly led to several people stepping up.

This will likely be a time-consuming process, but it will make the team stronger. It will force you to document and organize what you do, and just the act of explaining it to someone else will allow you and your replacement to identify things that need to be documented as well as possible opportunities for efficiency gains.

Assume that you'll need to be training your replacement for at least a few months, but the timeframe really depends on the cadence of your team's primary tasks.

Codify roles and responsibilities

This was especially important for the Drupal Community Working Group, as prior to my joining the group, there weren't any guidelines for length of term, how the leader was selected, and how to step away gracefully. Under the leadership of George DeMet, our team implemented all of these, and more. Both George and I led the team for more years than was probably healthy for either of us, but by the time I stepped away, there were clear guidelines for all of these things (with a significant focus on the mentally draining Conflict Resolution Team).

For less formal teams, this could be as simple as a wiki page or an issue in the project's queue with what you and the other leaders do, what your boundaries are, and what your plans for the future are. This can be especially effective when someone makes a request of you that you feel is above-and-beyond - it is nice to have a document that you could point to where roles and responsibilities are detailed.

I'll admit that I skipped this step when stepping down as leader of the Florida DrupalCamp organizing team, as I wasn't leaving the team completely - I just stepped down into a lesser role but was always available to the new leaders for questions and advice.

Getting started

There are many Drupal groups that have informal leadership roles, with many leaders who definitely feel that if they leave, then the group will fall. Clearly, this is not a healthy situation.

In this case, my advice is this: start by writing up a document/drupal.org page that describes what you do as leader and share it with the rest of the group. Then, be proactive and find a potential replacement and start the training process using the document as a guide.

No replacement

It should be obvious that the "finding your replacement" step requires a human being other than yourself being involved. But what happens if you can't find someone…

This situation can be stressful and heartbreaking at the same time, but I have a strong opinion on this - if you find yourself in this situation, then maybe it is time for the team to be disbanded or go dormant. If there's not enough interest in the community to keep the group alive, it's not your responsibility to sacrifice your time/money/mental-health. My advice is to write up your thoughts, announce your intentions (and time frame) and post it to all members of the group. This can be done in a way that sets up a future leader to use the codified roles and responsibilities as a framework to get things moving again. In a way, you're still training your replacement - just not in realtime.

Will there be people who are disappointed and/or angry with you for "abandoning" the group? Perhaps, but you'll need to do your best to ignore those folks and focus on setting up the next leader for success.

I would suggest that you keep things simple and focus on the main goal of always leaving the group in a positive manner, setting up future leaders for success.

Thanks to AmyJune Hineline, Adam Varn, Mike Herchel, George DeMet, and Gwendolyn Anello (who reviews pretty much everything I write) for reviewing this post prior to publication.

DrupalEasy Podcast S17E2 - Janez Urevc - Gander

drupaleasy@gmail.com (Michael Anello) — Wed, 21 Aug 2024 15:16:00 -0400

We talk with Janez Urevc from Tag1 Consulting about Gander, an open-source automated performance testing framework.

URLs mentioned

Gander (includes many helpful links!)
40-minute video presentation introducing Gander (including a demo)
Drupal.org docs page for performance testing with Gander
https://gander.tag1.io - dashboard that Tag1 hosts for the Drupal community
Two-hour Gander workshop at DrupalCon Barcelona on September 24, 2024

DrupalEasy News

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, iHeart, Amazon, YouTube, or Spotify.

Credits

Podcast edited by Amelia Anello.

Using ECA to pre-populate a form field from a query string variable

drupaleasy@gmail.com (Michael Anello) — Thu, 08 Aug 2024 10:06:51 -0400

There's no doubt that the ECA module is changing the way Drupal sites are built - at least for those of us that use it regularly. I recently used it to pre-populate a form field on a node add page and it turned out to be easier than I figured it would be.

The task was to pass the value I wanted to pre-populate into the form via a query string variable. Something like:

https://mysite.ddev.site/node/add/article?myvalue=1

On the node add page, there exists an entity reference field whose value I'd like to pre populate with a value of 1 (myvalue).

Modules required

Modules used in the following solution are:

Token
BPMN.iO for ECA
ECA BPMN (part of ECA module)
ECA Form (part of ECA module)
ECA UI (part of ECA module)
ECA Core (part of ECA module)

The Token module is required because the ECA model will access the myvalue query string value via a token.

ECA components

The ECA Form module (a sub-module of ECA) provides the necessary components to achieve the goal.

The Build Form event and the Form Field: Set Default Value task components are all that are needed. Configuration as follows:

Build Form event

Restrict by form id: node-article-form
Restrict by entity type ID: node
Restrict by entity bundle: article

Form Field: Set Default Value task

Field name: field_linked_content
Value: [current-page:query:myvalue]

Once the model is created and saved, enjoy the fruits of your labor!

DrupalEasy Podcast S17E1 - Jamie Abrahams - Drupal's new AI module

drupaleasy@gmail.com (Michael Anello) — Sun, 04 Aug 2024 15:26:43 -0400

We talk with Jamie Abrahams from FreelyGive about the new AI module and what it means for the future of AI modules in the Drupal ecosystem.

URLs mentioned

DrupalEasy News

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, iHeart, Amazon, YouTube, or Spotify.

Credits

Podcast edited by Amelia Anello.

Getting ready to run your first migration

drupaleasy@gmail.com (Michael Anello) — Tue, 23 Jul 2024 05:29:54 -0400

Migrating content into Drupal is an extremely useful skill for most Drupal developers. Often, the most difficult step in learning to do migrations is the first one - that of getting everything set up and running your first migration to ensure that everything is working as expected.

Most Drupal migration-related blog posts and documentation that I've seen either completely ignore the setup process or gloss over it before diving into the details of writing migrations. I like to ensure, both here, and when working with participants in our Professional Module Development course, that we ensure a solid understanding of this process to build not only skills, but confidence.

This blog post will explain how to set up and run your first (very simple) Drupal migration. The process I will outline is actually the same steps I do when beginning to write a custom migration - just to make sure I have everything "hooked up" properly before I start getting into the more complex aspects of the project.

I generally write migrations on my local machine, using DDEV as the local development environment.

Configuration migrations vs. Plugin migrations

When creating a custom migration, one of the initial decisions to be made is whether you'll write the migrations as plugins or configuration entities. I've always used configuration entities, but there are pros and cons to both approaches. Here, we will focus on configuration entity migrations.

There are some minor differences in the workflow presented below when using plugin migrations. For more information on the differences, I recommend Mauricio Dinarte's article.

Core and contrib modules used

If you're planning on following along with this article, the following modules should be installed and enabled:

Drupal core:

Migrate
Migrate Drupal

Contrib:

Migrate tools (for Drush commands) https://www.drupal.org/project/migrate_tools
Migrate plus (migrations as configuration, additional process plugins, and more) https://www.drupal.org/project/migrate_plus

Source database

This blog post will demonstrate importing a small portion of user data from a Drupal 7 site into a Drupal 10 site. Normally, the first step is setting up the source data: in this case a Drupal 7 database. I normally create a new d7 database on the same MariaDB server as the Drupal 10 site (using DDEV, this is quite easy) and then import the Drupal 7 database into it.

Next, we have to tell the Drupal 10 site about the d7 source database. This can be done by adding the following database connection array to the bottom of your settings.local.php file (which I know you're using!):

$databases['migrate']['default'] = array(
  'driver' => 'mysql',
  'database' => 'd7',
  'username' => 'db',
  'password' => 'db',
  'host' => 'db',
  'port' => 3306,
  'prefix' => '',
);

Note the database key is migrate and the database name is d7. Everything else is identical to the regular Drupal 10 database credentials in DDEV. If you're using Lando or another local development environment, then your database connection array may be different.

Custom migration module

Next, we need a custom module to house our migration. The easiest way to create one is via Drush's generate command:

$ drush generate module
 Welcome to module generator!
––––––––––––––––––––––––––––––
 Module name:
 ➤ My d7 migration
 Module machine name [my_d7_migration]:
 ➤ 
 Module description:
 ➤ Migrations from Drupal 7 site.
 Package [Custom]:
 ➤           
 Dependencies (comma separated):
 ➤ migrate, migrate_drupal, migrate_plus
 Would you like to create module file? [No]:
 ➤ 
 Would you like to create install file? [No]:
 ➤ 
 Would you like to create README.md file? [No]:
 ➤ 
 The following directories and files have been created or updated:
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
 • /var/www/html/web/modules/custom/my_d7_migration/my_d7_migration.info.yml

Once created, go ahead and enable the module as well:

$ drush en my_d7_migration

Migration group configuration

As this blog post will be writing migrations as configuration entities, create a new config/install directory in your new module.

We'll define a migration group to which all of our migrations will belong - this is what connects each migration to the source d7 database. Create a new migrate_plus.migration_group.my_group.yml file in the new config/install directory with the following contents:

id: my_d7_migration
label: My Drupal 7 migration.
description: Content from Drupal 7 site.
source_type: Source Drupal 7 site
shared_configuration:
  source:
    key: migrate
  migration_tags:
    - Drupal 7
    - my_d7_migration

The most important bit of this configuration is the source key of migrate; this links up this migration group with the d7 database, with the migrate key we previously configured. Then, any migration created that is in this group automatically has access to the source d7 database.

Simple sample migration configuration

Next, let's look at a super simple example migration for user entities. This will not be a complete user migration, but rather just enough to migrate something. Many migration blog posts, documentation pages and other sources provide guidance and examples for writing migration configuration files (remember, this blog post is focused on all of the configuration and mechanics that normally aren't covered in other places.)

Here's the user migration configuration we'll use. Create a new /config/install/migrate_plus.migration.user.yml file in your custom module with the following contents:

id: user
label: Migrate D7 users.
migration_group: my_d7_migration
source:
  plugin: d7_user
process:
  name: name
  pass: pass
  mail: mail
  created: created
  access: access
  login: login
  status: status
  timezone: timezone
destination:
  plugin: entity:user

Reputable Drupal migration articles and documentation will explain that migrations need a source (extraction,) some processing (transform,) and a destination (where to load the data.) Often these three concepts will be called ETL. Each of these concepts are easy to spot in our sample configuration file:

The data is coming from the d7_user plugin (provided by Drupal core with the data source being that of the my_d7_migration group which we configured in a previous step.)
The processing of the data in this simple migration is just field mapping (to: from.) Many migration configurations have transformations as part of this section, often provided by Drupal process plugins.
The destination is Drupal user entities.

Running the migration

Again, these instructions are specific to Drupal migration configurations when created as configuration entities. Instructions for migration configuration written as plugins are slightly different (and not covered in this article.)

As we are dealing with configuration entities, they must be imported into the active configuration store - which, by default, is the Drupal database. This is easily accomplished with the drush cim --partial command. This must be run each and every time a migration configuration file is modified. This is one of the (few, in my opinion) downsides of writing migrations as configurations.

Next, I often check the status of migration via the drush migrate:status command. When using the Migrate Drupal module, it is recommended to always use the --group option otherwise the output of migrate:status can get a bit messy (due to all the default migrations that will be displayed.)

The drush migrate:import and migrate:rollback commands should be self-explanatory. Each can be used with either the --group option or with a migration name (as shown below.) I almost always use the --update option on migrate:import for updating previously imported data.

Finally, keep the drush migrate:reset command in your back pocket when writing custom migrations. If the migration crashes, you'll need to use this to reset its status from processing to idle in order to run it again.

Here's a full set of the command specific to the sample user migration, migration group, and custom module created in this article:

$ drush cim --partial --source=modules/custom/my_d7_migration/config/install
$ drush migrate:status --group=whatever
$ drush migrate:import user --update
$ drush migrate:reset user
$ drush migrate:rollback user

What's next?

What I've presented in this article is 90% of what I regularly use when running migrations. Sure, there are a few edge cases where oddities occur, but I believe this is a solid base of knowledge to start with.

Once all this makes sense, I encourage you to utilize other blog posts and documentation to extend the user migration we started, or write new ones based on other resources. Once you're comfortable writing additional migrations, learning how to create your own process plugins is the natural next step. As process plugins are written as PHP classes, some knowledge of module development is necessary.

Interested in learning more about Drupal module development? Check out DrupalEasy's 15-week Professional Module Development course!

Additional resources

UnderstandDrupal.com - loads of resources about Drupal migrations from Mauricio Dinarte.
Tag1's recent series about migrations (also written by Mauricio Dinarte!):
Migration related modules (definitely not an exhaustive list, but a solid start):
- Migrate plus
- Migrate tools
- Migrate devel
- Migrate process extra - process plugins for migrations.
- Migrate conditions - additional process plugins for migrations.
- Migrate source CSV - allows migrations from .csv files.
- Migration tools - even more process plugins and additional helper classes and methods for migration.
- Migrate upgrade - Drush support for the Drupal core migrations from Drupal 6 and 7.

Lead image generated by OpenAI.

Visual Debugger module: a modern take on an old idea

drupaleasy@gmail.com (Michael Anello) — Thu, 20 Jun 2024 08:07:18 -0400

If you've been a Drupal developer since before the time of modern Drupal (pre-Drupal 8,) then you probably remember the Theme Developer module. This module is/was used to figure out theme template usage and possible overrides in Drupal 7.

With modern Drupal, this same information is available directly in the HTML source code of a file when Twig development mode is enabled.

The Visual Debugger module by Marcos Hollanda combines the best of the present with the best of the past to surface template information directly in the user interface without having to dig into the page's HTML.

Pre-impressions

I will admit that before I installed the module, I was doubtful that I'd be interested in using it. Marcos had pinged me on Slack asking me to take a look at it, and I figured it would be a nice exercise for DrupalEasy Office Hours, which it was.

Much to my surprise though, I really like using it.

Basic usage

There's not much to say about how to use this module - it works just like you'd expect. Use Composer to get the code, enable the module, then enable Twig development mode and you're done. By default it will appear on each non-admin page of your site, with a handy activate/deactivate icon. There's really not too much to say about its usage 😀.

Current status

The module is in alpha status with several planned features not yet implemented. What is implemented so far appears to be solid and useful. The basic functionality that I expected is there. Click on any section of the page, and the module will display the template file that is used to render that section as well as a list of possible template file override names. This is the same information that Twig developer mode displays in HTML comments.

Marcos let me know that other planned features include theme hook suggestions and displaying caching information; (similar to the Cache review module, perhaps?)

There are other challenges to overcome as well, including how to handle selecting overlapping elements. I did make one very minor suggestion to relocate the module's configuration page which Marcos quickly implemented 🤘🏼.

Who is this module for?

I would definitely put this module in the category of a developer tool for folks who are either new to Drupal theme development or people who prefer a UI instead of scrolling through raw HTML.

I plan on following the progress of this module closely, in hopes that it will be suitable to use during the next semester of Drupal Career Online, where we have a theming lesson that could definitely benefit from this module.

Two very different European Drupal events in one week

drupaleasy@gmail.com (Michael Anello) — Tue, 18 Jun 2024 08:18:48 -0400

I was fortunate enough to attend two very different European Drupal events recently, and wanted to take a few minutes to share my experience as well as thank the organizers for their dedication to the Drupal community.

The events couldn't have been more different - one being a first-time event in a town I've never heard of and the other celebrating their 20th anniversary in a city that can be considered the crossroads of the Netherlands.

DrupalCamp Cemaes

First off - it is pronounced KEM-ice (I didn't learn this until I actually arrived). Cemaes is a small village at the very northern tip of Wales with a population of 1,357. Luckily, one of those 1,357 people is Jennifer Tehan, an independent Drupal developer who decided to organize a Drupal event in a town that (I can only assume) has more sheep than people.

When this event was first announced a few months back, I immediately knew that this was something I wanted to attend - mostly because I've always wanted to visit Wales to do some hiking ("walking," if you're not from the United States.) I used the camp as an excuse for my wife and I to take a vacation and explore northern Wales. I could write an entire other blog post on how amazeballs the walking was…

DrupalCamp Cemaes was never going to be a large event, and it turns out there wound up being only nine of us (ten if you count Frankie, pictured below.) The advantage of such a small event was easy to see - we all got to know each other quite well. There's something really nice - less intimidating - about small Drupal events that I realized that I've really missed since the decline of Drupal meetups in many localities.

The event itself was an unconference, with different people presenting on Drupal contributions (James Shields), GitHub Codespaces (Rachel Lawson), remote work (Jennifer Tehan), the LocalGov distribution (Andy Broomfield), and Starshot (myself.)

The setting of the event couldn't have been more lovely - an idyllic seaside community where everything was within walking distance, including the village hall where the event took place. If Jennifer decides to organize DrupalCamp Cemaes 2025, I'm pretty sure Gwendolyn and I will be there.

Read a brief wrap-up of DrupalCamp Cemaes from Jennifer Tehan.

This camp was proof that anyone, anywhere can organize a successful Drupal event with a minimum of fuss.

Drupaljam

Four days later, I was in Utrecht, Netherlands, at the 20th anniversary of Drupaljam, the annual main Dutch Drupal event.

I had previously attended 2011 Drupaljam and recall two things about that event: the building it took place in seemed like it was from the future, and many of the sessions were in Dutch.

This was a very different event from the one I had been at a few days earlier, in a city of almost 400,000 people with over 300 attendees (I was told this number anecdotally) in one of the coolest event venues I've ever been to. Defabrique is a renovated linseed oil and compound feed factory that is a bit over 100 years old that is (IMHO) absolutely perfect for a Drupal event. Each and every public space has character, yet is also modern enough to support open-source enthusiasts. On top of all that, the food was amazing.

Attending Drupal Jam was a bit of a last minute decision for me, but I'm really glad that I made the time for it. I was able to reconnect with members of the European Drupal community that I don't often see, and make new connections with more folks that I can count.

I spent the day the way I spend most of my time at Drupal events - alternating between networking and attending sessions that attracted me. There were a number of really interesting AI-related sessions that I took in; it's pretty obvious to me that the Drupal community is approaching AI integrations in an unsurprisingly thoughtful manner.

The last week reinforced to me how fortunate I am to be able to attend so many in-person Drupal events. The two events I was able to participate in couldn't have been more different in scale and scope, but don't ask me to choose my favorite, because I'm honestly not sure I could!

Ruminations on Drupal Starshot

drupaleasy@gmail.com (Michael Anello) — Thu, 23 May 2024 08:03:00 -0400

a second official version of Drupal

- Dries Buytaert, in his blog post announcing Drupal Starshot

If you're a Drupal developer of any caliber and pay any attention to the goings-on in the Drupal community, then you no doubt have heard about Starshot, recently announced by Dries Buytaert at DrupalCon Portland 2024.

In this post, I'll do my best to not repeat everything that was announced, but rather to summarize, ask a question or two and offer an opinion or two…

The basics

Starshot will be a new download available on drupal.org that includes contributed modules and configuration to provide a superior out-of-the-box solution that is more usable/approachable/friendlier than Drupal core.

In my opinion, Starshot can be thought of (generally speaking of course) as two-ish large tasks. First, full integration with Automatic Updates, Project Browser and Recipes (including full Recipe support in Project Browser.) Second; Experience Builder, which is planned to be (roughly speaking) some combination of Layout Builder (or a replacement,) Paragraphs, Single Directory Components, an in-browser styling tool and other modules/configuration to provide a best-of-breed page-building solution.

The -ish in two-ish from above is all the additional functionality that having full Recipes support will bring. IMHO, this is the star in Starshot.

Note: Experience Builder is not new - it is an evolution of Next generation page builder initiative that started in 2023.

Why?

In his keynote, Dries spoke about the need for Starshot over the course of a few minutes, enumerating various reasons why he and others in the community feel this is a necessary task, including the fact that Drupal's UI is difficult to use for new users.

I think Mike Herchel summed the Why up nicely in his blog post:

It’s an acknowledgement of the perception that Drupal is archaic and/or legacy software, and that this perception needs to change.

Starshot is the Drupal community's effort to win back small- and medium-sized sites that don't currently even consider using Drupal.

Furthermore, one of the main goals of Drupal Starshot is to allow for faster innovation cycles, allowing Starshot to add functionality at a faster pace than Drupal core.

Timeline

There's a countdown clock to liftoff on drupal.org/starshot that is currently at a bit over 200 days. Based on this, Starshot will be ready by January 1, 2025. Dries mentioned in his keynote that the goal was to have an initial release by the end of 2024.

There's actually a very early prototype of a subset of the functionality available from phenaproxima (Adam G-H.)

I'm a bit dubious about all of the mentioned functionality of Starshot being ready by the end of the year. More of my opinion on this in a bit…

Relationship to Drupal core

It's not a fork - that much is clear. It will include Drupal core, but have its own release schedule. I can only imagine that any time Drupal core has a security update, there will be a new Starshot release (as well as any time any of the contrib modules used in Starshot have a security release as well, I assume)

What's up with the "Launch" button?

One of my biggest questions after Dries' keynote was based on a mockup of a drupal.org page that he presented.

What happens when someone clicks "Launch?" I've been a proponent of the Drupal Association engaging/partnering with low-cost hosting providers to provide a way to easily provide hosting for a Drupal site that ~~supports~~ relies on Automatic Updates and Project Browser. The community has invested a lot of time in both of these initiatives, and I feel that neither really has a hosting "home." What would be a better way to officially launch these projects than hosting partners that fully support both, as well as a meaningful site backup plan, all included in a low monthly hosting price. IMHO, this type of thing should definitely be one of the options behind the mysterious "Launch" button. Maybe the DA gets a small referral fee from the hosting providers as well?

Gábor Hojtsy writes in his blog post about Starshot, "Discussions around making simple hosting available for simpler sites was reignited and a WebAssembly-based browser-executed demo solution's feasibility is also explored again." He also mentioned the potential for a WebAssembly-based option in his DrupalCon Portland 2024 session about Drupal 11, as well as options for ephemeral (temporary) hosting solutions (think SimplyTest.me.)

Will the plan and/or timeline change?

Absolutely. Dries and other folks already involved in Starshot admit that there's a lot of things to still figure out, decisions to be made and a lot of work to do to make all this a reality. Nothing is set in stone.

If I had a magic wand 🪄

As exciting as Experience Builder sounds, I'm worried that this is going to take a long time. In addition, as we've seen with the plethora of Layout Builder related contrib modules, there is often no one-size-fits-all solution for page creation.

From my perspective, I think that Drupal Starshot (or Drupal CMS, or whatever we end up calling it) phase 1 should be Automatic Updates, Project Browser, Recipes, and a set of curated recipes available geared towards page building. Experience Builder should be phase 2.

Being able to install recipes from Project Browser (leveraging Package Manager from Automatic Updates) will be a game-changer.

The way I look at it is with full Recipes support, we don't have to have just one Experience Builder, we can have many. We can have simpler ones (sooner) and more intricate ones (later.) We can have recipes that leverage Layout Builder and any number of the currently existing supporting contrib modules or recipes that focus on Paragraphs. The cream will rise to the top as the various Experience Builder modules are written, tested, and released.

Simon Hobbs agrees that Recipes is the "secret sauce" to Starshot in his optimistic blog post.

Community reaction

In the two-ish weeks since Dries announced Starshot, Drupal agencies from around the world have weighed in with their support, including PreviousNext from Australia (blog post by Kim Pepper,) 1xINTERNET from Europe (announcement,) Specbee (blog post by Malabya Tewari,) and (obviously) Acquia (United States.)

In my conversations with folks while at DrupalCon Portland 2024, reactions were mostly positive, but some folks had some concerns; with the leading issue being that (paraphrasing) the announcement feels like there were some internal (non-public) discussions about doing Starshot following by a "we are doing this" announcement by Dries. While I don't completely agree with this sentiment, I do understand it. The main pieces of Starshot have been open to discussion in the community, while the idea of putting them all together into a new "product" is something that (as far as I could tell) wasn't necessarily widely open for community input.

Additional resources

If you're only going to read one (more) "reaction" blog post about Starshot, I recommend Mike Herchel's, despite the fact that we disagree about the most important part of Starshot (he says Experience Builder, I say Recipes: stay tuned for a future cage match.) Regardless of his incorrect opinion 😜, his blog post is quite comprehensive.
Blog post from Taylor Paine at Five Jars about Starshot.
Matt Glaman's reaction to the Starshot announcement (focuses on Recipes.)
Blog post from Nadiia Nykolaichuk from ImageX
Press release about Starshot from the Drupal Association
Paul Johnson't blog post about Starshot
Electric Citizen blog post by Dan Moriarty

Drupal needs new, young developers

drupaleasy@gmail.com (Michael Anello) — Tue, 21 May 2024 08:08:15 -0400

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.

Another data point

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.

Is this as scary as it looks?

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.

What's the solution?

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.

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.
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.
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.
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).
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.

How can you help?

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.

cspell and drupalorg CLI: two useful tools for Drupal contrib module maintainers

drupaleasy@gmail.com (Michael Anello) — Tue, 23 Apr 2024 08:34:51 -0400

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

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 CLI

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:

 help                                 Displays help for a command
 list                                 Lists commands
cache
 cache:clear (cc)                     Clears caches
ci
drupalci
 drupalci:list (ci:l)                 Lists test results for an issue
 drupalci:watch (ci:w)                Watches a Drupal CI job
issue
 issue:apply                          Applies the latest patch from an issue.
 issue:branch                         Creates a branch for the issue.
 issue:interdiff                      Generate an interdiff for the issue from local changes.
 issue:link                           Opens an issue
 issue:patch                          Generate a patch for the issue from committed local changes.
maintainer
 maintainer:issues (mi)               Lists issues for a user, based on maintainer.
 maintainer:release-notes (rn, mrn)   Generate release notes.
project
 project:issues (pi)                  Lists issues for a project.
 project:kanban                       Opens project kanban
 project:link                         Opens project page
 project:release-notes (prn)          View release notes for a release
 project:releases                     Lists available releases
tci
travisci
 travisci:list (tci:l)                Lists Travis Ci builds for a Drupal project
 travisci:watch (tci:w)               Watches a Travis CI job

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:

I downloaded the drupalorg.phar to a new ~/sites/drupalorg/ directory on my local, and renamed the file to just drupalorg.
I then gave execute permission to this file via chmod u+x ~/sites/drupalorg/drupalorg
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"
```
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
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.

Summary

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.