As we migrate more projects to GitLab on git.drupalcode.org, we have discovered improvements to make in the mapping of Drupal.org project maintainers to GitLab’s project members, ensuring that it is a 2-way synchronization.

The next time you update maintainers for your project on Drupal.org, this will update all maintainers’ access in GitLab. Please review project members in GitLab, and under Activity, the Team events. Syncing is now more thorough, so there might be more maintainership and member changes than you expect.

In the next few days we plan to bulk update GitLab project members for all projects that have maintainers with “Maintain issues” on Drupal.org, granting them the project planner role in GitLab. This will enable more access for them to manage issues and merge requests in GitLab.

We reviewed all the mappings and have settled on:

• “Write to VCS” on Drupal.org grants the GitLab project developer role.
• Having both “Administer maintainers” and “Write to VCS” grants the GitLab project maintainer role.
• “Maintain issues” grants the GitLab project planner role.
• Other Drupal project maintainership roles are not synced.

Syncing is two-way, so that saving maintainers in Drupal will keep choices made in GitLab.

• Maintainer in GitLab grants “Write to VCS” and “Administer maintainers,” matching GitLab’s “Administer maintainers” permission on Drupal.org.
• Developer grants “Write to VCS” and removes “Administer maintainers.”
• Planner grants “Maintain issues” and removes both “Write to VCS” and “Administer maintainers.”
• Reporter and Guest remove “Maintain issues,” “Write to VCS,” and “Administer maintainers.”

Reporter is very similar to planner, however it acts the same as guest for maintainership mapping. This preserves access when flipping between setting permissions in GitLab or Drupal. Access to “Maintain issues” in Drupal is mostly irrelevant with issues migrating.

Maintainer in GitLab previously did not grant “Administer maintainers.” It should because in GitLab, it allows the Manage project members permission, so it is a direct mapping.

Removing a maintainer in GitLab will

• If they were the project node author on Drupal.org, assign authorship to another person with “Administer maintainers,” or fall back to Unsupported projects.
• Remove “Maintain issues,” “Write to VCS,” and “Administer maintainers.”
• Not change access to “Edit project” or “Administer releases.”
• If they have no remaining Drupal.org project maintainership roles, completely remove them as a maintainer.

In addition to filling the gaps in the mappings, updates to maintainership in GitLab were missed, we hadn’t implemented a listener for the user_update_for_team webhook. So updating maintainers on Drupal.org will catch up all project member roles in GitLab.

Once all issues are migrated, “Maintain issues” will be removed from Drupal, and GitLab itself will be the only way to manage access below developer.

You can find the full details in the issue at #3586519: Migrate maintainers from Drupal.org projects as GitLab members

For any specific implementation questions, please comment on the issue. For general feedback, post to Drupal Slack's #gitlab-issue-feedback channel. 

DrupalCamp Ottawa 2026 will take place on 1 May 2026 at the Canada Science and Technology Museum, continuing its free, community-driven format. This year’s programme reflects a shift toward practical adoption, with sessions centred on Drupal 11, accessibility, multilingual delivery, and AI integration. Organisers describe the event as designed to balance technical depth with open participation, bringing together local and global contributors across disciplines.

Preamble

I've been discussing and committed to a Schema.org-first approach to building content models in Drupal for several years. Along the way, someone described Schema.org as "food for machines."

Originally, for Schema.org "machines" meant search engines; now it definitely means AIs and LLMs. Defining and generating accurate, well-structured Schema.org JSON-LD for a website is challenging and often treated as an afterthought. Even if you use my Schema.org Blueprints to create a Schema.org-first content model, it still requires significant work to set up and maintain.

AI can analyze vast amounts of information and provide instant answers to complex questions, or complete challenging tasks within minutes. Last year, I began to see how one could prompt an AI to recommend the ideal Schema.org JSON-LD markup by providing URLs to example content and linking to the appropriate Schema.org types and properties. Keep in mind that the LLMs behind AIs understand every public webpage and actively examine every piece of Schema.org markup on the web.

This realization led me to the notion that in Drupal, we can leverage our existing AI modules and tools to have AIs generate Schema.org JSON-LD markup for content with as little as a well-thought-out prompt.

Before I introduce you to my AI Schema.org JSON-LD module, three things need to be stated immediately and will be addressed in this post and a follow-up.

The remainder of this post is directly copied from the module's project page, with the understanding that additional posts are needed to cover the implications of this module for developers, such as myself, and for site builders and owners.

