We are pleased to announce that Peter Hinssen will be the keynote speaker at the Enterprise Drupal Summit Europe 2026 in Rotterdam on 28 September 2026.

Setting the stage

Peter Hinssen will open the summit with a session on how organizations deal with continuous disruption and long-term digital change — a topic he has spent decades researching, writing about, and bringing to stages around the world.

With over 1,500 keynote presentations delivered to Fortune 1000 companies and leading organisations globally, Peter brings a rare combination of strategic depth, clarity, and a dry sense of humour that turns strategy into clarity.

He is also the bestselling author of six business books, most recently The Uncertainty Principle (2025), a guide for leaders navigating what he calls the "Never Normal" — a world where disruption is not an exception but the baseline. 

Why this matters for your enterprise

The summit focuses on AI in enterprise environments, where change is structural rather than incremental. Peter's keynote sets the strategic context for the day's discussions across three key themes:

• AI in enterprise content systems
• Composable digital platforms
• Digital transformation in complex organizations

Because in enterprise environments, the question is no longer whether to adopt AI, but how to do it strategically.

Join us in Rotterdam

Enterprise Drupal Summit Europe 2026 brings together practitioners and decision-makers working on AI (and Drupal) at scale.

The program focuses on real implementations, architecture decisions, and operational lessons from enterprise and public sector environments.

A room full of decision-makers, and there's a seat with your name on it.

More information: summit.enterprisedrupal.eu

We are pleased to announce that Peter Hinssen will be the keynote speaker at the Enterprise Drupal Summit Europe 2026 in Rotterdam on 28 September 2026.

Setting the stage

Peter Hinssen will open the summit with a session on how organizations deal with continuous disruption and long-term digital change — a topic he has spent decades researching, writing about, and bringing to stages around the world.

With over 1,500 keynote presentations delivered to Fortune 1000 companies and leading organisations globally, Peter brings a rare combination of strategic depth, clarity, and a dry sense of humour that turns strategy into clarity.

He is also the bestselling author of six business books, most recently The Uncertainty Principle (2025), a guide for leaders navigating what he calls the "Never Normal" — a world where disruption is not an exception but the baseline. 

Why this matters for your enterprise

The summit focuses on AI in enterprise environments, where change is structural rather than incremental. Peter's keynote sets the strategic context for the day's discussions across three key themes:

• AI in enterprise content systems
• Composable digital platforms
• Digital transformation in complex organizations

Because in enterprise environments, the question is no longer whether to adopt AI, but how to do it strategically.

Join us in Rotterdam

Enterprise Drupal Summit Europe 2026 brings together practitioners and decision-makers working on AI (and Drupal) at scale.

The program focuses on real implementations, architecture decisions, and operational lessons from enterprise and public sector environments.

A room full of decision-makers, and there's a seat with your name on it.

More information: summit.enterprisedrupal.eu

Drupal core includes a database abstraction API to ensure that queries executed against the database are sanitized to prevent SQL injection attacks.

A vulnerability in this API allows an attacker to send specially crafted requests, resulting in arbitrary SQL injection for sites using PostgreSQL databases. This can lead to information disclosure, and in some cases privilege escalation, remote code execution, or other attacks.

This vulnerability can be exploited by anonymous users.

This vulnerability only affects sites using PostgreSQL. However, the dependency updates in this release apply to all sites.

Upstream security advisories

The Drupal releases for supported branches (11.3, 11.2, 10.6, and 10.5) in this advisory also include security updates for Symfony and Twig. Those projects have released important Security Advisories that were coordinated with this Drupal release, and Drupal is affected by some of the vulnerabilities.

Depending on your site configuration and contrib modules, you may be vulnerable to one or more of these upstream issues, so updating these dependencies is highly recommended whether the SQL Injection vulnerability affects you or not. It is also recommended to review which user roles have the ability to update Twig templates, for example via Views or contributed modules.

Install the latest version.

The following releases will be available as soon as automated release packaging is complete. You may receive a 404 in the interim. The updates may also be available on Packagist sooner.

Drupal 11

