Dependency Injection (DI) is a fundamental design pattern in object-oriented programming. Instead of having a class create its own dependencies, DI supplies them from the outside. This approach keeps classes loosely coupled and easier to maintain and test. By separating classes from the responsibility of creating their dependencies, we promotes flexibility, scalability, and cleaner architecture.

Dependency Injection in Drupal Image Ala Digital Marketer Wednesday, September 3, 2025 - 00:45 Teaser image Dependency Injection in Drupal Join the conversation + Comments Vote up! 0 claps

Overall SummaryOur June monthly meeting brought exciting transformational news for the UI Suite ecosystem. We're implementing a major reorganization strategy that will introduce a meta package while maintaining all existing modules as separate, optional components. This change aims to provide both flexibility for individual module users and convenience for those wanting the complete UI Suite experience through a single installation command.

Ask anyone about Drupal’s strengths, and they’ll talk about content modeling: custom content types, views, workflows, and permissions that can be built entirely through the UI. No other CMS matches Drupal’s flexibility for complex information architectures.

But once the backend is in place, you still need to make it usable and beautiful for real people. And that’s where things get hard.

Drupal theming is expensive.

Theming in Drupal has historically been expensive and complex. Unlike WordPress or Webflow, you can’t just drop in a template and go. A proper Drupal theme requires specialized knowledge of:

Overall SummaryOur May 2025 UI Suite community meeting brought together 20 passionate developers and contributors to discuss the exciting progress we're making toward transforming Drupal into the first design system native CMS. We celebrated significant milestones, including Pierre's promotion to provisional front-end framework manager, and showcased groundbreaking work on form API integration with Single Directory Components (SDC). The meeting highlighted our ambitious two-year roadmap and demonstrated how we're revolutionizing the way developers build and manage design systems in Drupal.With major releases on the horizon and innovative features like component-driven form elements becoming reality, we're witnessing a pivotal moment in Drupal's evolution. Our community continues to grow, and the momentum behind our initiatives shows no signs of slowing down.

Overall SummaryOur latest monthly meeting showcased the incredible momentum we're building across the UI Suite ecosystem. With 18-20 participants from both sides of the Atlantic, we celebrated Jean's promotion to core maintainer for SDC and Icon APIs while diving deep into groundbreaking developments that are reshaping how we approach design systems in Drupal.The session highlighted two years and a half of consistent progress, featuring live demonstrations of revolutionary tools like UI Patterns UI for simplified component management, UI Patterns Field for content entity integration, and our ambitious new Display Builder that promises to transform how we create layouts. From experimental form API integrations to major theme releases reaching beta status, we're seeing our vision of a unified design system approach becoming reality.

Overall SummaryWe're thrilled to share the exciting developments from our latest UI Suite monthly meeting, where we celebrated major milestones and outlined our ambitious roadmap ahead. After eight years of dedicated work and five years since UI Suite 1, we're finally witnessing UI Suite 2 taking concrete shape with the imminent release of UI Patterns 2.0.0 stable.

Overall SummaryOur final monthly meeting of 2024 marked the end of what can only be described as a transformative year for the UI Suite initiative. We've reached significant milestones across all five modules that comprise our complete design system implementation for Drupal, with UI Patterns 2.0 approaching its stable release and the entire ecosystem evolving toward a more mature, component-based architecture.

Overall SummaryOur 22nd monthly UI Suite meeting brought together community members for an exciting update on the ecosystem's evolution. This session focused heavily on transitions and new developments, with UI Patterns 2 taking center stage as the official version while layout options are being phased out. We're experiencing significant momentum across our entire suite of tools, with multiple modules preparing new branches compatible with UI Patterns 2 and the upcoming UI Icons integration into Drupal core.

Overall SummaryOur 21st monthly meeting marked a significant milestone in the UI Suite Initiative's journey. After two years since starting in October 2022, we've officially transitioned from the legacy UI Suite module to promoting UI Patterns 2 as our flagship solution. This meeting highlighted our growing momentum with around 50 UI Patterns 2 users and our position as the second most popular SDC module on Drupal.org.