About this module

The AI Schema.org JSON-LD module provides a...Read More

Eduardo Telaya spent months reviewing Drupal code where the same AI-generated mistakes kept appearing across projects. Rather than treating them as isolated issues, he identified a structural gap between AI tools and Drupal best practices. That insight led to Drupal AI, a toolkit of skills, rules, and agents designed to guide coding assistants and reduce technical debt in AI-assisted development.

Building a flexible Frontpage has historically been a challenge in Drupal. Often, there is no fixed data model, and editors need the ability to quickly add, remove, or rearrange content. In this article, we compare how Canvas and Display Builder handle this scenario without relying on predefined fields, using only components. After all this will allows us to build all kinds of flexible pages, not just the Frontpage.

Every framework's API surface sits on a spectrum, from strict (typed interfaces, schemas, service containers) to loose (string keys, naming conventions, untyped hooks). Strict APIs cost more upfront: more boilerplate, more to learn before writing code. Loose APIs shift that cost later: more ambiguity, more reliance on naming conventions, and more bugs that are harder to detect and fix.

AI changes who pays. Boilerplate and learning curves don't slow agents down. What slows them down is missing feedback: code that runs but does the wrong thing, errors that don't point to the cause, conventions that have to be guessed. Magic-name binding, untyped hooks, unvalidated configuration, and conventions the code doesn't enforce produce exactly those failure modes.

Magic strings break the loop

For example, both Drupal and WordPress have long used magic-string hooks. In Drupal, you write a function like mymodule_user_login. WordPress uses a related pattern: a string action name passed to add_action(). In both cases, the binding is a string the language can't validate.

Get the name wrong and the system silently skips your code: no error, no warning, nothing in the logs. The function just sits there, unloved.

The signature is a convention, not a contract: the documentation says the user_login hook receives a $user object, but nothing enforces it. To your IDE or a static analyzer like PHPStan, it's just a function. They don't know it's wired into the platform's login flow, so they can't warn you when it's wrong.

A typed alternative makes the binding explicit. With a PHP attribute like #[Hook('user_login')] on a registered service, the class must exist, the method signature is type-checked, and the container wires the dependencies. IDEs, static analyzers, and AI coding agents can follow the chain from the attribute to the implementation.

For AI agents, this keeps the feedback loop tight instead of turning it into trial and error. That means they can move faster, spend less time debugging, and use fewer tokens.

At DrupalCon Chicago this March, AI coding tools migrated a Lovable-generated site into Drupal in hours. The strict APIs kept the agent on track.

A bet made before AI existed

This didn't start with AI. Drupal 8, which we shipped in 2015, introduced Symfony's routing, services, and event dispatcher, replacing large parts of the procedural hook system. Since then, we've kept reducing magic hooks. The attribute-based approach (#[Hook('user_login')]) landed in Drupal 11.1 and helps remove more of the remaining procedural-only paths.

Hooks aren't the only place Drupal has been getting stricter. Drupal stores a lot of configuration in YAML, which was one of the loosest parts of the system. A multi-year validation effort has been tightening that.

When an agent generates a content type definition or editor configuration, validation catches missing keys, invalid values, and broken references before anything is saved. The agent gets a precise error pointing to the exact field, instead of a runtime failure. That tight feedback loop is what makes Drupal a strong CMS for AI-assisted development.

Drupal made this bet early, and it was painful. The Drupal 7 to Drupal 8 transition broke backward compatibility and took years to recover from. But it left the platform much stricter. More than ten years in, we're still making Drupal stricter.

Meanwhile, WordPress made a different bet, prioritizing backward compatibility over stricter APIs. That kept the platform stable for a long time. It also kept the looseness.

Those trade-offs now determine how efficiently AI agents can work with each platform.

What was style is now speed

What used to be a stylistic choice is now a speed and cost problem. Loose APIs mean more debugging and guesswork. Strict APIs mean faster, more precise feedback. This was always true for humans. It's now also true for AI agents. But today that cost shows up in tokens.

Join us to hear directly from the team behind an award-winning AI solution built for local government. What does genuinely useful AI in public services look like? Not a concept, not a pilot, but a working solution that saves hours of manual work, improves accessibility, and puts better content in front of citizens faster.

Southwark Council's AI-powered PDF importer for Drupal is exactly that, and it won the prestigious Digital Leaders AI Impact Award 2026.

We are delighted to invite you to a webinar where you can hear the story first-hand.