• If you use Drupal 11.3.x, update to Drupal 11.3.10.
• If you use Drupal 11.2.x, update to Drupal 11.2.12.
• If you use Drupal 11.1.x or 11.0.x, update to Drupal 11.1.10.

Drupal 10

• If you use Drupal 10.6.x, update to Drupal 10.6.9.
• If you use Drupal 10.5.x, update to Drupal 10.5.10.
• If you use Drupal 10.4.x or earlier, update to Drupal 10.4.10.

Drupal 9 and 8

• If you use any version of Drupal 9, try manually applying the Drupal 9.5 patch for this issue.
• If you use Drupal 8.9, try manually applying the Drupal 8.9 patch for this issue.

Drupal 11.1.x, Drupal 11.0.x, Drupal 10.4.x, and below are end-of-life and do not receive security coverage. (Drupal 8 and Drupal 9 have both reached end-of-life.) Due to this issue's severity, the unsupported releases and patches for unsupported versions are provided as a best effort. Those unsupported versions will still have other, previously disclosed security vulnerabilities.

• Michael Maturi (michaelmaturi)

• Björn Brala (bbrala)
• Benji Fisher (benjifisher) of the Drupal Security Team
• catch (catch) of the Drupal Security Team
• Lee Rowlands (larowlan) of the Drupal Security Team
• Dave Long (longwave) of the Drupal Security Team
• Drew Webber (mcdruid) of the Drupal Security Team
• Jess (xjm) of the Drupal Security Team

• Anna Kalata (akalata) of the Drupal Security Team
• Benji Fisher (benjifisher) of the Drupal Security Team
• catch (catch) of the Drupal Security Team
• Damien McKenna (damienmckenna) of the Drupal Security Team
• Neil Drumm (drumm) of the Drupal Security Team
• Greg Knaddison (greggles) of the Drupal Security Team
• Heine Deelstra (heine) of the Drupal Security Team
• Tim Hestenes Lehnen (hestenet)
• Dave Long (longwave) of the Drupal Security Team
• Drew Webber (mcdruid) of the Drupal Security Team
• Juraj Nemec (poker10) of the Drupal Security Team
• Pierre Rudloff (prudloff) of the Drupal Security Team
• Jess (xjm) of the Drupal Security Team
• Cathy Theys (yesct) of the Drupal Security Team

We are proud to share that the Drupal Association has been awarded a grant from the Alpha-Omega Project, a project of The Linux Foundation, which seeks to help open source projects identify and mitigate security vulnerabilities.

As AI-generated commits and AI-driven security threats become the norm, open-source ecosystems must evolve rapidly. This funding directly strengthens the already mature Drupal Security Team, ensuring our core ecosystem is hardened against the modern, AI-age vulnerabilities.

The funding provided by Alpha-Omega will enable the Drupal Security Team to build the program we need to stay ahead in this fast moving environment. Drupal’s already excellent security position will be even better going forward.

~ Tim Doyle, CEO at Drupal Association.

Security has been a defining pillar of the Drupal ecosystem. This collaboration with the Alpha-Omega Project underscores our ongoing commitment to open-source resilience, solidifying Drupal's position as the gold standard for secure enterprise content management.

Drupal is, and will continue to be, one of the most secure CMS platforms in the world.

We are proud to share that the Drupal Association has been awarded a grant from the Alpha-Omega Project, a project of The Linux Foundation, which seeks to help open source projects identify and mitigate security vulnerabilities.

As AI-generated commits and AI-driven security threats become the norm, open-source ecosystems must evolve rapidly. This funding directly strengthens the already mature Drupal Security Team, ensuring our core ecosystem is hardened against the modern, AI-age vulnerabilities.

The funding provided by Alpha-Omega will enable the Drupal Security Team to build the program we need to stay ahead in this fast moving environment. Drupal’s already excellent security position will be even better going forward.

~ Tim Doyle, CEO at Drupal Association.

Security has been a defining pillar of the Drupal ecosystem. This collaboration with the Alpha-Omega Project underscores our ongoing commitment to open-source resilience, solidifying Drupal's position as the gold standard for secure enterprise content management.

