A proposal emerging from the LocalGov Drupal community outlines a shared, open-source approach to committee management in councils. Known as Project Quorum, the initiative focuses on consolidating governance workflows—meetings, agendas, documentation, and public access—into a single Drupal-based platform. While such systems are often overlooked in digital prioritisation due to fragmented usage patterns, community feedback suggests the tool addresses persistent operational gaps across councils.

Stanford WebCamp 2026 opens its doors today, and as always, it will cost nothing to attend. Free, open, and community-driven for sixteen years, this year's edition arrives at a charged moment for the web: AI is reshaping institutional infrastructure at scale, while the open source values that built the web continue to hold their ground. From a keynote on AI as infrastructure to sessions on accessibility and mentorship, WebCamp 2026 reflects a conversation the web community is having with itself.

What's New

• Ubuntu 26.04 and Fedora 44 were released this week. We checked, and we're proud to say that DDEV works great on both. We have one small docs change for the Ubuntu 26.04 native install. The Windows Installer did fail with an Ubuntu 26.04 distro because the wslu package has been removed, but we fixed that in PR, and it has an easy workaround anyway.
• coder.ddev.com Updates → More work is ongoing with Coder.ddev.com, we're hoping to make it fulfil even more of your ambitions. drush works again for Drupal's main branch, and there are lots of other updates. Lots of other updates. Visit coder.ddev.com and start.coder.ddev.com for more, and we'd love to hear your suggestions and experiences at coder-ddev repository or in the DDEV Discord. We've deployed a staging server, and have plans for automated testing of changes so we don't just deploy and try them out.
• Intel Macs have run their course → We'll be retiring our three macOS AMD64 test runners. There's not much more for them to do, so we're going to turn them off. Only 7.3% of you are still using Intel Macs and it's been a very long time since we saw a regression or problem on the Intel test runners that wasn't also caught by the Apple Silicon runners. See the stats.

Talking Drupal Podcast

Stas and Randy appeared on episode 549 of the Talking Drupal podcast. Get the inside scoop on latest DDEV updates, the DDEV Drupal Contrib add-on, coder.ddev.com, and more. Listen to episode 549↗

DrupalDevDays Athens 2026

Community member bserem presented "From Chaos to Consistency" at DrupalDevDays Athens 2026, a DevOps session covering how DDEV brings order to local development environments. View the presentation slides↗. His correct and well-explained thesis is that DDEV add-ons are just a file/feature delivery mechanism that can be used to systematize your team's projects. Watch here for a blog from him!

Community Highlights

A new book on DDEV! Set Up Drupal in 10 Minutes: A Practical DDEV & Composer Guide for Developers. English on Amazon, Italian on Amazon Italy.

Who remembers Mike Anello's 2018 book Local Web Development With DDEV Explained: Your Step-by-Step Guide to Local Web Development With DDEV? 4.6 stars! (Mike is now Treasurer and Board Member of DDEV Foundation, this is how you move up in the world!) My bet is that most of what he described there still works, although many things probably work better now.

Contributor Training

Add-on Creation and Maintenance Contributor Training: Watch it↗

TYPO3 Update for DDEV

The TYPO3 community published a post on what's new in DDEV for TYPO3 developers. Read on TYPO3 News↗

Community Tutorials from Around the Web

• Getting Started with Search API in Drupal → WebWash covers how to set up and use the Search API module in Drupal — useful alongside a DDEV local environment. Read on WebWash↗
• DDEV AI Workspace: Full Drupal AI Development Setup → Read on menetray.com↗

Governance

The next DDEV board and advisory group meeting is May 6, 2026 at 8:00 AM US Mountain / 10:00 AM US Eastern / 16:00 CEST. Add to Google Calendar • See the agenda.

Note: Randy on Vacation May 19–June 9

Randy will be away May 19 through approximately June 9, on a bike trip in Sicily. The community will carry on!

Sponsorship Update

Sponsorship is at 79% of the goal — thank you to everyone who has contributed!

March 2026: ~$9,294/month (77% of goal)

April 2026: ~$9421/month (79% of goal), making progress, thanks!

If DDEV has helped your team, consider sponsoring. Whether you're an individual developer, an agency, or an organization, your contribution makes a difference. → Become a sponsor↗

Contact us to discuss sponsorship options that work for your organization.

Statistical Tidbits of the Month

• About 19,000 users report using DDEV each week, live graph.
• SO MANY macOS Docker Providers, live graph.

Stay in the Loop—Follow Us and Join the Conversation

• Blog↗
• LinkedIn↗
• Mastodon↗
• Bluesky↗
• Discord↗

Compiled and edited with assistance from Claude Code.

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.

Inside the Answer Gap: Winning Visibility in the Age of AI Search kdavis Mon, 04/27/2026 - 12:55 Topic Artificial Intelligence Summary Phase2, Yext, and iPullRank joined forces to explore what it takes to stay visible as AI reshapes how customers find answers. When platforms like ChatGPT, Claude, and Perplexity respond to customer queries, your brand is either part of the conversation — or it isn't. Watch the replay to discover what drives AI citation decisions and how to ensure your brand earns its place. Promo Image Yext Webinar Replay.png

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.