About the webinar

Date: Tuesday 16th June | 16:00 BST
Guest: Angie Forson, Web and Digital Programme Lead, Southwark Council
Host: James Hall, Product Lead, Websites at Everyone TV

This is a rare opportunity to hear directly from a senior stakeholder about how Drupal and AI are delivering real, measurable value in an area that truly matters: public services for the citizens of Southwark.

Angie will walk through the journey, the challenges, the outcomes, and what it means for the wider local government sector.

Register for the webinar →

The problem it solves

Manual PDF conversion has long been one of the most time-consuming tasks facing council web teams. Converting a single document can take hours. Multiply that across thousands of PDFs and the burden becomes significant, both in staff time and in the delay it creates before citizens can access accurate, accessible information.

The Southwark team, working with their partners at Chicken, built an AI-powered importer for the LocalGov Drupal Publication Module that reduces that process to minutes, often under one minute.

How it works

Each PDF passes through a three-step pipeline:

1. Extract - a PDF parser pulls the raw content from the document
2. Transform - AI converts it to properly structured, accessible HTML with logical pagination
3. Save - clean HTML pages are ready to review and publish directly in Drupal

The result is an HTML representation of the PDF content, saved into a Drupal Publication and ready for review before going live. Every import is logged, so errors can be identified and resolved efficiently.

The module uses a plugin architecture, meaning each step in the pipeline can be swapped out. Councils can use different extractors, AI models, or output to different Drupal content types, making the solution adaptable to a wide range of content and operational requirements.

Built the right way

The team delivered this project with an agile, user-centred approach, continuously refining requirements to ensure the tool meets real user needs rather than simply ticking a technical specification.

"This project is a great example of AI working alongside and empowering content creators, and Drupal as a platform supports this really well." - Farez Rahman, Drupal Developer

"I'm excited about the impact this product will have, not just for our users, but also in transforming how we design, build, and create content internally. We're shaping a future where services start with HTML-first thinking." - Evelyn Francourt, User Experience Lead

Why this matters beyond Southwark

Local government teams across the country face the same challenge. This solution, built on open source Drupal and the LocalGov Drupal ecosystem, is designed to be shared, not kept in one place.

If your organisation publishes PDFs, manages large volumes of content, or is exploring where AI can deliver practical value without unnecessary complexity, this webinar is for you. Tuesday 16th June | 16:00 BST | Online.

Register for the webinar →
 

Schema.org markup can make or break your search visibility, but writing it by hand across hundreds of nodes is unrealistic. What if your CMS just did it for you? Find out in this blog.

The SaaS tools you rely on are costing more than you think. We make the case for building software your business actually owns, on a platform built to last.

Stas Zhuk and I covered the full add-on lifecycle in this Contributor Training session: bootstrapping from the ddev-addon-template, writing Bats tests, testing locally and against branches or open PRs, and publishing to the registry. The session also covers use cases beyond service providers — custom commands, DDEV hooks, and distributing team workflows across projects.

The slides are available online (source).

What Are DDEV Add-ons?

Most people first encounter add-ons as service providers — Redis, Elasticsearch, Solr, Mailpit — but Bill Seremetis (bserem) put it well in his DrupalDevDays Athens 2026 talk: "an add-on is a set of files: hooks + commands + scripts + config — it's a distribution mechanism." His agency uses a single custom add-on across 100+ Drupal projects to encode institutional knowledge, enforce quality gates, and deliver the team's workflows to the terminal. One update to the add-on propagates improvements to every project. That framing opens up a lot: custom commands that automate your team's processes, DDEV hooks that fire at key checkpoints (sanitize the database on import, install Git hooks on project start), and boilerplate configs or scripts distributed automatically to wherever they're needed.

The heart of every add-on is an install.yaml, which defines what files get placed at the project-level or globally, plus pre_install_actions and post_install_actions that can run shell or PHP scripts during install.

Getting started with a new add-on is straightforward: use the ddev-addon-template, which wires up GitHub Actions CI and a tests/test.bats Bats test suite from the start. You can test locally before publishing with ddev add-on get /path/to/your/addon, against a branch with --version branch-name, or against an open PR with --pr 54. When ready to publish to the world (if you want to), add the ddev-get topic to your GitHub repository and it will appear in addons.ddev.com within about 24 hours.

Resources