Drupal is, and will continue to be, one of the most secure CMS platforms in the world.

Join us THURSDAY, May 21 at 1pm ET / 10am PT, for our regularly scheduled call to chat about all things Drupal and nonprofits. (Convert to your local time zone.)

We don't have anything specific on the agenda this month, so we'll have plenty of time to discuss anything that's on our minds at the intersection of Drupal and nonprofits. Got something specific you want to talk about? Feel free to share ahead of time in our collaborative Google document at https://nten.org/drupal/notes!

All nonprofit Drupal devs and users, regardless of experience level, are always welcome on this call.

This free call is sponsored by NTEN.org and open to everyone.

Information on joining the meeting can be found in our collaborative Google document.

Join us THURSDAY, May 21 at 1pm ET / 10am PT, for our regularly scheduled call to chat about all things Drupal and nonprofits. (Convert to your local time zone.)

We don't have anything specific on the agenda this month, so we'll have plenty of time to discuss anything that's on our minds at the intersection of Drupal and nonprofits. Got something specific you want to talk about? Feel free to share ahead of time in our collaborative Google document at https://nten.org/drupal/notes!

All nonprofit Drupal devs and users, regardless of experience level, are always welcome on this call.

This free call is sponsored by NTEN.org and open to everyone.

Information on joining the meeting can be found in our collaborative Google document.

There will be a Drupal core security release for all supported branches on May 20, 2026, between 17:00 and 21:00 UTC. (To see this in your local timezone, refer to the Drupal Core Calendar.) The Drupal Security Team urges you to reserve time for core updates at that time because exploits might be developed within hours or days.

The risk is currently rated as:
Highly critical 20 ∕ 25 AC:None/A:None/CI:All/II:All/E:Theoretical/TD:Uncommon.

Not all configurations are affected. Reserve time on May 20 during the release window to determine whether your sites are affected and in need of an immediate update. Mitigation information will be included in the advisory.

We recommend updating to the latest supported patch (bugfix) release for your site's version of Drupal before May 20, so that you can address any other upgrade issues before the security window. (Recommendations for specific Drupal versions follow.)

This issue is being protected by Drupal Steward. Sites that use Drupal Steward are already protected from known attack vectors, but should upgrade in the near future in case additional attack vectors are discovered.

Affected versions

Supported core versions

Security releases will be provided for all the currently supported branches of Drupal core, which are:

• 11.3.x
• 11.2.x
• 10.6.x
• 10.5.x

Sites on one of these supported versions should update to the latest patch release for the given branch now in preparation for the security window.

End-of-life minor core versions (Drupal 10 and 11)

While the Drupal Security Team does not normally provide security releases for unsupported releases, given the severity of the issue, we are providing 11.1.x and 10.4.x releases that include the fix for sites which have not yet had a chance to update. Therefore, in advance of the window:

• Sites on Drupal 11.1 or 11.0 should update to at least Drupal 11.1.9.
• Sites on Drupal 10.4, 10.3, 10.2, 10.1, or 10.0 should update to at least Drupal 10.4.9.

These sites should apply the security update as soon as it is released on May 20, then plan to update to Drupal 11.3 or 10.6 in the near future. (Two other recent security advisories, SA-CORE-2026-001 and SA-CORE-2026-002, will not be addressed for 11.1 or 10.4.)

End-of-life major core versions (Drupal 8 and 9)

These major versions are fully end-of-life, so no releases will be created for these branches. However, given the potential severity of this issue, we will provide patch files for Drupal 8.9 and 9.5.

These patches must be applied manually. They are not guaranteed to work correctly, and might introduce other bugs or regressions. However, they may help mitigate the vulnerability for sites still on these old major versions until they upgrade to a supported release.

For the best chance of the patches being applied successfully:

• Sites on any version of Drupal 9 should update to Drupal 9.5.11.
• Sites on any version of Drupal 8 should update to Drupal 8.9.20\.