Overall SummaryOur 20th monthly meeting marked a significant milestone for the UI Suite Initiative - celebrating two full years of consistent community engagement and progress. This meeting showcased substantial achievements across our entire ecosystem, with major releases and exciting new developments that demonstrate our maturation as a comprehensive design system solution for Drupal.

The big plugin attribute change-over made easy

Attributes are here and they're great. I hated annotations; they were a necessary evil, but putting working code into comments just felt wrong.

But the conversion work is still ongoing: many contrib modules (and perhaps custom ones too) need to convert their plugin types to being attribute-based. There is time to do this: code in \Drupal\Core\Plugin\Discovery\AttributeDiscoveryWithAnnotations announces that attributes on plugins are required from Drupal 12, with the old-style annotation allowed to remain alongside it for backwards-compatibility until Drupal 13.

But the sooner you convert plugin types to attributes, the sooner you benefit from imported classes in definition values, the ability to put comments within the annotation, cleaner translation of labels, and use of PHP constants in attribute keys or values. And IDE autocompletion of the plugin definition keys, if you're not using Module Builder to generate your plugins (why, though? why?).

With Drupal Rector you can convert individual plugins from annotation to attribute, but to convert a plugin type, you need more than that.

Module Builder can help with this with its Adoption feature. This adds items to your module config based on the existing code, which allows you to alter or add to the code definition before re-generating it. (This feature is particularly useful for adding further injected services to an existing class such as a plugin or a form.)

Release 4.5.4 of Drupal Code Builder (the library that powers Module Builder) added adoption of plugin types, and this opens the door to converting a plugin type from annotation to attribute. The steps are are follows:

1. Go to Administration › Configuration › Development › Module Builder.
2. If your module is not already defined in Module Builder, click 'Adopt existing module', then find your module in the list and click 'Adopt module and adopt components'. If you already have the module in Module Builder, go to your module's 'Adopt' tab.
3. On the adopt components form, select the plugin types you want to convert.
4. Click 'Adopt components'.
5. Go to the 'Plugins' tab of your module. Your plugin types should be in the form.
6. Change the discovery type of each one to 'Attribute plugin'. The values will carry across (this is actually a problem with FormAPI that I've never managed to figure out, but it's actually quite handy).
7. Go to the Generate tab.
8. Select the files to write. For each plugin type, you'll want the plugin manager, and the new attribute class.

You should verify the new attribute class. Properties will have been adapted from the annotation class but they may not all be correct. In particular, default values for optional properties aren't yet handled by Module Builder, so you'll need to add those.

Once you've tidied up the attribute class, your plugin type is now attribute-enabled. (You should run the tests that cover plugins just to make sure everything is fine.)

The plugins of this type in your module are still using annotations, so now we turn to Rector.

There is full documentation on converting plugins but the gist of it is this:

$rectorConfig->ruleWithConfiguration(\DrupalRector\Drupal10\Rector\Deprecation\AnnotationToAttributeRector::class, [ new \DrupalRector\Drupal10\Rector\ValueObject\AnnotationToAttributeConfiguration( '10.0.0', '10.0.0', 'MyPluginType', 'Drupal\my_module\Attribute\MyPluginType', ), ]);

Run rector on just your plugin folders to make it go quicker, since you know where the plugin files are:

vendor/bin/rector process path/to/module/src/Plugin/MyPluginType

That converts all the annotations, but unfortunately, it doesn't format them properly: the whole thing ends up all on one line. And PHPCS and PHPCBF don't know how to format an attribute either.

But regular expressions come to the rescue, and fortunately the syntax of attributes is fairly distinct.

In your IDE, a search of '(?=\b\w+: )' replaced with '\n ' (note two spaces, for the indent) will put each property onto its own line. It won't handle array values though. And beware: it will catch the use of colons in text strings! This is an instance where using a GUI for git makes quick work: stage the fixes to the attributes, discard everything else.

That leaves just the terminal closing bracket, which you can do by hand, or cook up a regex if you have a lot of plugin classes.