• DDEV Add-on Documentation — the official reference for creating and maintaining add-ons
• DDEV Add-on Registry — browse the full catalog of community add-ons (see also: registry introduction)
• Add-on Maintenance Guide — guidance for maintaining add-ons over time
• Anatomy of an Advanced DDEV Add-on — a deep dive into a complex add-on with a custom container

Contributions Welcome!

Your suggestions to improve this blog are welcome. You can do a PR to this blog adding your techniques. Info and a training session on how to do a PR to anything in ddev.com is at DDEV Website For Contributors.

Follow the DDEV Newsletter for information about upcoming user and contributor training sessions.

Accessibility requirements for websites are increasingly being enforced across public and private sectors, affecting Drupal-based systems used by governments, universities, and businesses. Compliance with WCAG standards is no longer treated as a one-time milestone but as an ongoing responsibility that spans both system configuration and everyday content publishing.

In a recent LinkedIn post, John Harris highlights how reliance on automated scans often leaves significant gaps in accessibility compliance, particularly in areas that require manual validation and editorial oversight.

At the same time, accessibility in Drupal environments continues to depend on both technical systems and publishing practices, with emerging risks from AI-generated content further complicating matters. These factors point to accessibility as a continuous, shared responsibility rather than a fixed checkpoint.

Here is a selection of Drupal stories published over the past week.

ORGANIZATION NEWS

• DevBranch BootCamp Expands as Entry Pathway for Drupal Talent
• TDT Townhall Reviews Editorial Progress and Community Direction in April Session
• HOOK_DEV_ALTER Launches Drupal Consulting Offering for Agencies and Large Projects

FREE SOFTWARE

• Dries Buytaert Questions “Buy European” as a Durable Digital Sovereignty Strategy

DISCOVER DRUPAL

• Drupal AI Initiative Marks One Year Since Leuven Origins
• AI-Assisted Drupal Module Built in Under Six Hours Highlights Review Challenges
• ECA Breadcrumbs Module Adds No-Code, Dynamic Control to Drupal Navigation
• Drupal Module Enables Direct WordPress Database Migration Without WXR Files
• Drupal 11.4 Introduces PHP Attribute-Based Routing for Controllers
• Shibin Das Seeks Community Input on Releasing LLM-Based Drupal Workflow Builder
• Local Data Sanitiser Module Adds CLI Tools for Cleaning Drupal Databases
• Node Cleanup Module Adds Bulk Deletion Interface for Unpublished Drupal Content

EVENT

• DrupalCon Rotterdam 2026 Announces First Winners of Miffy Mascot Contest
• Drupal AI Contribution Weekend Planned in Goa as Community-Led Initiative
• amazee.ai to Host Webinar on OpenClaw Hosting and Data Privacy
• DrupalCon Rotterdam 2026 Launches Community T-Shirt Design Contest

Additional developments from across the Drupal ecosystem were published during the week. Readers can follow The Drop Times on LinkedIn, Twitter, Bluesky, and Facebook for ongoing updates. The publication is also active on Drupal Slack in the #thedroptimes channel.

Kazima Abbas
Sub-editor
The Drop Times

In episode 550 of Talking Drupal, Rod Martin joins us to discuss how Drupal site builders are defined, how their role has changed across Drupal versions, and what the future may look like with Drupal CMS, Canvas, and Drupal AI. The show's module of the week is Password Policy, presented by Avi Schwab, covering customizable password constraints and password expiration/reset features, along with supporting modules Password Policy Extras and Password Policy Pwned, which checks passwords against the Have I Been Pwned database. The conversation also explores the challenges site builders face around layout, theming, and configuration management, and the need for better templates, workflows, and guardrails as AI-assisted site building evolves.

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

Topics

• Module of the Week: Password Policy
• MidCamp 2026 Promo
• Defining Drupal Site Builders
• Rod's Training Background
• Site Builder Role and Skills
• Comparing Drupal WordPress Joomla
• Editors vs Site Builders
• Site Building Changing in Drupal
• Layout Builder Fallout
• Canvas and AI Promise
• Barriers and Bulk Fields
• Prompt Built Architecture
• Guardrails and Nuance
• Playbooks and Context
• Drupal Must Shift
• Templates Over CMS
• Dev and Builder Handoff
• Two Paths Forward
• Recipes Upgrade Gotchas
• Closing and Contacts

Resources

NIST Password Guidelines - https://specopssoft.com/blog/nist-password-guidelines/ Password Recipe -

Emdash - https://blog.cloudflare.com/emdash-wordpress/ Talking Drupal #122 - Taxonomy or Entity Reference https://talkingdrupal.com/122