We strongly recommend Drupal 8 or 9 sites update to at least Drupal 10.6 soon. Drupal 8 and 9 include numerous other, previously disclosed security vulnerabilities that will not be addressed by either Drupal Steward or the best-effort patch files.

Drupal 7 is not affected.

Disclosure policy

Neither the Security Team nor any other party is able to release any more information about this vulnerability until the announcement is made. The announcement will be made public at https://www.drupal.org/security, on Bluesky, Mastodon, X (formerly Twitter), and LinkedIn, and in email for those who have subscribed to our email list. To subscribe to the email list: log in on Drupal.org, go to your user profile page and subscribe to the security newsletter on the Edit » My newsletters tab.

Security release announcements will appear on the Drupal.org security advisory page which also has RSS feeds.

• Benji Fisher (benjifisher) of the Drupal Security Team
• catch (catch) of the Drupal Security Team
• cilefen (cilefen) of the Drupal Security Team
• Damien McKenna (damienmckenna) of the Drupal Security Team
• Neil Drumm (drumm) of the Drupal Security Team
• Greg Knaddison (greggles) of the Drupal Security Team
• Tim Hestenes Lehnen (hestenet)
• Lee Rowlands (larowlan) of the Drupal Security Team
• Dave Long (longwave) of the Drupal Security Team
• Drew Webber (mcdruid) of the Drupal Security Team
• Juraj Nemec (poker10) of the Drupal Security Team
• Jess (xjm) of the Drupal Security Team

The Enterprise Drupal Summit Europe 2026 will take place on 28 September 2026 in the SS Rotterdam.

We are now accepting session proposals.

Focus of the summit

The program focuses on Drupal in enterprise contexts, with emphasis on:

• Large-scale Drupal architectures
• Digital experience platforms built on Drupal
• AI use in enterprise content and delivery workflows
• Composable and API-driven architectures
• Governance, security, and compliance in regulated environments
• Operating Drupal at scale in complex organizations

The event is aimed at practitioners and decision-makers working on enterprise digital platforms.

What we are looking for

We are prioritizing submissions that are based on real implementations.

Relevant topics include:

• Case studies from enterprise or public sector deployments
• Architecture decisions in complex Drupal systems
• AI integration in content management or delivery
• Multi-site and multi-brand Drupal setups
• Sessions should be grounded in practical experience rather than product positioning.

Format

Accepted formats include:

• 20 minute talks (MAX)
• Case study presentations (focus on the business side)
• Architecture or strategy sessions

Selection criteria

Proposals will be evaluated on:

• Relevance to enterprise Drupal use cases
• Clarity of problem and solution
• Evidence of real-world implementation
• Transferable lessons for other enterprise organizations
• Technical or organizational depth

Submit a proposal

Submissions are open via Pretalx.

Looking forward to seeing you there!
 

Article by: Aidan Foster, Foster Interactive

The three human skills that turn AI into a multiplier.

Creativity, strategic thinking, and articulation are the three skills that decide whether AI makes you better or just faster. - Aidan Foster

• Strategic thinking comes from experience. There's no shortcut.
• Creativity can be learned, but it's more like going to the gym than reading a book. You build it through reps.
• Articulation lets you craft quality prompts and specs for AI, and it's the most trainable of the three. But it only matters when there's something worth articulating. The value lives in the other two.

What Everyone Is Getting Wrong

The AI discourse has one dominant message: automate faster, cut the grunt work, reduce headcount, ship more.

Most leaders are responding by getting better at execution. Better prompts. Faster workflows. More output per person.

Execution still matters. It's just not where the constraint is anymore. The leaders who pull ahead in the next three years won't be the ones who automated the most; they'll be the ones who understood where the real constraint moved.

The Bottleneck Moved

Think back to five years ago. A new landing page meant a brief, a copywriter, a designer, a developer, a round of revisions, and three weeks of calendar time. A campaign asset required coordinating four people across two time zones for something that might run for six days before you killed it.

That friction was real. Teams were sized around it. Agencies were built on it. Budgets accounted for it. That friction is gone.

A capable team can now produce a landing page in hours. Drafts, variants, and structured content at a pace that would have required six people two years ago. The execution ceiling collapsed.