joachim Tue, 02/09/2025 - 13:17 Tags

• module builder
• plugins
• Rector
• deprecation
• regex

Image

DrupalCon Barcelona 2024 by Bram Driesen

Ready for a truly technical deep-dive? At DrupalCon Vienna 2025, you’ll gain insights from cutting-edge sessions, hands-on workshops, and direct interaction with the maintainers shaping Drupal’s future. Here are the top five technical reasons you can’t miss this year:

1. Shape the Future with Drupal Canvas

Drupal Canvas debuts at DrupalCon Vienna with the session "Drupal Canvas Unleashed: The Future of Drupal is Here" by Lauri Timmanee and Bálint Kléri. This session unveils the production-ready Drupal Canvas and shows how it transforms Drupal site-building through a component-driven, in-browser development workflow. Learn how to:

• Kick-start new sites with faster, more collaborative builds
• Leverage UI-embedded code and reusable components for efficiency
• Incorporate existing modules into this modern architecture

 

2. Maximize Performance with DevOps and Network-Level Enhancements

Don’t miss "TCP Fast Open and HTTP/3: Network-Level Optimizations for Lightning-Fast Drupal" by Nicolas Perussel, where you'll dive into advanced networking techniques that can dramatically reduce latency and improve load times. Combine that with "Secure by Design: Integrating Security into Drupal Development" by Janna Malikova — learn how to bake essential security practices into every step of your build and deployment pipeline. This combo gives your projects real-world robustness and performance.

 

3. Explore AI-Powered Workflows and Multibrand Architecture

DrupalCon Vienna spotlights enterprise innovation through sessions like "Drupal AI – Strategy and Application" by Christoph Breidert and Frederik Wouters, and "Nestlé Nutrition Scalable Multibrand Design System on Drupal" by Olga Tsiamliak and Bastien Chanot. Get inside:

• Strategic approaches to applying AI workflows in Drupal projects
• Modeling large-scale, flexible design systems in a multisite environment
• The role of AI-driven automation in enhancing editorial and marketing efficiency

 

4. Hands-on Learning Through Contribution, Workshops & Labs

With over 100 expert-led sessions, plus workshops and a dedicated Contributor Day, DrupalCon Vienna isn’t just about inspiration. It's about execution. Participate in:

• Code labs that walk through module development, debugging, and API integration
• Workshops on CI/CD flows, configuration management, and production optimization
• Live contribution opportunities where you can get real code reviewed and merged
   This immersive, practical environment helps you bring new skills directly into your projects.

 

5. Gain Vision Through Keynotes and Future-Focused Talks

DrupalCon Vienna features four keynote presentations, including the Driesnote by Drupal founder Dries Buytaert, plus forward-looking panels such as "The Web in 2035" and "Drupal CMS Spotlights". These sessions offer:

• Strategic insights into Drupal’s evolution and roadmap
• Speculative discussions about the future of open web technologies
• Inspiration for how Drupal can lead next-generation digital experiences

Why It Matters

• Track-based learning: With seven technical tracks — from Drupal CMS and InfoSec & DevOps to Clients & Industry Experiences — you can dive deeply into the areas most relevant to your role and interest.
• Strategic immersion: Whether you're refining DevOps pipelines, architecting large-scale builds, or integrating AI into workflows, DrupalCon Vienna gives you actionable knowledge to level up your projects.

Ready to be at the forefront of Drupal innovation?
Prepare your personalized agenda, explore new sessions, and let DrupalCon Vienna 2025 be the turning point in your Drupal journey.

Stay Tuned!

So bookmark this space, and get ready to experience DrupalCon Vienna 2025 like never before.

Are you coming? Let’s connect!

By Iwantha Lekamge

Technical Lead
WSO2

