One website, three completely different visitors. The hardest part of a multi-audience site is not building it - it is making sure each group finds its path without tripping over everyone else's.
Part 1 of this Drupal guide covers audience research, hybrid navigation strategy, and how to structure content with taxonomy, menus, and Views.
Today we are talking about Content, syndication, and Synchronization between Drupal Sites with guest Thiemo Müller. We'll also cover Drupal core 11.4 as our module of the week.
For show notes visit: https://www.talkingDrupal.com/560
TopicsThiemo Müller - content-sync.io thiemo
HostsNic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Ashraf Abed - drupito.com ashrafabed
MOTW CorrespondentMartin Anderson-Clutz - mandclu.com mandclu
This is the second and final part of a two-part guide to building a component-based corporate website with Drupal Paragraphs. Turn the bare components from part 1 into a flexible, production-grade library with color variants, responsive layouts, spacing controls, conditional fields, and admin UX.
Add style variants with CSS custom properties and Paragraphs behavior plugins, build mobile-first responsive layouts, give editors margin and padding controls, and polish the admin experience with Gin, conditional fields, and smart defaults.
Recent Drupal news fits inside a wider question Dries Buytaert raised in his blog post, License-only versus Stewarded Open Source: what turns code that is merely available into infrastructure people can depend on? The distinction is useful because this week’s updates are not only about individual announcements. They show the work that sits behind dependable open source: governance, maintenance, security response, shared knowledge, and long-term care.
The 2026 Drupal Association at-large board election brings that work into the governance layer. One community-elected seat on the association’s board is now moving through its election cycle, giving individual members a direct role in how Drupal’s institutional support is represented. In a project where technical decisions and community structures constantly shape each other, governance is not a background process. It is part of how shared infrastructure is kept accountable.
The same distinction between availability and dependability appears in the ten contributed-project security advisories published on 8 July 2026. Four were rated Critical. Three direct site owners to uninstall unsupported projects, while the fourth addresses SQL injection in Location Selector. Unsupported projects may still exist in repositories and production sites, but that does not make them safe to keep using.
For site teams, the response is practical rather than abstract. Affected modules need to be identified, fixed releases need to be applied where available, and unsupported projects without advisory-listed fixes need to be removed. This is the maintenance layer of open source that rarely attracts attention until something breaks.
ECA crossing 20,000 reported Drupal site installations shows the same issue from the maintainer side. The Event-Condition-Action module allows site builders to model workflows through events, conditions, and actions instead of relying on custom glue code. Adoption at that scale is not just a usage milestone; it changes the weight of future commits, API decisions, and compatibility promises.
In a written response to The DropTimes, project co-founder Jürgen Haas said the milestone changes how he thinks about maintenance responsibility. That is the cost of relevance in practical form. Once a module becomes part of thousands of working sites, its maintainers are no longer only improving a tool. They are helping support a piece of shared infrastructure.
The week’s event deadlines extend the same theme into community programming. Pacific Northwest Drupal Summit 2026 is accepting proposals ahead of its October event in Vancouver, British Columbia, while DrupalCamp Italy 2026 has extended its Call for Papers to 31 July 2026 for its one-day camp in Bologna. Event programmes are another support structure for the ecosystem because they turn project work, lessons, failures, and experiments into knowledge others can use.
Taken together, these updates make a selected but coherent brief. They are not the whole week in Drupal, and they are not a ranking of every important story. They are a thread through the work that keeps open source dependable after the code is released: electing representatives, closing security gaps, maintaining widely used modules, and making room for contributors to share what they are learning.
Readers can follow The DropTimes on LinkedIn, Twitter, Bluesky, and Facebook, or join the publication’s Drupal Slack channel at #thedroptimes.
(Allen Jason, junior sub-editor at The DropTimes, writes and curates this week’s Editor’s Pick.)
This is part 1 of a two-part guide to building a component-based corporate website with Drupal Paragraphs. By the end of the series you'll have a library of 10-12 universal paragraph types with style variants, responsive layouts, and editor-friendly spacing controls.
Plan a reusable component library, set up the Paragraphs module, and build Hero, Text + Image, and Feature Grid paragraph types with Twig templates and CSS.
Step debugging is one of the first things every developer should master in any language or environment, and it's my opinion that it's just as fundamental as version control. With DDEV, getting Xdebug working with PhpStorm takes less than five minutes and no php.ini fiddling. This screencast shows the whole thing on a TYPO3 project, start to finish.
Watch the Video What You'll SeeThat's it. No manual php.ini changes, no fussing with host.docker.internal, no separate Xdebug install.
Works the Same EverywhereThis screencast uses PhpStorm, but the same setup works identically with VS Code, on Linux, and on Windows with WSL2. If you're setting up a new machine, see:
Xdebug is created and maintained by Derick Rethans. He's been maintaining it for 20+ years. Send money to the Xdebug project!. The DDEV Foundation supports it as an upstream project, you can too.
Learn MoreIf you have questions, reach out in any of the support channels.
Follow our blog, Bluesky, LinkedIn, Mastodon, and join us on Discord. Sign up for the monthly newsletter.
This article was edited and refined with assistance from Claude Code.
Hi friends! It's been a while since our last article, and you might have been wondering when we'd be back with something new. Thanks for your patience—we're excited to return with a fresh topic that many Drupal site owners, marketers, and developers deal with on a regular basis: spam. Drupal websites can be secure, flexible, and high-performing. But there is one issue that keeps bothering site owners, marketers, and developers again and again. It is spam.
Spam is no longer only about strange messages in a contact form. Today, it can mean fake registrations, low-quality leads, disposable emails, bot-driven submissions, and AI-generated junk content. All of this creates extra moderation work, pollutes your CRM, and wastes your team’s time.
That is exactly why Drupal anti-spam protection matters much more now than it did a few years ago.
Near the end of most Open Source licenses, usually in capital letters, sits a clause that disclaims almost everything: no warranty, no liability, use at your own risk.
For an organization that depends on that code, the clause is harsh. If the code fails and takes your data or revenue with it, the license owes you nothing. No fix, no refund, and no one to explain what went wrong.
That is the license doing its job. It makes the code available and protects the people who share it. Without that protection, sharing code could become a gift that backfires: a generous act turned into unlimited legal risk.
But the license can only answer the legal questions: who may use the code, on what terms, and what risk the authors are willing to accept. It cannot tell you what kind of Open Source project you are working with.
Some Open Source is "License-only Open Source": code released under an Open Source license, without active stewardship or any promise of ongoing care. There is no guarantee of updates, fixes, security response, or long-term support.
Other Open Source is "Stewarded Open Source": code cared for as shared infrastructure. Maintainers review contributions, fix bugs, respond to security issues, manage releases, provide long-term support, and much more. Organizations fund maintainers, support core development, donate infrastructure, and absorb costs end users never see.
Both types of projects are Open Source, but they are not the same. A weekend hobby project and business-critical software can ship under the exact same license. Legally, they look identical. Practically, they are worlds apart.
The difference is stewardship. The license makes code available; stewardship makes it dependable. And the more people or organizations depend on a project, the more stewardship it often requires.
Responsibility is the tax on relevance.
Distinguishing license-only from stewarded Open Source gives us the vocabulary to describe two very different realities that the words "Open Source" alone do not capture.
For example, the distinction becomes useful when we talk about contribution. If a company depends on Open Source, should it give back?
For license-only Open Source, the answer can be simple: no one is required to contribute, and that is the point. The code was shared freely, without a promise of care or an expectation of return.
Stewarded Open Source is different. The license may still require nothing, but the work does not happen for free. Someone is paying to keep your code usable, secure, and available. When you depend on that work, the question is not only what the license allows, but who helps carry the responsibilities beyond what the license requires.
The license says use at your own risk. Stewardship is what happens when people decide you should not have to.
This is the fifth post in our GitLab issue migration series. So far we’ve covered the immediate changes, the new workflow for migrated projects, how to use it, and what the migration looks like from a contributor’s perspective. This post is about which projects we’re migrating next, and why.
We are now migrating projects maintained by Ripple Makers, the individual members of the Drupal Association. If you’re a Ripple Maker who maintains one or more contrib projects, this is our thank you for your membership.
Why members first?Migrating issues to GitLab, and running GitLab itself, has a real cost. There is engineering time for the migration tooling, upgrades for git.drupalcode.org, and ongoing work on the integrations that keep contribution credit, issue forks, and the rest of the Drupal.org glue working smoothly.
That cost is covered by the people and organizations who fund the Drupal Association: Ripple Makers and Drupal Certified Partners. As we schedule migration batches, we are prioritizing projects maintained by members and projects supported by Drupal Certified Partners.
To be clear: every project will eventually be migrated. Membership doesn’t change whether your project moves; it changes when. Prioritizing members is a small way to say thank you to the people whose contributions make the infrastructure itself possible.
Not a member yet?If you’d like your projects prioritized, and, more importantly, if you’d like to support the infrastructure that the whole Drupal ecosystem runs on, this is a good moment:
Membership funds don’t just pay for GitLab. They keep Drupal.org, project packaging, GitLab CI, automatic updates infrastructure, and more running for everyone, members and non-members alike.
Reporting bugs and getting helpFound 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 continuing to iterate on this transition based on what we hear from maintainers and contributors in migrated projects. Your feedback now shapes the experience for the rest of contrib later.
Related blog posts in this series:
Related issues
By the Drupal AI Initiative
Following our announcement last week introducing Inside AI and Outside AI, we are excited to share how we are scaling our leadership and organizational structure to support these two parallel workstreams.
What started as an ambitious vision originally founded by Jamie Abrahams from FreelyGive quickly gained community-wide momentum. In June 2025, our founding partners – 1xINTERNET, Acquia, Dropsolid, FreelyGive, and Salsa Digital – came together to establish the official Drupal AI Initiative, providing a cohesive strategy, baseline funding, and dedicated staff. Since then, the initiative has grown rapidly to encompass over 30 partner organizations, with many of their team members stepping directly into key leadership and execution roles.
To support our rapid growth and ensure effective daily coordination, we are evolving our structure into a more robust, three-tier governance model comprising a Drupal AI Board, a Drupal AI Leadership Team, and our existing community of AI Partners.
The Drupal AI Leadership TeamThe purpose of the Drupal AI Leadership Team is to coordinate day-to-day project execution, align technical and cross-functional work streams, and ensure all initiative activities successfully deliver on our strategic goals.
At the center of this governance evolution, this team formalizes leadership roles that have organically emerged and evolved over the past year. Rather than introducing a brand-new operational layer, this structure officially empowers the individual contributors who have already been actively driving the initiative's day-to-day work.
By having dedicated, individual leads taking ownership of specific subject-matter areas, we ensure that every key aspect of the initiative has focused guidance. This structure also provides a natural avenue for our partner organizations to showcase their technical talent and gain visibility within the ecosystem, while placing experienced contributors in charge of critical technical and horizontal areas.
The Leadership Team's execution is divided into two distinct, cooperative disciplines:
This division ensures that technical teams can focus on delivering robust functionality, while cross-functional leads act as an internal agency to validate, test, document, and promote those features before they reach users.
In an upcoming post, we will share more details about the leadership team structure, introduce our current domain leads, and outline vacant positions.
The Drupal AI BoardOur founding partners, who previously made up the initiative's core steering group, are transitioning to become the members of the Drupal AI Board.
The Board serves as the strategic and supporting foundation for the Leadership Team, establishing a strong, predictable operational environment. Rather than individual developers having to balance ecosystem coordination, funding allocations, and administrative hurdles alongside daily coding, the Board takes on these responsibilities.
Composed of our founding partner companies, the Board is responsible for setting the high-level strategy, defining the general initiative direction, and prioritizing our long-term roadmap. In addition to guiding this overarching strategy, the Board provides baseline initiative funding and staff, manages overall ecosystem alignment, and secures ongoing partner resource commitments. This structural backing ensures a stable operational runway, allowing the Board to focus on defining leadership functions, appointing execution leads, and securing the necessary resource allocations so developers can focus strictly on build and delivery.
What Changes? (And What Stays the Same)For the developers, builders, and content creators actively contributing to the initiative, the day-to-day experience will feel familiar, but with clearer support structures.
Our established sprinting procedures remain completely unchanged. The community and partner teams will continue to collaborate on their scheduled sprints.
However, we are introducing two key improvements:
This structural evolution ensures that everything built by both Inside AI and Outside AI integrates seamlessly with the broader Drupal AI roadmap and aligns directly with our collective short term and long-term goals.
How to Get InvolvedAs we step into this new phase of growth, we are looking for dedicated partners and brilliant minds to help execute our goals.
The Drupal AI Initiative is made possible by the generous funding, resources, and technical contributions of our partner network. We are incredibly grateful to these companies for driving the future of open-source AI:
Founding Partners Gold PartnersYou can view the full list and status of our contributing sponsors on the official Drupal AI Partners directory.
Join Martin, Andy and Mike as they discuss what Drupal site templates are and how they differ from Drupal's traditionally bare-bones starting point, aiming to reduce setup effort and total cost of ownership while making Drupal competitive again for small nonprofits and smaller sites. They compare building templates versus client sites, covering the evolution from early Layout Builder/Recipes work to today's simpler packaging via a Drush site:export workflow, plus tooling like DripYard Recipe Builder for extracting reusable "recipe" parts.
For show notes visit: https://www.talkingDrupal.com/cafe018
Topics Martin Anderson-ClutzBased in London, Ontario, Martin transitioned from graphic design to web development, ultimately specializing in Drupal in 2005. Currently working as a Product Marketing Manager at Acquia, he is Triple Certified in Drupal and UX-certified by the world-renowned Nielsen Norman Group. His key contributions include: As a speaker & writer, presenting at Drupalcamps and Drupalcons, and a published blogger across multiple platforms, including the Acquia Dev Portal and opensource.com; as a podcast host, participating in the Talking Drupal podcast, including as the "Module of the Week" correspondent; and as an open source maintainer, developing and maintaining popular Drupal contrib modules and recipes, including Smart Date and Fullcalendar.
Andy GilesAndy is a Drupal back-end developer. In 2012, he founded Blue Oak Interactive, a development and consulting agency focused on complex Drupal site builds, particularly in e-commerce. In 2025, he partnered with Mike Herchel to launch Dripyard, a premium Drupal theme designed to reduce the cost of ownership and enhance the developer experience for modern Drupal projects.
Mike HerchelMike is a founder & developer at Dripyard, and is a longtime contributor to Drupal. He has played a key role in modernizing Drupal's frontend architecture, performance, and accessibility, and is known for helping bring Drupal's component-driven development into mainstream use. Mike has delivered projects for organizations including IBM, the U.S. Small Business Administration, and the U.S. court system. He is a frequent speaker on performance, accessibility, and modern frontend practices.
Martin Anderson-Clutz - mandclu.com mandclu
Content moderation is a data processing problem. For large sites with many content contributors, moderators can get bogged down catching obvious content policy violations without having time to do real editorial work.
Meanwhile, AI is great at fast, consistent classification of text, which is exactly the kind of work that can clog an editorial queue. It’s not a replacement for human judgment: it makes mistakes, it can be gamed, and it lacks context. But as a first-pass filter, AI can meaningfully shrink the noise that reaches a human reviewer.
This post walks through adding that type of AI content filter to an existing Drupal workflow using contrib modules and no custom code.
Implementing the SolutionModulesThe full solution uses zero custom code. Here are the key contrib modules:
The assumption is that a site already has a working Content Moderation workflow. The AI gate slots in between author submission and the editor queue:
[Before] Draft → Needs Review → Published [After] Draft → Needs Review → [AI gate] → AI Review Passed → Published ↘ RejectedTo support this, the workflow needs two new states (AI Review Passed, Rejected) and two new transitions (AI Approve, AI Reject). Those transitions should not be granted to any UI role as they’re triggered only by ECA.
The five modules listed above need to be installed, an AI provider configured with a securely stored API key, and the updated workflow applied to the relevant content type.
Workflow state diagram The ECA ModelThis is the core of the implementation.
Create a new ECA model at Admin → Configuration → ECA. The model has five nodes:
1. Event — Workflow: state transition Fires when an article transitions to needs_review.
2. Action — Token: set value Stores [entity:body:value] into a token named moderation_input. This uses ECA’s token replacement, which resolves field values correctly at runtime. (A note on this: the more obvious Get field value action returns null for body fields in practice — token replacement is the right approach here.)
3. Action — Moderation (from AI Integration for ECA) Calls the AI provider’s moderation operation. Set model to openai / omni-moderation-latest, token input to moderation_input, and token result to ai_result. The result token exposes [ai_result:flagged] (1 or 0) and [ai_result:information] (per-category scores).
4. Action — Workflow: transition (condition: [ai_result:flagged] = 1) Transitions to rejected. Revision log: AI moderation: content flagged.
5. Action — Workflow: transition (condition: [ai_result:flagged] = 1, negated) Transitions to ai_review_passed. Revision log: AI moderation: content passed initial screening.
The conditions use ECA’s built-in Compare two scalar values plugin. Steps 4 and 5 share the same condition — one negated, one not.
ECA model visual Moderation action configuration panel TestingSubmitting a benign article routes it to ai_review_passed with the pass log entry. Submitting content that violates the violence policy routes it to rejected with the flagged log entry. Both transitions appear in the node’s revision history with the AI-stamped message.
Node revision history on a rejected article Going FurtherCustom Moderation PromptsThe OpenAI Moderation API uses fixed categories. If your policy doesn’t map to them cleanly — community guidelines, brand safety rules, domain-specific restrictions — you can replace the Moderation action with a Chat action and a configurable system prompt. The rest of the ECA model stays the same.
With a Chat action returning structured JSON (response_format: json_object), you define exactly what the AI evaluates and how it reports back. The downstream ECA conditions check the response token the same way. This makes the screening logic editable in the UI without a code change or redeploy.
Giving Authors a Path ForwardA bare rejection with no context isn’t great author experience. ECA can handle the follow-on steps too. On the rejection branch, you can chain additional actions before or after the transition: send the author an email using [ai_result:information] to surface which categories were flagged, set a message on the form, or move the node to a Needs Revision state rather than a hard Rejected — giving authors the ability to edit and resubmit rather than starting over.
You could also model a full revision loop: Rejected → Needs Revision → Needs Review (with the AI check firing again on resubmit). Whether that’s appropriate depends on your content volume and how much trust you extend to repeat offenders, but the workflow and ECA config support it without any custom code.
Closing NotesThe drupal/ai_integration_eca module is what makes this approach work cleanly. Without it, inserting AI into an ECA model would require a custom action plugin. With it, the entire integration is UI-configurable and exportable as config.
A few things worth knowing before you build on this:
coder.ddev.com gives you a full DDEV environment in the cloud, no local Docker required. This is a quick look at using it for a TYPO3 project with the freeform template.
For general background on coder.ddev.com, including access requirements and the other available templates, see the announcement post.
Watch the Video What You'll SeeThe workspace can be shared with other coder.ddev.com users directly, without any extra setup.
It can also be shared with ddev share, since rfay/typo3demo uses a relative base (/camino) instead of a hardcoded URL. Projects that do hardcode a full URL in base need the pre-share/post-share hook fix described in Sharing Your TYPO3 Project with ddev share.
Learn MoreIf you have questions, reach out in any of the support channels.
Follow our blog, Bluesky, LinkedIn, Mastodon, and join us on Discord. Sign up for the monthly newsletter.
This article was edited and refined with assistance from Claude Code.
In the enterprise world, Drupal is often chosen for its unparalleled flexibility and power. Organizations, including large-scale research institutions like CERN, have historically relied on Drupal to manage thousands of complex, interconnected websites. Yet, we are witnessing a trend where massive Drupal ecosystems are migrated to alternative platforms.
This migration is rarely about the CMS engine itself. It is a symptom of The Drupal Paradox: the same flexibility that makes Drupal the ideal choice for an enterprise also creates the conditions for its eventual mismanagement.
The Anatomy of MismanagementWhen an organization manages hundreds of websites, Drupal’s modular nature can become a double-edged sword. Mismanagement typically creeps in through three specific avenues:
Many organizations view migration as a clean slate. They assume that moving to a new platform will solve the underlying technical and process issues. This is a mistake.
If an organization lacks the governance to manage a Drupal ecosystem, they will inevitably reproduce the same technical debt on any other platform they choose. Migration is not a cure for poor architectural discipline, it is simply a very expensive way to reset the clock on systemic failure.
Preventing the Paradox: A New Governance StandardTo ensure the longevity of an enterprise CMS, organizations must shift from a "content-editing" mindset to an "engineering-discipline" mindset:
Drupal is not failing, enterprise governance is. If you find your organization trapped in a "paradox" where your CMS feels like a burden, stop looking at migration as your only option. Start looking at the structural integrity of your team’s processes.
We don't believe in "quick fixes." We believe in building systems that respect your investment. If you are struggling with a paradox of your own, we approach enterprise architecture differently.
Drupal migration Drupal Planet Drupal WordPress Share this Copied to clipboard Add new comment