The bottleneck didn't disappear. It moved upstream, to the quality of thinking that goes in before AI touches anything.

Strategic clarity. Creative direction. Precise articulation of what you actually want.

That's where the value lives now. That's where most teams are dangerously underprepared.

Strategic Thinking

A CMO walks into a strategy review and knows something is wrong. They've seen this pattern fail before, in a different market with a different product. They remember exactly how it ended.

That's not intuition in the mystical sense. It's pattern recognition built through immersion. You watch your confident calls go wrong, you figure out why, you adjust.

Strategic thinking requires experiencing consequences. You have to have been wrong, and had something depend on you being right.

Researchers studying scientists at the frontier of human knowledge found the same principle. The best of them use cultivated judgment to ask better questions, to know where to go next. AI needs to be pointed. It executes brilliantly within a defined frame. The frame has to come from somewhere.

Our sense for aesthetics, meaning and embodiment give us a vital advantage over our technological creations.

Why Human Intuition Is Still Science's Greatest Tool In The Age Of AI - Noema Magazine, 2026

Creativity

Most people believe creativity is an innate trait. Either you have it or you don't. That's wrong.

86% more ideas after 3 months of training. The untrained control group barely changed.

Creativity is a muscle. It responds to reps, to practice, to deliberate exposure to new inputs. A controlled study at Radboud University found that students who went through structured creativity training nearly doubled their ideation output in under a year. The untrained group stayed completely flat. (PLOS ONE, 2020)

You cannot read your way to it. You have to do the reps.

Research across Nobel laureates and major creative contributors identified two distinct types of creativity with two distinct peak ages. Conceptual innovators - the ones who execute one brilliant overarching idea - tend to peak young. Experimental innovators - the ones who synthesize across years of accumulated experience and observation - peak in their 50s. (Galenson and Weinberg, via Big Think)

The kind of creativity that matters most in marketing is the experimental kind. The kind that gets better the more you've seen.

The senior strategist who's been in the game 15 years isn't past their creative peak. The research says they may not have hit it yet.

Articulation

Articulation gets your thinking and creativity out of your head and into a form AI can use.

A VP with sharp strategic instincts and genuine creative range can still get generic output from AI if they can't extract what's in their head and structure it precisely.

Imprecise input produces generic output. Always.

The model doesn't know what your brand sounds like. It doesn't know who your buyers are, what language they use, or what keeps them up at night. It doesn't know what you've learned over three years about what actually converts.

All of that has to come from you, structured in a way AI can use. Articulation responds to deliberate practice faster than the other two. Most people never treat it as something worth developing. (Canadian Marketing Association AI Playbook, 2025)

Experience Is the Advantage If You Use It Correctly

The skills AI cannot replicate are the ones that take years to build. But knowing that doesn't help unless you act on it. Three things worth doing now:

Audit your process assumptions, not your expertise. The judgment you've built is the asset. The habits formed around the old production bottleneck are what need to change.

Treat articulation as a skill to develop deliberately. Document what you know about your buyers, your brand, your market. Structure it. That structured knowledge is what separates useful AI output from generic noise.

Do the creative reps. Consistent exposure to new inputs and new problems. New disciplines.

Give yourself and your team time to be creative. Whiteboard ideas as a group. Collect interesting work and express what specifically about it grabbed your attention.

Skip the reps and your creative edge fades.

Leaders who invest in all three first will pull ahead. The advantage compounds.

Where does your team sit?

Most teams I talk to are strong on execution. The upstream work - the strategic clarity, the creative direction, the structured articulation of what makes them different - is where the gap is.

That gap is also where the opportunity is.

Drop a comment. I'd like to hear how others are thinking through this.

Sources: Noema Magazine (2026), Radboud University / PLOS ONE (2020), Galenson and Weinberg / De Economist (via Big Think), Canadian Marketing Association AI Playbook (2025)
 

At DrupalCon Chicago, the Driesnote included a visualization with “community” as one of the three pillars of Drupal, along with “platform” and “agencies.” That framing felt memorable, and worth exploring further.