If you've been using DDEV for a while (like me!) then you've probably run into the issue of your Docker disk space allocation getting full. I use Rancher Desktop and more than a few times I've received warnings that more than 95% of the 100GB I have allocated is full. Being a bit naive, I normally react by backing up a few projects I'm not regularly using and then doing a ddev delete on them. The most recent time, however, I decided to take a different approach. At the time, I didn't think I had all that many active DDEV projects (relative to my normal situation) so I did a little digging and learned that Mutagen (included by default with DDEV) cache files can take up quite a bit of space. So, instead of using ddev delete on a bunch of projects, I used: ddev mutagen reset on four of my most recently used projects and the issue went away without me having to delete any of my DDEV projects. In a conversation with Randy Fay, one of the maintainers of the DDEV project, he mentioned that he

If your Drupal website is slowing down under pressure, you need some performance-accelerating modules! Check out 7 such great Drupal modules that can keep your site performing smoothly even during traffic spikes.

At Liip, we often work with clients who have complex content management needs. One recent project was the new website for the Museum für Gestaltung in Zurich, the leading Swiss design museum with a diverse and active public program. A key requirement was a flexible event management system that could support a wide range of event types.

Understanding the requirements

In addition to its permanent and temporary exhibitions, the museum hosts a broad spectrum of events: from guided tours and school visits to multi-day workshops and the occasional concert or film screening.

These events take place at three different locations and cater to different audiences: individual visitors, families, friend groups, and school classes. Some events are free, while others require paid registration. Many are offered in multiple languages.

Managing this complexity required a system that could support:

• Recurring events with complex schedules
• Variable durations (from 2-hour visits to multi-day workshops)
• Multiple locations
• Audience segmentation and targeting
• Participant limits (minimum and maximum)
• Automated visitor communication (e.g., reminders)

In short, the museum required more than just a simple event list and a calendar.

Evaluating Drupal solutions

With Drupal, the motto is “there’s a module for that.” With over 53,000 contributed modules available, it was natural to begin our search there.
After evaluating several options, we identified the Recurring Events module as the most promising starting point.

Why Recurring Events?

Pros:

• It is the most comprehensive module for managing events in Drupal.
• It provides strong functionality out of the box, in some areas even exceeding our requirements.

Cons:

• Not all the museum’s requirements were covered.
• Some existing features didn’t align with the museum’s use cases and would need to be modified.

Identifying feature gaps

The Recurring Events module met many of our needs, but not all of them. This is a common challenge in software development: existing solutions often get you most of the way there, but rarely tick every box.

Here are some key features required by the Museum für Gestaltung that were not available at the time:

Multilingual support

In addition to the three national languages of Switzerland, the museum regularly offers events in English for international visitors. Full multilingual handling for event content and registration workflows is essential.

Group registrations

Most visits occur in groups, ranging from families and friend circles to school classes and tour groups. The system needed to support registering entire groups at once. If an event does not have sufficient remaining capacity to accommodate the whole group, the group should be put on a waitlist.

Default capacity per event type

Some event types (such as guided tours) recur frequently and always have the same fixed capacity. Setting a default value per event type would streamline content entry and reduce the risk of manual errors.

Locked event dates

In our use case, once an event is published and publicly visible, its dates must not be changed. However, at the time, the Recurring Events module allowed dates to be changed or deleted at any time. To avoid confusion and dissatisfaction with visitors, the dates should be locked once published online.

Tailored email communication by registrant type

Depending on whether the visitor is a private group or a school class, different teams are responsible for managing the event, and different email templates need to be used.

Deciding the right approach

The question now becomes whether to extend what’s available or build a custom solution from scratch. Let’s look at the options:

Option 1: Build a custom solution

This would give us complete control and flexibility.

Pros:

• Tailored exactly to the museum’s requirements without any compromises.

Cons:

• High upfront development cost.
• Reinventing features already available in existing modules.

Option 2: Fork the Recurring Events module

This is a pragmatic approach, especially in the short term, but it is difficult to maintain in the long term.

Pros:

• We adapt the module to meet all specific needs. Remove what we don’t need, change what is necessary.
• The fastest to implement during initial development.

Cons:

• Long-term maintenance burden: we’d need to track and integrate upstream changes continuously for the whole duration of the project.
• High risk that future changes to the module will collide with our own.
• Our improvements wouldn’t benefit the community, nor receive community improvements in return.