Guests

Rod Martin - DrupalHelps.com imrodmartin

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan Avi Schwab- froboy.org froboy

Module of the Week

with Avi Schwab- froboy.org froboy

Password Policy - A password policy can be defined with a set of constraints which must be met before a user password change will be accepted. Each constraint has a parameter allowing for the minimum number of valid conditions which must be met before the constraint is satisfied.

Drupal 11: Cascading Select Forms With HTMX

This is part four of a series of articles looking at HTMX in Drupal. In the last two articles we looked at using HTMX with controllers in different ways. This time I'll be venturing into the world of HTMX and forms.

Years ago on this site I wrote an article about Cascading ajax select forms in Drupal, which I often refer back to when I'm trying to figure out something to do with select forms and ajax. In that article I take a year, month, and day select field and tie them together so that they influence each other during the selection process.

I've been writing Drupal sites for quite a number of years and I still need to take a deep breath before attempting to embark on implementing ajax in Drupal forms. I end up with form fields that have wrapper elements or custom attributes in an attempt to get things working. It always seems to be a painful experience.

When I was learning about HTMX and Drupal I sat down to re-implement this cascading select form and had something working in about half an hour. Most of that time was spend adding the form elements to the build form method. A stark difference between the old and the new ways of adding ajax to forms in Drupal.

In this article we will look at creating a form that contains multiple select elements and then use HTMX (and a little bit of the form states API) to tie them together so that selecting one element updates the others.

All of the code contained in this article can be found in the Drupal HTMX examples project on GitHub, but here we will go through what the code does and what actions it performs to generate content.   

Just like the other articles on HTMX, I'm going to start with the basics and define the route.

philipnorton42 Sun, 04/26/2026 - 18:58

DevBranch has developed its in-house Drupal BootCamp into a recurring training pathway aimed at preparing new developers for project work. The programme has run eight cohorts since 2021, training more than 30 participants, with about half receiving job offers. Details shared by Functional Manager Nataliia Khomiuk outline how changes in duration, cohort size, and skill focus reflect practical hiring and onboarding needs within distributed Drupal teams.

This is the fourth post in our GitLab issue migration series. The earlier posts focused on what is changing and how maintainers should set up their projects. This one is for the rest of us — the people who file bugs, review code, push fixes, and triage queues without wearing a maintainer hat. If your favorite contrib project has just moved its issues to git.drupalcode.org, here's what you need to know.

What's changed at a glance

When a project's issues are migrated, they move from www.drupal.org/project/{name}/issues to git.drupalcode.org/project/{name}/-/work_items. Old URLs redirect to the new ones, and issue numbers (NIDs) are preserved as GitLab IIDs — so an #3409678: Opt-in GitLab issues you find in a commit message will still resolve to the same issue.

In GitLab, "issues" are technically a subtype of "work items," but the term issue still applies, and you'll see it throughout the UI. If you've worked on any GitHub or GitLab project before, the experience will feel familiar.

What still works the way you're used to

A lot has not changed:

• You can still create issues without any special role.
• The contribution credit system is unchanged. Every comment you make on a GitLab issue still syncs to its contribution record automatically. The credit UI itself still lives on drupal.org.
• Shared issue forks are still the way to collaborate (on code). Drupal still doesn't use personal forks; collaboration on a single fork remains the model. The fork management UI also still lives on drupal.org.
• The familiar workflow conventions can still apply — Needs work, Needs review, RTBC, priority levels, and so on. They were migrated as scoped labels (more on this below).
• GitLab CI still runs your tests the same way it has for the past few years.
• Your Drupal.org login still works. Single sign-on means no extra account to manage.
• Cross-references and parent/child relationships still exist, just with slightly different syntax (more on that below).

Some things actually got better

It's worth naming a few real wins for contributors:

• A modern issue editor with proper markdown, real code blocks, syntax highlighting, image paste, and a mobile-friendly UI.
• Issues and merge requests now live alongside the code, pipelines, and CI logs on git.drupalcode.org — far less context-switching during code review.
• Much better filtering, search, and saved queries on issue lists.
• Issue boards (Kanban-style) are available for projects that want them.

Who can edit what

A few permission details are worth knowing up front, because they're tighter than what you may be used to on the old issue queue:

• Anyone can comment on an issue.
• Only the original author or project maintainers can edit the issue description. This is a real change — on drupal.org, any logged-in user could edit an issue summary. If you'd like a description updated and you're not the author, leave a comment with the suggested wording so the author or a maintainer can apply it.
• Labels and other metadata (priority, version, category, component, tags) can only be edited by users with a Planner role or higher on the GitLab project.

That last point is real friction for contributors who triage and label issues, and we're addressing it directly. #3559846: Allow changing GitLab issues labels for all contributors is building a label-management UI that will live on drupal.org, alongside the existing contribution credit and issue fork management screens. Once it ships, any contributor will be able to manage labels on any issue without needing a project role on GitLab. This is also an upstream issue, but it doesn't seem to be worked on.

Until then, if metadata needs updating, leave a comment noting what should change. Maintainers and other contributors with the role can apply it.

Old workflow conventions can still apply

Good news for anyone with muscle memory for Drupal's NW / NR / RTBC dance: the conventions weren't dropped in the migration. They were preserved as scoped labels on GitLab issues — state::rtbc, the equivalent state labels for needs-work and needs-review, priority labels, and so on. Each project's setup may vary, but the familiar conventions carried over, and contributors can keep using them.

Convention Now Needs work state::needsWork label (alternative: MR set to Draft) Needs review state::needsReview label (alternative: MR set to Ready) RTBC state::rtbc label (alternative: MR approval) Needs reroll Push a rebase to the issue fork branch

Two notes:

• Applying these labels yourself currently requires the Planner+ role on the project, until #3559846 ships the contributor label UI. In the meantime, a comment indicating the status you'd assign is the right move.
• Merge request states are a useful parallel signal: an MR's Draft / Ready toggle and approval status reflect the actual code change being reviewed, which often communicates more clearly than a label on the parent issue. Some projects lean heavily on MR state, some on labels, some use both — there's no single right answer.

Day-to-day: how to do common things Create an issue

Navigate to the project, click Issues in the left sidebar, then New issue. The form is just a title and description; labels and metadata are added afterwards by users with the appropriate role. If a project has set up issue templates (markdown files in the repo), you'll see them in a dropdown.

The first auto-generated comment

The first comment on every new issue is posted by DrupalBot. It's the bridge to the things that still live on drupal.org:

• A link to the contribution record (where credit is tracked).
• A link to the fork management page, where you can create or request access to a shared fork, view existing MRs, and open a new one.
• Once #3559846 ships, a link to the contributor label management UI.

Forks and merge requests

The fork management screen on drupal.org works the same way for GitLab issues as it has for Drupal.org issues. From there, you can create a shared issue fork, request access if one already exists, push a branch, and open an MR. Branching and merging happen in GitLab's native UI, where they're already optimized.

Linking issues across systems

During the transition, contributors will be working with both Drupal.org issues and GitLab issues, sometimes in the same comment. The syntax differs by direction:

• Drupal.org → Drupal.org issue Brackets around the issue number (without spaces): [ #123456 ] (unchanged)
• GitLab → GitLab issue (same project): #123456 (no brackets)
• Cross-platform (either direction): paste the full URL

For "related issues" entries on Drupal.org, always use the full URL when pointing at a GitLab issue.

Things you might notice on migrated issues

A few oddities are worth flagging if you're working through historical issues:

• DrupalBot is listed as the author on every migrated issue. (Issues created after migration correctly show their actual creator.) The GitLab API forced a tradeoff between preserving the original author and preserving the issue ID. We chose to preserve the ID so that #123456 still maps to the same issue. The original author's name is preserved in the first line of the issue description.
• Old drupal.org issue URLs redirect to their GitLab equivalents, so existing links in commit messages, blog posts, and external references continue to work.

Reporting bugs and getting help

Found a bug in the migration itself or in the integration between Drupal.org and GitLab? Please file it in the Drupal.org customizations issue queue.

Have a question, or want to share feedback on the new workflow? Join the #gitlab-issues-feedback channel on the Drupal community Slack.

We're actively iterating on this transition based on what we hear from contributors and maintainers in opted-in projects. The more feedback we get now — while we're still in the opt-in phase — the better the experience will be when the rest of contrib gets batch-migrated.

Reference: GitLab documentation

For more detail on any of the GitLab features mentioned in this post, the official GitLab documentation is the canonical source.

Issues and work items

• Issues overview
• Create an issue
• Work items
• Description templates
• Crosslinking issues
• Issue boards

Labels and permissions

• Labels (including scoped labels)
• Roles and permissions

Merge requests

• Merge requests overview
• Draft merge requests
• Merge request reviews and approvals

Markdown

• GitLab Flavored Markdown

Related blog posts in this series:

• GitLab issue migration: immediate changes
• GitLab issue migration: the new workflow for migrated projects
• GitLab issue migration: how to use the new workflow
• GitLab issue migration: a contributor's perspective (this one)
   

Related issues

• Opt-in your project for migration to GitLab Issues. Eventually, all projects will be migrated.
• Provide feedback on the GitLab issue migration.
• General issue for the GitLab migration.

* We used Claude AI to refine our first draft and help link related materials like the GitLab documentation.

One year ago, at Drupal Developer Days in Leuven, something special happened.

The Drupal AI Initiative was not officially launched yet. That would happen later, in June. But Leuven was where the spark happened. It was where the first real momentum came together. Where conversations turned into commitment. Where a shared belief became a shared plan.

Five companies stepped up to kickstart the initiative: Dropsolid, Acquia, 1xINTERNET, FreelyGive, and Salsa Digital. Together, they helped turn an ambitious idea into the beginning of a movement.

Now, one year later, as we gather again at Drupal Developer Days in Athens, we celebrate one year since that moment of conception.

Leuven was where the initiative was kickstarted. June was when it officially went live. Athens is where we celebrate how far it has come.

A year of momentum, collaboration, and delivery

The Drupal AI Initiative was created with a bold ambition: to help Drupal become the leading open source CMS for AI-powered digital experiences.

But from the beginning, this was never just about adding AI features.

It was about building AI into Drupal in a way that reflects the values of the Drupal community: open, flexible, responsible, transparent, and collaborative. It was about giving organizations the tools to innovate with AI while keeping control over governance, content, security, editorial workflows, and long-term digital strategy.

Over the past year, the initiative has grown from a spark in Leuven into one of the most ambitious collaborative efforts in Drupal’s history.

What has been delivered?

Since the official launch of the Drupal AI Initiative, the team has made major progress. The amount of installs is growing significantly, 13980 at the time of writing. Adoption is accelerating. According to shared data we’re growing at about 260 sites per week and accelerating.

This is only the sites that share numbers, the real share is much higher. 

Growing numbers of Drupal AI Partners

Between Drupal Con Vienna and Chicago, the initiative added 12 new partners, a total of 34, representing a 50% increase in participation. We are on track to match this growth in support between now and DrupalCon Rotterdam, a key goal for this year.

Delivering capabilities at scale

The initiative also successfully established and executed the delivery management RFP process, putting important operational frameworks in place, including:

• Partner expectations documentation
• Onboarding processes
• Development sprint processes
• Contribution tracking
• Team planning sheets
• Weekly status reporting

These may sound like operational details, but they are what make collaboration at scale possible. They help turn enthusiasm into structure, and structure into delivery.

The Drupal AI Initiative has become the largest multi-company collaboration in Drupal community history.

- Dries Buytaert

The initiative is now actively funding critical roles across multiple organizations, including product management, innovation management, technical leadership, and program management. This marks a major milestone: the Drupal AI Initiative has become the largest multi-company collaboration in Drupal community history.

The 2026 roadmap was finalised earlier this year, informed by customer demand and industry insight. Delivery is actively underway.

At the same time, marketing efforts have been elevated to position Drupal as the leading AI-powered open source CMS globally, supported by ongoing storytelling and visibility through the Drupal AI Initiative blog.

Significant rise contribution

Focused effort on strategically important features, combined with a growing number of partners committing resources and strong community participation, has driven a significant increase in momentum and impact.

The tag clouds below visually represent the many Drupal community members who in the past 12 months have contributed to the AI Initiative (sized according to number of fixed issues worked on). Includes code and non code contributions. 

The following organizations have also contributed to the Drupal AI Initiative in the past year.

Marketing Drupal AI

From small beginnings with Paul Johnson and Frederik Wouters taking on marketing, we now have a cross disciplinary high performing team with 10 leads across areas of specialization.

Focussing on introducing Drupal to new audiences the emphasis has been on webinars, participating in external events and organising major new customer facing events of our own. These include Drupal AI Summit Paris and New York City (14th May 2026), The AI Summit London (10-11 June 2026) and the latest Enterprise AI Summit Rotterdam (28 September 2026).

Our work has included facilitating Southwark Council, London, winning Digital Leaders AI Impact Award 2026, producing video case studies and highlighting major new AI features announced during the DriesNote with social video content. All these activities have substantially raised Drupal’s profile to a wider audience.

Building toward Rotterdam

The next major milestone is already taking shape.

In Rotterdam, the initiative will launch an exclusive Drupal Enterprise AI event, available only to Drupal AI Initiative partners. The event will bring together European decision-makers aboard the SS Rotterdam for peer networking, customer case studies, and strategic conversations about building AI-powered content management solutions with Drupal.

Participation in this event is limited to partners who join the Drupal AI Initiative by June 30.

That creates a powerful moment for companies that want to be part of Drupal’s AI future. The initiative is scaling, the roadmap is active, the team is growing, and the opportunity to help shape what comes next is open now.

A strong foundation for what comes next

The Drupal AI Initiative is in a strong position.

With $380,000 in cash and $1.5 million in in-kind contributions, more than 50 contributors from partners, the initiative has the resources and commitment needed to continue scaling. The plan is to onboard an additional 12 partners by Rotterdam, further strengthening the team and accelerating delivery.

The message is clear: You counted on Drupal AI, and we delivered. Now we want to create more efficiency and scale.

That is what this next phase is about. More delivery. More visibility. More impact.

Thank you to the people who made this possible

This milestone belongs to many people.

It belongs to everyone who joined those early conversations in Leuven.

It belongs to Frederik Wouters, who brought the right people together at the right moment and helped create the spark that started it all.

It belongs to the five companies that kickstarted the initiative: Dropsolid, Acquia, 1xINTERNET, FreelyGive, and Salsa Digital.

It belongs to every partner, contributor, sponsor, strategist, developer, product thinker, marketer, and community member who has helped move this initiative forward.

And it belongs to the wider Drupal community, whose openness and willingness to collaborate make initiatives like this possible.

You can still join

The Drupal AI Initiative is growing, and companies can still become part of it.

If your organization believes in the future of Drupal, if you want to help shape responsible AI in open source, or if you want to be part of the group building the next generation of AI-powered content management, now is the time to join.

Become part of the 34 makers already helping to build Drupal’s AI future.

To join the Drupal AI Initiative as an organization and become a partner, contact Dominique at dominique@dropsolid.com.

From Leuven to Athens, this has been an incredible first year.

And the best part? We are only just getting started!
 

File attachments:  54456328639_3949c293a3_k.jpg adoption.png partners.png tagcommunitytop.png tagcommunitybottom.png tagcompanies.png 10team.png events.png rotterdam.png scaling.png

A business spends hundreds of thousands of dollars with a developer or agency to build an eCommerce website, endures years of instability and missed deadlines, and then concludes that the platform just doesn’t work. They start eyeing Shopify or whatever choice platform the first consultant they engage recommends, hoping the grass will be greener. Meanwhile, the actual issue—an underqualified or negligent service provider—walks away unexamined.

Developer problems are often disguised as platform problems. We’ve seen this situation many times with Drupal Commerce implementations that aren’t performing as desired. We’ve even solved issues merchants put up with for years in a matter of hours. It’s not that we’re special, though we do know our own platform better than anyone else. We believe any competent Drupal developer would also be able to identify and solve these issues, possibly just as quickly.

So how do you tell the difference? How do you know your issues stem from your developer, and not your platform?

Below, we’ll give you the language and the lens to evaluate whether your developer is actually serving you well, or whether they’re the reason your Drupal Commerce site feels like it's held together with duct tape and bubblegum.

How some developers get in over their heads

A company needs a Drupal website with eCommerce capabilities, so they search for a Drupal developer. Maybe they already have a Drupal website and want to add some commerce features. Either way, they find a freelancer who has built blogs, nonprofit sites, and maybe a university portal with some advanced functionality. That person says, "Sure, I can handle commerce. It’s just another module." For a basic eCommerce website with minimal traffic, maybe they can.

Read more

Search behaviour is changing as AI-generated answers take over SERPs, reducing clicks and redefining performance metrics. Understand the AI impact on CTR, SEO, and why your marketing strategy needs to adapt.

When Views meets Drupal Canvas -- getting dynamic content into your Canvas page John Locke Tue, 04/21/2026 - 08:00

From early days, "views" has been the killer feature of Drupal. Views is a powerful querying tool built into Drupal that allows dynamic lists and displays of content to be created without writing custom code.

Dev Corner

• Read more about When Views meets Drupal Canvas -- getting dynamic content into your Canvas page
• Add new comment