If you attended DrupalCon Chicago, you might have experienced a slightly differently shaped triangle. I don’t know the attendance numbers, but I saw technical sessions with packed rooms, while community-focused sessions had plenty of empty seats. That’s not new. It’s been true for years. People care about community, but when the schedule forces a choice between a session on AI integration and one on community health, most folks choose the technical session. I understand why. Technical work feels concrete. Community work is generally not why employers send folks to a DrupalCon.

This raises a question: how can all of us work together to close that gap without having to attend community sessions at DrupalCon?

Consulting our Code of Conduct

I serve on the Community Working Group (CWG), specifically on the Community Health Team. A lot of people don’t know there are two teams inside the CWG, so here’s the short version:

• The Conflict Resolution Team handles incidents after they happen. If you file an incident report, they’re the ones who review it.
• The Community Health Team works on everything that happens before an incident report, such as workshops, resources, and other preventive work. Our goal is to help the community build the kind of culture where fewer situations reach the reporting stage in the first place.

Both teams matter. And beyond the CWG, the DrupalCon Code of Conduct offers advice for all of us. It includes a section titled “We are collaborative,” which says:

If and when misunderstandings occur, we encourage people to work things out between themselves where this is practical. Where support is beneficial to achieve this, participants agree to ask for help. People are encouraged to take responsibility for their words and actions and listen to constructively-presented criticism with an open mind, courtesy, and respect.

I suspect that many people read the harassment list and the reporting email and stop there. That’s understandable. Those parts exist for a reason. But the passage above describes the wide middle ground where most friction in our community occurs.

The middle ground of community health

If the only two options we envision are “this is fine” and “file a report,” we end up with a lot of buried resentment, a few dramatic blowups, and not much in between. Most day-to-day friction doesn’t rise to the level of a Code of Conduct violation. It’s tone. Assumption. Misread intent. A comment in an issue queue from someone who didn’t scroll up to read what had already been said. A joke that came off differently than it was intended.

The Community Health Team’s work is to strengthen the middle. That means helping people develop the habits and skills to address friction directly, kindly, and early, so it doesn’t compound into something that needs the Conflict Resolution Team. The Code of Conduct invites everyone to do this work. Not just CWG members. Everyone.

Some ways we work things out

Here are four situations I’ve seen in the community, and in some cases been part of. None of these are scripts. They’re illustrations. The point is that the Code of Conduct invites you to try, and that you’re allowed to. You don’t need permission.

• Late at night at a DrupalCon, after hours of sprinting and drinks in the hotel lobby, someone says something about another contributor that turns a few heads. That person might realize it the next day. The generous move, the one the Code asks for, is to find that person and say “I said something last night I want to walk back.” Not a grand apology. Just a small, honest correction. Most of the time, that’s the whole fix.
• Someone drops a comment in an issue queue without reading the full thread above. Their comment reads as dismissive of work that’s already been done, or repeats a point that was already addressed, and it comes off as rude. They might not know that’s how it came across. A direct message from someone in the thread (“hey, I think you may have missed a few comments, here’s where we landed”) can turn that into nothing. A pile-on in the issue turns it into something else.
• You witness an exchange between two people at DrupalCon that makes you wince. Maybe it’s cultural. The Drupal community spans continents, and directness that comes across as rude in one country seems normal in another. Maybe it’s a power dynamic, or a bad day, or both. Checking in with the person on the receiving end, just between the two of you (“I could not help but notice your conversation and I wanted to ask, are you doing okay?”), doesn’t escalate anything. It lets them know they weren’t invisible.
• Someone keeps doing something that just doesn’t feel right. Not harmful, but grating. You can do your best to describe how it made you feel before it becomes a grudge you carry into every future interaction. “Hey, can I mention something? The way we’re doing X did not sit well with me, and I want to figure out how to talk about it.”

If you need help figuring out the best way to handle a situation like this, the Community Health Team is available. We can help you talk through a situation, decide whether a direct conversation is possible, or offer a second perspective. You can reach out at any time. We don’t investigate, and we don’t take sides. We think with you.