Option 3: Override the module with custom code

Use the module as is, and build the missing functionality alongside it using Drupal's APIs, which are designed to adapt existing features to a project’s specific needs.

Pros:

• We can make use of the existing features of the module.
• Clean separation between contributed code and project-specific logic.

Cons:

• Still requires ongoing maintenance of our custom code.
• A smaller risk of conflicts if the module’s feature set evolves over time.
• Our planned additions might be useful for other users of the module, but they wouldn’t be contributed back.

Option 4: Contribute to the Recurring Events module

Work collaboratively with the module maintainers to integrate new features directly into the module.

Pros:

• Aligns with Drupal’s open-source philosophy.
• Ensures long-term compatibility and community support.
• Features are reviewed and improved by other experienced developers.
• Reduces maintenance effort for our team in the long run.

Cons:

• Contributions must meet high standards for code quality and documentation.
• Contributions need to be reviewed and tested by the community. It is possible that contributions are rejected or take a long time to be reviewed.
• Requires additional communication and coordination during development.

A collaborative success

We chose Option 4: to work closely with the maintainers of the Recurring Events module and contribute the features that were missing for our use case. Over the course of several months, we actively collaborated through the issue queue, contributed code, and reviewed patches. This effort led to one of our developers being onboarded as a co-maintainer of the module.

The result was a success. We were able to deliver a powerful, flexible event management system that met the museum’s needs. It is built entirely on open source principles. Several of our contributions are included in the latest releases of the module, and additional improvements are still in progress.

At Liip, we strongly believe in strengthening the tools we use, not just for us and our clients, but for the entire Drupal open source community. If you're interested in improving event management in Drupal, we invite you to join the conversation and collaborate with us in the Recurring Events issue queue.

Today we are talking about Drupal Canvas, What it is, and when we can use it with guest Lauri Timmanee. We’ll also cover Starshot Demo Design System as our module of the week.

For show notes visit: https://www.talkingDrupal.com/518

Topics

• What is Drupal Canvas
• The Evolution and Future of Drupal Canvas
• Building with Drupal Canvas: Components and Templates
• User Experience and Flexibility in Drupal Canvas
• Collaboration and Extensibility in Drupal Canvas
• Default Components in Drupal Canvas
• Introduction to Modular Components
• Drupal CMS and Site Templates
• Acquia Source and Drupal Canvas Integration
• Pricing and Use Cases for Acquia Source
• Canvas Beta and Stability
• Migration and Upgrade Paths
• AI Integration in Drupal Canvas
• Future of Drupal Canvas

Resources

• Civictheme storybook
• Acquia Source

Guests

Lauri Timmanee - lauriii

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi

MOTW Correspondent

Martin Anderson-Clutz - mandclu.com mandclu

• Brief description:
  • Have you ever wanted to try out Canvas (previously known as Experience Builder) with a fully built-out design system? There’s a Drupal theme for that.
• Module name/project name:
  • Starshot Demo Design System
• Brief history
  • How old: created in July 2024 by longtime Drupalist Kristen Pol of Salsa Digital
  • Versions available: 1.0.6, which supports Drupal 10 and 11
• Maintainership
  • Actively maintained
  • Security coverage
  • Test coverage
  • Documentation - Multipage writeup of SDDS, including contribution and development guides
• Number of open issues: 34 open issues, 3 of which are active bugs
• Usage stats:
  • 79 sites
• Module features and usage
  • Some of our users may have already tried out the pre-release demo of Canvas that phenaproxima posted on Github. That actually has the Starshot Demo Design System, or SDDS, baked in. So, even if you watched a demo video of Canvas, you’ve probably seen SDDS in action
  • SDDS is itself built on CivicTheme, a Drupal theme built to act as a component-based atomic design system. As such, CivicTheme includes a rich component library, built from published Figma and Storybook UI Kits. And because some of the early builds for SDDS were for GovCMS, the Australian whole-of-government CMS project, it is accessible, with WCAG 2.2 compliance out-of-the-box
  • While the official purpose of SDDS is providing a platform to use for demos in Driesnotes and other presentations to illustrate the progress being made on Canvas, I think it’s also safe to say that testing the latest features of Canvas with a fully-realized design system has also helped to identify issues in Canvas itself. That means the products of all the work that has gone into SDDS will include a more production-ready stable release when that gets tagged (hopefully in time for Vienna)

This is a table of contents of a 10 part blog series for anyone considering Drupal or LocalGov Drupal training.

Social media plays a crucial role in disseminating information, although it is also accompanied by noise. Platforms like LinkedIn, Mastodon, and Bluesky influence how projects, such as Drupal, are initially discovered, discussed, and evaluated. The Drupal Association’s decision to scale back on Twitter/X while investing in decentralised and professional networks is not a side strategy; it signals that visibility is as critical to sustainability as code. Perception sets the pace for participation.

This alignment, however, exposes a larger challenge: being visible is not the same as being understood. Drupal’s strength has always been its flexibility, but that complexity is difficult to translate into shareable stories. Without clear demonstrations of use cases, governance processes, and long-term sustainability, transparency risks becoming noise. An open project must do more than publish updates; it must demonstrate how those updates have a practical impact. For Drupal, the question is whether its social presence can reflect not only technical progress but also the health and inclusiveness of its community.

Meanwhile, the structural hurdles are significant. The end of life for Drupal 7 has left many nonprofits and smaller organisations facing urgent migration decisions. The platform’s steep learning curve continues to limit entry for new developers and site builders. And upgrade complexity remains a friction point that undermines confidence even among seasoned teams. These are not legacy problems; they are active barriers to adoption. Social platforms cannot solve them, but they can amplify them, surfacing real experiences, connecting peers, and applying pressure for solutions.

INTERVIEW

• Dear Drupal, From Chris McGrath With Esteem

DISCOVER DRUPAL

• Drupal Developer Survey 2025 Results are Out!

• Markdown Easy 2.0.0 for Drupal: New Flavor, Simplified Setup, and Better Markdown Support

• Drupal Community Working Group Seeks Volunteers to Support Community Health

• Drupal.org Credit System Moves to Contribution Records

• New “Squid Game” Drupal 11 Theme Released by Frontend Specialist Joginder Singh

EVENTS

• DrupalCamp Italy 2025 Announced for November 14 in Rome

• DrupalCamp Pune 2025: Register Now for September Event and Win a DrupalCon Nara Ticket

• DrupalCon Nara to Host Webinar on Crafting Winning Entries for Splash Awards Asia 2025

ORGANIZATION NEWS

• From Vision to Platform: How LastGuide Scaled Open Knowledge on Drupal

• How IT Care Used AI to Speed Up YMCA Website Content Migration

• How Drupak Automated Swapcard-to-Drupal Content Sync for Event Management

• Morpht Becomes Gold AI Maker, Strengthens Drupal AI Initiative

• Cheppers Releases Free AI & Drupal E-Book for Mission-Driven Organizations

• Jeff G. Relaunches The Accidental Coder to Provide Drupal and Web Development Solutions

Tutorial

• New Drupalize.Me Course Covers Single Directory Components in Drupal Core

We acknowledge that there are more stories to share. However, due to selection constraints, we must pause further exploration for now. To get timely updates, follow us on LinkedIn, Twitter, Bluesky, and Facebook. You can also join us on Drupal Slack at #thedroptimes.

Thank you, 
Sincerely,
Kazima Abbas, 
Sub-editor, The DropTimes.

We will try to give back information about what is happening on the technical side, so people can stay up to date with improvements happening in the Drupal AI space from a developers perspective.

I was recently myself away on vacation for some weeks, and realized just how quickly everything is moving, both in the AI space and the Drupal AI space when you are not actively following it. The Drupal AI Initiative and its people contributing to it, outside of FreelyGive, have started its own momentum.

So this is a way to get a bi-weekly update on what is happening outside of releases, to be able to test things happening on the dev branches of different projects.

Tool API is released