When it isn’t practical

The Code says “where this is practical.” Sometimes it isn’t.

We live in a world with power differences. If the person on the other side holds significant authority over your ability to contribute, a direct conversation may not be safe for you. Ongoing patterns of behavior are different from single incidents. Safety concerns are different from style concerns. And if the other person has shown they aren’t willing to engage in good faith, you are not obligated to keep trying.

Those are incidents for the Conflict Resolution Team. Those are the situations the people on that team signed up for, and you can reach them through the incident report form. Filing a report is not escalation for its own sake. It’s using the right tool for the situation.

The three-pillar framing

Returning to the Driesnote, if community is one of three pillars holding up Drupal, then the pillar can’t only be carried by the folks who show up to CWG sessions. The math doesn’t work. Community health has to happen in the rooms with the technical sessions, on the Slack channels where the code review happens, or at the dinner table where someone just got interrupted for the third time.

Most of the work the Community Health Team cares about isn’t work you need a whole session to learn. It’s work you’re already in a position to do. The next time something said in an issue queue doesn’t feel right, you catch yourself venting about someone, or you see a newcomer get talked over, you have a chance to support Drupal’s community.

Community is a pillar, which means it doesn't get held up by a small group of people with CWG in their session title. It gets held up, or it doesn't, by how we talk to each other on a Tuesday afternoon when no one's watching.

Drupal’s Code of Conduct doesn’t just give you a way to report harm. It also asks you to do the smaller, harder thing first. That’s where most community health happens.

Article by: María Fernanda Silva

If you’ve spent any time around Drupal lately, you’ve probably noticed that AI is everywhere — in the keynotes, in the hallway conversations, in the issue queues. You may also have noticed that everyone else seems to know what they're doing, while you're still trying to figure out where to start.

You are not. Not even close.

Those questions — what is actually going on, and where do I even start? — are exactly what the Drupal AI Learners Club was built for.

Where it started

Angie Byron (webchick) has been part of the Drupal community since 2005: core committer, one of the driving forces behind Drupal 8, and one of those people everyone seems to know. She did not come to DrupalCon Chicago 2026 planning to start anything. She came to celebrate Drupal's 25th anniversary and catch up with old friends.

But somewhere between the hallway conversations and the late-night tables, she started picking up on something: a lot of people were anxious about AI, unsure what it meant for their work, their identity as Drupal developers, their community — and quietly terrified to admit they did not have it figured out.

"I don't know what is going on, and neither do you," she would later describe as the feeling she wanted to create space for. "It's fine. Nobody knows. It's changing too fast." 

That feeling stuck with her. And the Drupal AI Learners Club was born. Not as a space to hype AI, and not as a space to condemn it, but as a place to cut through the noise and talk honestly about what these tools actually do, how people are using them, and where they fall short.

Just show up

The club runs on a simple premise: come as you are. Sessions are low-pressure, informal, and require no prepared presentation. Participants share their setups, their workflows, what is working, and what is not.

The first session launched on April 8, 2026, with the topic "Share Your Setup!" and brought together community members to walk through the models, modules, agents, IDEs, and tools they were actually using day-to-day.

Sessions happen whenever someone steps up to talk about something (currently, ~weekly) and are recorded, so anyone who cannot attend live can catch up afterward. And as Angie puts it, there are no stupid questions. Everyone is here to learn, including the people who have been doing this the longest.

Join the conversation

The Drupal AI Learners Club is not here to tell you AI is the future. It’s here to make sure that wherever this is going, the Drupal community goes together — developers, site builders, contributors, and everyone in between.

There are many ways to join the club: attend a session, suggest a topic, volunteer to present, or join the organizing team. Sessions are published to a playlist on the Drupal Association YouTube channel so you can catch up anytime, and the conversation keeps going in the #ai-learners channel on Drupal Slack.

And remember, as the Spanish proverb says: there is no silly question — only silly people who do not ask.
 

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. 

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 →
 

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.

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 Work items in the left sidebar, then New item. 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.