The first alpha release of Tool API happened in the past week. The idea behind the Tool API is to create one uniformed API for any type of tool with clear input and output schemas. These will be able to be used both as function calling tools for AI, for tools for MCP, but also in the future derive actions for powerful automation tools like ECA. 

In practice it means that you can define a tool once and use it in multiple systems, including as a function call for AI. The idea with this is that you should be able to create reusable tools for manipulating entities, using views as context, getting information about the Drupal system etc. simply in the GUI and be shipped as configuration. 

This together with the functionality to create completely custom function calls in the UI using ECA, opens up for shipping a lot of agents as configuration without other module dependencies.

Tool API is being released as its own module, since the possibilities of how to use this is something that is outside of the scope of just the AI module.

Going forward with the MCP Client, we will most likely use Tool API as well as the foundation to make sure that any tool from a MCP server you want to create a version of inside Drupal.

A huge thanks to Michael Lander who has been working tirelessly on this project and for all the expertise he has been giving back to the AI project in general.

A video of the tool api in action creating Drupal content that with Claude Desktop and MCP using natural language can be found here.

Image-To-Image operation type is merged

One year ago when the initial Image to image operation type was thought of, it was a fairly “useless” AI inference type. The problem was that the AI models could not keep consistency, meaning that at best you could use it for some nice demoing purposes, most of which made little sense to use in a Drupal context.

This has somewhat since changed, with Dreamstudio offering things like removing backgrounds, outpainting of images to fit specific ratios etc. and OpenAI GPT-1-Image making it possible to generate images in a style of another image. This was what it was initially meant for.

However, since the issue was put “in review” and it has now been merged, Nano Banana was released and is a complete game changer in this field. It lets you edit images in natural language with very good consistency and gives a future image of what is to come.

We just need to add that to a provider now and we will have a way for a chatbot or another prompting interface to change images directly inside Drupal using natural language.

Use Tavily in your agents to do web searches and research

The Tavily module got another release - 2.0.0-rc3. Tavily is a service specifically designed for connecting your agent to the web.

The main feature of this release is a function call that you can use in your agent to do web searches to get either full html scraped webpages or markdown versions of the websites it finds.

This means that you can have an agent summarizing some topic for you or fact checking something for you.

See more here: https://www.drupal.org/project/tavily

Support for Fibers

Currently the AI module is treating any provider synchronously. This means that if you ask for instance OpenAI four different things that are not dependent on each other, we at the moment run the first one, start the second one when the first one is done and so on.

This change makes sure that we can utilize Fibers in PHP and run this asynchronously, so the process only becomes as slow as the slowest of the four calls in this case.

Currently we have no real case usage of this, but future jobs like for instance AI Translate, where each field translation is independent of the other, could work in parallel to translate a lot faster.

See: https://www.drupal.org/project/ai/issues/3538027

Removing code reiteration and reusing provider standards

A lot of providers today are using a standard that OpenAI created for its messaging API platforms. This means that a lot of providers can actually reuse a lot of code that we initially set up for the OpenAI provider.

The problem is that you do not want to make a provider dependent on the OpenAI provider, just because you want to inherit functionality from it.

Because of this we have opted to create a base class for OpenAI based providers, outside of the normal base class.

You can see the base class here.

We have already started removing huge chunks of code that was just duplication of code found in other providers.

Other smaller but noticeable fixes:

• The AI Translate’s Drush command to translate can now take multiple ids, instead of just one: https://www.drupal.org/project/ai/issues/3537084

• We have added a marker interface for all exceptions the AI module throws, so you can catch em’ all: https://www.drupal.org/project/ai/issues/3542498

• The StreamIteratorInterface has been worked over for 1.2.x release, without being backwards breaking, but with provider developers needing to take a step to make logging of the response working. This is to prepare for making tool calling possible using streamed output:

  • https://www.drupal.org/project/ai/issues/3541471

  • https://www.drupal.org/project/ai/issues/3541472

Stay tuned for further bi-weekly Drupal AI development progress. Visit the Drupal AI Initiative home for ways to connect and get involved.