Drupal Metatag Module Basics for Content Editors Joel Steidl Tue, 06/23/2026 - 14:38 Drupal

Helping your website content be found, shared, and understood clearly and responsibly.

When you publish website content, the work does not stop at the page itself. Search engines, social platforms, and browsers all rely on behind-the-scenes information to understand what your content is about and how it should appear to people looking for it.

In Drupal, the Metatag module gives content editors a way to shape that understanding. You do not need to be a developer to use it effectively as part of your day-to-day content work. Editing and reviewing metatags is generally straightforward for content editors.

Installing the module and establishing site-wide defaults typically requires a developer or someone with Drupal experience. Tasks such as adding the module, enabling it, and defining default values are usually handled during site setup. Once that foundation is in place, content editors can focus on the quality and context of their content rather than technical implementation details.

This article explains the most common Metatag settings you will encounter, what they do, and when they matter.

What the Metatag Module Does

The Metatag module lets you manage information about your content that is not visible on the page itself, but is visible to:

• Search engines such as Google and Bing
• Social media platforms such as Facebook, LinkedIn, and X
• Web browsers and assistive technologies

You can think of metatags as context. They help external systems understand your content and present it accurately to people who depend on those systems to find trustworthy information.

Metatags on Content Edit Screens

As a Drupal content editor, the metatag fields you will work with most often appear directly on the content editing screen alongside the rest of the page fields.

You will typically see them:

• On content edit screens for pages, articles, events, and similar content types
• Grouped under a Metatag or SEO section

Many of these fields are pre-populated using defaults established during site configuration.

These fields control how a specific piece of content appears in search results and social shares. You will not need to adjust them for every page. Understanding what they do helps you make informed decisions for high-visibility content, time-sensitive information, or pages likely to be shared widely.

Metatag Configuration

You may also hear references to "Metatag settings" or "Metatag configuration." These live in the Metatag module's administrative settings rather than on individual content pages.

This configuration is used to:

• Define site-wide defaults for titles, descriptions, and social previews
• Control which metatag fields appear for different content types
• Set fallback values when editors leave fields blank

Because these settings affect the entire site, they are typically managed by developers or site administrators. Content editors generally do not need to interact with this area as part of their regular workflow.

Understanding this distinction helps establish clear ownership: developers maintain the framework, while editors focus on content quality and accuracy.

Core Metatags You'll Use Most OftenPage TitleWhat it is

The page title appears in browser tabs and is often used as the main headline in search results.

Why it matters

This is one of the clearest signals search engines use to understand what a page is about. It is also the first thing many people see when deciding whether to click.

Best practices

• Keep it clear and specific
• Put the most important words first
• Aim for roughly 50 to 60 characters

Example

Summer Programs for Kids | City of Example

Meta DescriptionWhat it is

A short summary that often appears below the page title in search results.

Why it matters

While it does not directly affect rankings, it helps people decide whether a page is relevant to them.

Best practices

• Write in plain language
• Be accurate and inviting
• Aim for roughly 150 to 160 characters

Example

Explore fun and educational summer programs for children ages 5–12. Registration now open.

Canonical URLWhat it is

The canonical URL tells search engines which version of a page should be treated as the primary one.

Why it matters

This helps search engines identify the authoritative version of content when similar or duplicate pages exist.

For editors

In most cases, this is handled automatically. You usually will not need to change it.

Robots (Index / Follow)What it is

Instructions that tell search engines whether they should:

• Include the page in search results (index)
• Follow links on the page (follow)

Common settings

• Index, Follow: Appropriate for most public-facing pages
• No Index: Used for pages that should not appear in search results

Why it matters

These settings help ensure that search engines surface the right content while excluding pages that may be temporary, incomplete, or intended for limited audiences. Used thoughtfully, they support clarity, trust, and consistency across the site.

When "No Index" is appropriate

• Temporary or time-limited pages
• Confirmation or thank-you pages
• Internal-only content

Social Sharing Metatags

These settings control how your content appears when it is shared on social media. Clear, accurate previews help people quickly understand what they are being asked to read or click.

Open Graph (Facebook, LinkedIn, and Others)Open Graph TitleWhat it is

The headline shown in social previews when the page is shared on social platforms.

Helpful tip

This does not have to match the page title exactly. You can use more conversational language if it helps provide useful context.

Open Graph DescriptionWhat it is

A short summary shown beneath the title in social previews.

Helpful tip

Focus on clarity and relevance. This text helps people decide whether the content is useful to them.

Open Graph ImageWhat it is

The image displayed alongside the title and description in social feeds.

Why it matters

A clear, relevant image helps your content stand out and be understood at a glance.

Best practices

• Choose an image that reflects the content honestly
• Use high-quality images without small or difficult-to-read text
• Avoid images that feel generic or misleading

Advanced Metatags

You may notice additional fields that are rarely needed on a page-by-page basis. These metatags are typically managed at the site level rather than by individual content editors.

In most Drupal sites, advanced metatags are:

• Configured centrally in the Metatag module settings
• Applied automatically using site-wide defaults
• Maintained by developers or site builders as part of the site's overall configuration

This approach promotes consistency across the site while reducing the risk of configuration drift and unintended changes.

As a content editor, you generally do not need to edit these fields. They are managed for you so you can focus on creating and maintaining clear, useful content.

Keywords

Modern search engines largely ignore this field. You can usually leave it empty unless your organization has a specific reason to use it.

Content Language

The Content Language metatag communicates the language of the page to search engines, browsers, and assistive technologies.

This is usually set automatically based on the site's configuration. During site setup, a developer or site builder defines the site's default language and any additional supported languages in Drupal's language settings.

Drupal applies the appropriate language metadata to each page based on:

• The site's primary language
• Whether the site supports multiple languages
• How a specific piece of content is configured or translated

You typically do not need to manage this field directly. It is handled automatically to help ensure content is interpreted and presented correctly across devices, platforms, and accessibility tools.

Site Verification, Geo Tags, and Custom Tags

These fields are often used for:

• Search engine verification
• Analytics and monitoring tools
• Organization-wide integrations

They are usually managed globally rather than by individual editors.

Want to Go Deeper?

For teams responsible for Drupal configuration, governance, or ongoing platform maintenance, the following resources provide additional detail:

Drupal Metatag module documentation (Drupal.org)

Official documentation covering available metatag types, defaults, and configuration options:

https://www.drupal.org/docs/contributed-modules/metatag

Working with images in metatag fields

A helpful explanation of how metatag image fields work with Drupal Media and tokens:

https://mark.ie/blog/adding-tokens-for-metatag-image-fields-when-using-drupal-media-entity

These resources are most useful for developers and site builders, but they can also provide helpful context for editors interested in understanding how content is presented across platforms.

Key Takeaways

Most Drupal sites provide sensible metatag defaults, which means editors rarely need to complete every field. Even so, it is worth reviewing metatags for key landing pages, high-traffic content, major announcements, and pages that are likely to be shared externally.

Before publishing, take a moment to confirm that:

• The page title clearly reflects the content.
• The meta description accurately summarizes the page.
• Social sharing previews make sense when viewed outside the context of the website.
• The page is intended to appear in search results.

Metatags are not a substitute for clear content, good information architecture, or strong governance. They are supporting metadata that helps search engines, social platforms, browsers, and assistive technologies interpret content consistently. When paired with well-structured content and thoughtful editorial practices, they help ensure information is represented accurately wherever people encounter it.

Jon Bowman

Freedom is Not Free: A Model for Open Source Sustainability demet Tue, 06/23/2026 - 11:49

How to align public policy and procurement to support the costs of our shared digital infrastructure

The modern world runs on open source software—trillions in economic value, and growing more essential to digital sovereignty by the day. Yet, beneath this foundation, the projects producing it are starved of capital. Open source simply does not have the structural resources it needs to be sustainable. The code is free, but the human and technical infrastructure required to maintain it is not.

A project like Drupal is no longer just a code repository; it is a full-scale utility provider. We deliver supply chain security, product management, and continuous integration pipelines. Our licenses waive all warranties and responsibilities—and yet enterprise scale demands we provide these services anyway, because no one else will. The core failure of our current model is that open-source funding is completely disconnected from these operational cost centers.

Because we lack a built-in mechanism to capture the value open source creates, we have accidentally engineered an extractive system. The Takers who consume open source without paying their fair share of its operational footprint are not acting out of malice; they are simply doing exactly what the market currently incentivizes them to do.

It is not inevitable that open source must be extractive. That is an architectural choice. To change the outcome, we must change the incentives. Using regenerative system design, we must re-engineer open-source models to capture enough resources from our outputs to continuously sustain our inputs. We must ensure that supporting open source the right way becomes both the easy way and the expected way.

Right now, supporting open source the right way is almost impossible for our largest users. Public procurement systems are designed to buy structured services from single vendors. They cannot write open-ended checks to decentralized communities. To bypass this "charity trap," we must transition to an operational cost framework and move the operating costs of open source off the donation sheet and directly into core operating budgets as a predictable, line-item consumption expense.

To make the easy way possible, open source foundations must clearly quantify and communicate our true technical and human costs. In Drupal, we know part of it. We provide $10 per site per year in consumable technical infrastructure, but our revenues only fund $7.50. The remaining $2.50 is pushed off as technical debt to the future. That gap says nothing about the release managers and security teams whose essential work is still mostly donated—that burden sits entirely outside this number. We must turn these technical and human maintenance costs into a transparent, billable utility, giving institutions a clear, legally compliant way to pay for what they consume.

But once we make it easy to pay for this utility, how do we make it the expected way?

That requires establishing two clear standards.

For the vendor ecosystem, we need a sustainable participation standard. In Drupal, we have a contribution credit system to visibly recognize our Makers, those who invest real capital, code, and labor into the project. This system also helps us to identify the Fakers, organizations that use sponsorship and marketing to signal commitment while funding and doing little-to-none of the actual work.

For public institutions and enterprise users, we need a sustainable use standard defined by three practices:

• One, select vendors who sustainably participate in the projects they use.
• Two, include an explicit open source maintenance line item in every contract—a cost-recovery expense that shifts the burden off pro-bono maintainers.
• Three, require timely upstream release of all non-sensitive bug fixes and features.

With these standards in place, Open Source Program Offices can work with procurement officers to differentiate the true Makers from the Takers and Fakers at the point of purchase. And, the market-making power of public purchasing operationalizes "Public Money, Public Code" into the norm.

Open source cannot thrive on the margins of volunteerism, but it doesn’t have to. Once public policy acknowledges open source maintenance as an operational cost rather than a charitable act, everything else follows. That's regenerative system design in practice: change the incentives, and the system begins to fund itself.

Adapted from a June 23, 2026 presentation by Tiffany Farriss at the Sovereign Tech Agency's Breakfast Reception during United Nations Open Source Week.  Photo by Mike Gifford, licensed under CC BY-SA 4.0.
 

When we started working on the Drupal AI initiative in June 2025, I assumed most AI features would live inside Drupal.

By my DrupalCon Chicago keynote in March 2026, my thinking had changed. I framed the shift as "inside-out" versus "outside-in" and concluded that not every AI capability belongs inside Drupal. Some work is better done outside the CMS, where AI tools can move faster and connect back to Drupal when needed.

Last week, I explored these ideas in more detail in "AI and the great CMS unbundling". That post argued AI is making the CMS less central as a creation tool, but more important as a control layer: the place where content is structured, governed, reused, and published with trust.

This post picks up from there. If Drupal's role as the control layer is becoming more important, it needs to support AI-driven workflows that run inside Drupal, start outside Drupal, and move across both: external workflows that call into Drupal, and Drupal-native workflows that outside systems can safely rely on.

Drupal joins workflows beyond the CMS

First, Drupal needs to work well with tools outside the CMS: coding agents like Claude Code and Cursor, and orchestration platforms like Salesforce Agentforce, n8n, and Activepieces.

I actually showed what this could look like in my DrupalCon Vienna keynote in October 2025. Here is a short clip of that:

It was a proof of concept demo, and we had some fun with it. But the pattern behind the demo mattered more than the demo itself: an external tool drove the work and handed tasks to Drupal, while Drupal returned structured content and state.

Watch the demo, and it will be easy to imagine the same pattern in a real marketing use case. Campaigns usually begin with a marketing brief and span many tools and channels: email, website landing pages, social media, paid media, and more.

An external agentic platform could generate campaign copy and ask Drupal to build a landing page. Drupal could map the copy to the right structured content type, place it into approved components with Drupal Canvas, save a draft, and flag any fields, metadata, or translations still missing before it can publish.

If Drupal reports a missing hero image, the agentic platform could search the digital asset management system (DAM), find an approved campaign image, and hand it back. Drupal could then attach it through its media model, supply or verify the required alt-text, confirm the page meets its requirements, and advance the draft through the editorial workflow.

This is a pattern that Drupal will need to support well. External platforms can coordinate work across the broader digital stack, but Drupal should remain the system that assembles, validates, governs, and publishes the content.

External workflows call Drupal-native workflows

While the larger campaign workflow may live outside Drupal, there is an equally important case for Drupal-native workflows.

External agents are good at coordinating work across systems. But once a workflow needs to act on Drupal content or data, it should use Drupal's native content model, permissions, validation rules, moderation states, revisions, and publishing workflows rather than recreate them outside of Drupal.

That is where projects like ECA, FlowDrop, and Maestro become more important. They let Drupal turn site-specific processes into repeatable, multi-step workflows that outside systems can call.

For example, any of these three systems could power a single Drupal workflow that validates a draft, coordinates translations in five languages, assigns reviewers, and publishes the content only after all required approvals are complete.

Depending on the task, these internal Drupal workflows can be deterministic, AI-assisted, or fully agentic. Drupal can support that today.

An external agent should not have to manipulate Drupal from the outside, field by field or function by function. It should be able to ask Drupal to execute a Drupal-native workflow through a single external API call.

That is the other half of what I showed in the demo video above. Drupal was not just exposing content to an external agent. It was exposing custom Drupal-native ECA workflows that an external automation tool called.

That was powerful last fall at DrupalCon Vienna, but as agentic workflows become more common, this pattern will only grow in importance.

The best end-to-end experience will win

There is a natural tendency to debate what should live where. Should AI happen inside Drupal, or outside of it? Should workflows be Drupal-native, or managed by external platforms?

Those are useful questions, but the answer is not universal. AI and workflows should live where they create the best end-to-end experience. Sometimes that will be inside Drupal, sometimes outside Drupal, and often across both.

What "best" means depends on the use case, the user, and the requirements for speed, reliability, security, governance, cost, and human review. There will be best practices, but no single approach fits every case.

Who is doing the work shapes what "best" looks like:

• A developer may prefer an external coding agent like Claude Code.
• A marketer may prefer a Drupal-native experience that keeps them close to previews, translations, moderation, and publishing.
• A campaign manager may need an external workflow that coordinates email, social media, analytics, DAM, and CMS.

Work will move across systems and people. The best end-to-end experience will come from doing each step where it can be done best, while making the handoffs feel invisible.

A head start is not a plan to win

Understanding Drupal's role in these future workflows gives us clarity about where Drupal needs to go. Drupal needs to get better at supporting external orchestration, Drupal-native workflows, and the real-world hybrids that combine both.

What makes Drupal interesting is that it already has so much of the hard, unglamorous infrastructure these workflows need: structured content, granular permissions, revisions, rollback, JSON:API, and plenty more. These are exactly the capabilities agents need, and they're genuinely difficult to build well from scratch or retrofit.

Conceptual clarity and a strong foundation are wonderful things, but they are not enough to win.

When I asked whether AI coding agents would recommend Drupal, the issue was not Drupal's capability. It was whether agents could get from prompt to a working Drupal site quickly and easily enough. As I wrote in "Friction, abstraction and verification", agents tend to choose the path that gets them to a real, verified result with the least friction.

For experienced Drupal teams, the challenge is different. They have already chosen Drupal. They do not need an agent to recommend it. They need agents that help them build, validate, and ship quality work faster.

To turn Drupal's advantage into adoption, we need to improve both paths: helping agents choose Drupal for new builds, and helping existing Drupal teams ship better work faster. Both depend on making it easier for agents to work with Drupal from start to finish.

That means Drupal needs to expose the best practices, site context, tool definitions, constraints, and precise validation agents need to take the right actions and verify the result.

A lot of this is already underway across Recipes, Site Templates, Drupal AI, Drupal Canvas, ECA, FlowDrop, Maestro, MCP, and CLI improvements, to name a few.

But the goal is bigger than any one project. Drupal needs these efforts to add up to a clear, coordinated path for agents: from setup to connection, context, governed action, validation, recovery, and launch.

Special thanks to James Abrahams, Jürgen Haas, Randy Kolenko, Scott Falconer, and Shibin Das for their review and contributions to this blog post.

I Keep Evaluating Alternatives to Drupal. I Keep Choosing Drupal. Here Is the Actual Reasoning. Why I Bother Looking at All

There is a failure mode among experienced developers where they defend their stack because switching would invalidate years of accumulated expertise. The sunk cost is real and the bias is real. The antidote is to take the alternatives seriously when the opportunity comes, build something real with them, and see whether they have caught up.

So when a project's requirements actually push me toward another tool, or when I am curious enough about a new one to spend real time on it, I do exactly that. I read the docs properly. I build a non-trivial prototype. I model a real content structure, not a blog with three fields. I look at what production would actually require. Then I compare honestly.

This post is the result of those evaluations. It is not a Drupal sales pitch. It is the reasoning of someone who has genuinely used the alternatives and keeps finding that, for the work I do, the decision still holds.

Where the Alternatives Are Genuinely Better

Let me start here, because a post that only praises Drupal is not credible.

The modern headless stacks are genuinely better at greenfield speed. If I am starting a small-to-medium project with a clean content model and a React frontend, Sanity or Payload will get me to a working state faster than Drupal will. The developer experience is smoother. The frontend integration is more natural. The mental overhead is lower. For a certain class of project, they are simply the better choice, and I have recommended them when that was the case.

Custom Next.js builds give you total control. No framework opinions to fight. No contrib modules to maintain. For a team with strong frontend engineers and a genuinely unusual set of requirements, building from scratch can be the right call.

These are real advantages. I am not going to pretend otherwise. If your project is greenfield, your content model is simple, and your team is React-native, the alternatives deserve serious consideration and might win.

Where They Keep Falling Short

Here is the pattern I keep hitting. The alternatives are excellent at greenfield and start to strain the moment the content model gets genuinely complex.

A blog with posts and authors is easy in any of these tools. A content structure with deeply nested relationships, polymorphic references, conditional fields, revision workflows across content types, and the kind of editorial complexity that real enterprise content demands is where the headless tools start showing their age, and where Drupal's entity and field system pulls ahead.

This is the single most consistent finding across every round of re-evaluation I have done. The tools that win the demo lose the complex content model. Drupal that loses the demo wins the complex content model. And in the kind of work I do, the content model is almost always complex.

The Four Reasons I Keep Choosing Drupal

When I strip away the noise, four things keep Drupal as my default for the work I actually do.

1. The content modeling is genuinely better

Drupal's entity and field system is the best content modeling foundation I have worked with, and I have worked with most of them. The ability to define content types with arbitrary fields, reference entities polymorphically, attach fields to anything, build view modes for different rendering contexts, and have all of it integrate cleanly with revisions, translations, and access control is not matched by the headless alternatives.

The headless tools model content as documents with schemas. That works beautifully until your content is not really document-shaped. Drupal models content as entities in a relational graph, which is harder to learn and more powerful when the structure gets complex. For the content I work with, that power is the difference between a clean implementation and a pile of workarounds.

2. Long-term maintenance and stability

I have Drupal sites I built years ago that still run, still update, still get security patches, and still make sense to a developer opening the codebase for the first time. The upgrade path from Drupal 8 forward has been genuinely good, and the project takes backward compatibility and security seriously in a way that matters when you are responsible for a site over years rather than months.

The headless ecosystem moves faster, which is exciting and also exhausting. Tools get acquired, change pricing, deprecate APIs, or simply lose momentum. Betting a long-lived enterprise site on a venture-funded SaaS CMS means betting on that company's roadmap and survival. Drupal is not going to get acquired and pivot. That stability has real value when the site needs to live for a decade.

3. Ecosystem and community depth

Twenty years of contrib modules, documentation, Stack Exchange answers, and accumulated community knowledge is a moat that is easy to undervalue until you need it. When I hit an unusual problem in Drupal, someone has almost certainly hit it before and written about it. The depth of the ecosystem means most problems are solved problems.

The newer tools have enthusiastic communities, but they do not have twenty years of accumulated edge-case solutions. When you hit the unusual problem in a younger ecosystem, you are often the first one there, which means you are solving it from scratch.

4. Migration and enterprise-scale capability

Drupal's Migrate API and its broader enterprise tooling (multilingual, workflow, content moderation, granular permissions, multisite) are built for the scale and complexity that enterprise content operations actually have. I have migrated large, messy, legacy content estates into Drupal, and the tooling for that work is mature in a way the alternatives have not matched.

When a project involves moving hundreds of thousands of pieces of content from a legacy system, with all the data-cleaning and field-mapping and URL-preservation that entails, Drupal has the tools and the patterns. Most of the alternatives assume you are starting fresh, because greenfield is where they shine.

What This Means in Practice

The honest synthesis is this. Drupal is not the right answer for every project, and I do not pretend it is. For greenfield projects with simple content models and React-native teams, the alternatives are often better and I will say so.

But for the work I actually do, which involves complex content models, enterprise requirements, long-lived sites, and frequently the migration of large legacy content estates, Drupal keeps winning the evaluation. Not because I am attached to it. Because every time I take the alternatives seriously and build something real with them, I hit the same wall: they are excellent until the content model gets hard, and then Drupal pulls ahead.

The decision is not "Drupal is best." The decision is "Drupal is best for this kind of work," and the kind of work I do keeps being that kind.

Closing Thought

The reason I stay aware of the alternatives is that the day one of them closes the gap on complex content modeling, long-term stability, and enterprise migration, I want to know about it before my competitors do. So far that day has not come. The headless tools keep getting better at the things they were already good at, and keep not solving the things Drupal is good at.

Maybe that changes. Maybe Payload or whatever comes next builds a content modeling system that matches Drupal's entity API while keeping the modern developer experience. If it does, I will notice, because I pay attention. Until then, the choice keeps making itself.

If you have moved from Drupal to one of the alternatives and it held up on a genuinely complex content model, I would be curious to hear about it. That is the case I keep expecting to find and keep not finding, and I would rather learn it from you than from losing a project.

The Drupal Scheduler module automates content publishing and unpublishing. Learn about the module setup, its cron dependency, workflow integration, and configuration.

Overview Defence Housing Australia’s challenge The Defence Housing Australia website was on Sitefinity CMS, a proprietary content management system that was approaching end-of-life (EOL). DHA wanted to rebuild its website on the GovCMS SaaS platform, within a tight time frame of only 9-12 weeks to ensure that the replatforming was done prior to the EOL date. Defence Housing Australia’s transformation Salsa Digital started with an assessment to ensure GovCMS SaaS and CivicTheme would meet DHA’s needs. As part of the assessment (and in preparation for the content migration) Salsa mapped the existing content structures to CivicTheme. The mapping became a key input to the Figma designs, platform configuration and content uplift.

Today we are talking about AI, Agents, and A System to manage them with guest Luke McCormick. We'll also cover AI Auto-reference as our module of the week.

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

Topics

• Introducing Agent Management
• Origin Story Claude Credits
• Scrum Meets AI Retention
• Handoff Protocol Filesystem
• Why Handoffs Work So Well
• Examples and Human Loop
• Agent Roles and Model Costs
• Choosing Models by Task
• Not Drupal Specific
• Works With Any Model
• Scrum Sprints For Agents
• Human Cognitive Overload
• Tuning Autonomy Levels
• Setup And Handoff File
• Updating Customized AMS
• Persistent Memory Artifacts
• Demand Better Summaries
• Solo Power With Agents
• Roadmap And AMS Trio

Resources

• Stanford Web Camp - Agile for Agents – Managing Robots The Way We Manage Humans.
• AMS
• Robert Douglas spec kitty
• xdebug tui
• ams-trio

Guests

Luke McCormick - cellear

Hosts

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

MOTW Correspondent

Martin Anderson-Clutz - mandclu.com mandclu

• Brief description:
  • Have you ever wanted to use AI to suggest related content on your Drupal site? There's a module for that.
• Module name/project name:
  • AI Auto-reference
• Brief history
  • How old: created in June 2023 by Scott Euser (scott_euser) or Soapbox
  • Versions available: 1.0.0-rc4
• Maintainership
  • Actively maintained
  • Security coverage - opted in, needs stable release
  • Test coverage
  • Number of open issues: 4 open issues, 1 of which is a bug
• Usage stats:
  • 19 sites
• Module features and usage
  • AI Auto-reference works with any reference fields, so it could find suitable taxonomy terms, nodes, etc
  • It does that by rendering a specified view mode, so it should with any kind of complex layout approach you may have implemented on your site
  • It will also automatically shorten your content to fit within your AI model's token window, which you can also configure
  • The module extends Drupal's main AI module, which means you can select which model to use, and probably means you can also use guardrails, and all the other powerful features that come with that ecosystem
  • Ai Auto-reference comes with default prompts, but you can also edit those if you really want to make sure you're squeezing out every drop of relevance
  • You can also choose for which fields in each content type you want to generate suggestions, as well as whether you want the suggestions should be automatically applied, or whether you want them manually reviewed
  • As mentioned on the project page, you can already have AI suggest things like tags using the AI module without this project, but this may be a better choice if you want to make sure the recommendations stick to an existing set

Governance, infrastructure funding, and release maintenance define this week’s Editor’s Pick as the Drupal Association keeps self-nominations open for its 2026 At-Large Board Election and introduces the Drupal Sustaining Members Program. The updates connect elected representation, recurring support for shared project infrastructure, security remediation, and final testing for Drupal 11.4.0-rc2.

The election will fill one community-elected seat on the Drupal Association Board. The seat opens as Alejandro Moreno completes their 2024–2026 term. Candidates must self-nominate, and nominations close on 30 June 2026 at 23:59 UTC.

Candidates will be announced on 7 July 2026. The Get to Know the Candidates period runs from 7 July to 21 July 2026, followed by voting from 22 July 2026 at 00:00 UTC to 14 August 2026 at 23:59 UTC. The new board member will be announced on 26 August 2026.

Voting eligibility depends on individual Drupal Association membership. Members must have an active membership by 21 July 2026 at 00:00 UTC, at least 24 hours before voting opens. The schedule gives prospective candidates and voters clear deadlines for participation before the election enters its voting phase.

The Drupal Sustaining Members Program creates a recurring funding path for organisations that depend on Drupal. The association says contributions support Drupal.org, code repositories, software packaging and distribution, the Composer package endpoint, issue tracking, contribution workflows, continuous integration and testing, Automated Updates, Project Browser infrastructure, and security response systems. The programme frames shared infrastructure as an operational responsibility rather than an incidental benefit of open-source use.

The programme follows Acquia’s Fair Trade Initiative, which directs 2% of eligible Acquia partner Drupal deals to the Drupal Association. Together, the two efforts point to a more predictable funding model for infrastructure used across the Drupal ecosystem.

Maintainers should also review Drupal security advisories published on 17 June 2026. The Drupal core advisories cover improper validation, server-side request forgery, cache poisoning and open redirect, a gadget chain, and PHP object injection. Contributed project advisories were also published for Plotly.js Graphing, Flag attendance field, and Formatter Field.

Drupal 11.4.0-rc2 is available for final testing ahead of the Drupal 11.4.0 stable release window. Release candidates are not supported for production sites, but they allow developers, maintainers, translators, and site builders to test compatibility before the stable release. Sites using Media oEmbed URL discovery may also need to review media_oembed_discovery_trusted_host_patterns in settings.php.

Drupal 11.4.x will receive security support until June 2027. Drupal 11.3.x will continue to receive security support until December 2026. Those support windows give site owners a near-term basis for upgrade and maintenance planning.

The DropTimes also held its June Open Townhall as part of its monthly community coordination format. The session covered editorial updates, contributor coordination, community feedback, and coverage planning. It reflects TDT’s continuing effort to align editorial priorities with Drupal community activity and reader input.

Upcoming Drupal events include DrupalCamp Tokyo 2026 on 27 June 2026 in Tokyo, DrupalCamp Kortrijk 2026 from 29 June to 30 June 2026 in Kortrijk, Drupal Camp Asheville 2026 from 10 July to 12 July 2026 in Asheville, and Decoupled Days 2026 from 6 August to 7 August 2026 in Montréal.

The week’s updates place governance, funding, security, release readiness, editorial coordination, and community participation in the same frame. Community members considering board service can review the election process before nominations close. Organisations that rely on Drupal can assess whether recurring infrastructure support fits their open source contribution model.

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.

Allen Jason
Junior sub-editor
The Drop Times

Provider costs, agent behaviour and multilingual support are becoming practical governance questions for Drupal sites adopting AI workflows. In written responses facilitated by the DrupalCamp Tokyo 2026 organisers, James Abrahams told The DropTimes that Drupal AI is relying on pluggable governance, Drupal CMS-aligned work, outside-in agent workflows and collaboration with Symfony AI. His answers frame Drupal’s AI direction around maintainability, structured site building and multilingual production readiness rather than isolated feature development.

Read more

AI makes execution cheap. It makes context, coordination, governance and sovereignty more valuable.

The CMS is being unbundled into a control plane and an execution plane. Follow that logic across the full customer experience and something else becomes visible: the DXP is being rebundled as the shared control plane for an organisation’s digital promise.

The CMS is unbundling. The DXP is rebundling.drupalMonday, June 22, 2026 - 18:00

DrupalCon Rotterdam’s first Government Summit has opened its call for public-sector session proposals ahead of the one-day event on Monday 28 September 2026. The summit will bring local, national, and European public administrations together around shared digital infrastructure, open source reuse, digital sovereignty, and Drupal-based service delivery. Organisers are seeking case studies, demonstrations, workshops, and facilitated discussions, with submissions closing on Monday 29 June 2026 and selected participants receiving complimentary access to the summit.

We Love To Hear Your Support Questions!

As you know and have experienced personally, AI has been replacing human interaction in support situations, and in some cases doing a decent job. It generally does a good job with questions about DDEV.

But getting answers to questions is not the only purpose of support. It's also a great way to communicate problems and ambiguities to project maintainers.

We want you to ask us questions! We live for your questions. We miss the fact that you've been absent from Discord, #ddev in Drupal Slack, and the issue queue. When you ask, it helps us to understand what your struggles are and how DDEV can get better. DDEV's strength has always been the community's willingness to engage and share their needs and frictions and hopes for the project.

As you know, Stack Overflow has been displaced by AI. There aren't new answers going up there, because people use the AI answers and don't improve anything for the future. But DDEV is not static and its future depends on you and your needs. If we don't hear you ask about those, we can't react to your experience.

Join us in all the support channels!

Upsun Completes DDEV Trademark Transfer

Upsun has finished transferring the DDEV trademark to the DDEV Foundation — a milestone for the DDEV project's long-term independence and health. This is a generous and important step for DDEV. (At one time before Upsun/Platform's involvement, we were ready to fork and rename the project due to trademark issues.) Read our announcement↗ and see Upsun's generous response↗ as well.

What's New

• coder.ddev.com: Drupal Contrib → The hosted Coder.ddev.com environment now supports Drupal contrib projects via the DDEV Drupal Contrib add-on workflow.
• Joomla! Explicit Support → Joomla users have loved DDEV for years, and in DDEV v1.25.2 we introduced an explicit joomla project type. Community member renekreijveld also maintains the ddev-joomla↗ repository, which provides scripts and tooling for extended Joomla workflows.
• mayfly.live → Zero-config DDEV-based online preview environments, in open beta.
• Drupal AI Learner's Club AI Safety Session → Randy was co-host of AI Security 'Opportunities': Guardrails, Sandboxes, and Keeping Your Agents on a Leash and introduced a couple of the many add-ons.

New DDEV GUIs

New community-built GUI tools have appeared for DDEV:

• ddevbar → A macOS menu bar app for managing DDEV projects with a single click — start, stop, and restart without touching the terminal. klemens.ee/ddevbar↗
• DDEVUI → A native macOS app (Swift/SwiftUI) that puts a visual front-end on DDEV. github.com/dave-agilepixel/DDEV-Apple-GUI↗
• ddev-ui → A cross-platform desktop app for macOS, Windows, and Linux built with Electron and React. Covers project management, database import/export, snapshots, add-on management, log streaming, and more. github.com/shiv122/ddev-ui↗

Stanford WebCamp: Pre-Flight Checklist for Drupal Developers

Bob McDonald (UltraBob) presented "Pre-Flight Checklist: Local Code Quality for Drupal Developers" at Stanford WebCamp, covering the ddev-drupal-code-quality add-on for running Drupal.org CI checks locally before pushing. View session↗.

DrupalDevDays Athens — Video Now Available

Community member Bill Seremetis (bserem)'s "From Chaos to Consistency" DevOps talk from DrupalDevDays Athens 2026 is now on YouTube. The talk covers how DDEV add-ons work as a file/feature delivery mechanism for standardizing team projects. Watch on YouTube↗ • Slides↗.

Community Highlights

DDEV Sponsorship Data Story — A new post on ddev.com tells the story of how a LinkedIn message from Anoop John at TheDropTimes turned into live, auto-updating sponsorship displays across DDEV properties and a public data feed. Read it↗

Open Source AI Contributions — Amber Matz wrote about the complexity AI-generated contributions are bringing to open source projects, using a conversation with Randy as a central example. Worth a read for all maintainers and contributors and AI users. Read↗

Community Tutorials from Around the Web

• Getting Started with DDEV for Drupal Development → WebWash covers installation, project setup, commands, database management, and debugging with DDEV and Drupal. Read on WebWash↗
• DDEV Linux Installation with WordPress → Step-by-step guide to installing DDEV on Ubuntu and setting up a WordPress project with WP-CLI. Read on rueegger.me in German↗
• DDEV + a-blog cms (Japanese) → A guide to using DDEV as a local development environment for a-blog cms, covering multi-project management and Mailpit. Read on kazumich.com↗
• Lando & DDEV: Replacing Custom Shell Scripts — Drainpipe → Lullabot explores how Drainpipe, a Composer plugin for Drupal CI/CD, can use either Lando or DDEV as its local environment. Read on Lullabot↗

Governance

The DDEV board and community are working on updated sponsorship tiers and improved communication around them. Discussion at ddev/sponsorship-data#42↗ and ddev.com#647↗.

The first-ever DDEV Foundation Board meeting was held on June 17!

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

Sponsorship Update

Sponsorship is at 84% of the goal, thank you to everyone who has contributed!

April 2026: ~$9429/month (79% of goal)

June 2026: ~$10,075/month (84% of goal)

If DDEV has helped your team, consider sponsoring. → Become a sponsor↗

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

Statistical Tidbits of the Month

• DDEV has exceeded 20,000 weekly users some weeks! — 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.

Views is one of the most important modules in Drupal. After the field system, it is the tool you reach for most often as a site builder. You use it to build content listings, create blocks, power admin screens, and feed components into Drupal Canvas.

In the video above, you’ll learn how to build a Views page, customize fields with image styles and rewrite tokens, expose filters and sorts, configure pagers and infinite scroll, expose a view block as a Canvas component, and create a backend admin page.

LocalGov Drupal Camp 2026

LocalGov Drupal Camp 2026 was held on 11th and 12th June in the city of Sheffield in the north of England. I drove over the Pennines from my home in Cheshire to attend the camp for the two days.

LocalGov Drupal, in case you weren't aware, is a Drupal distribution that is set up in a way that makes it easy for councils to publish their content. Since it's built on Drupal the sites can also make use of the many Drupal modules available. There are also lots of additional LocalGov Drupal modules that integrate with waste collection systems, bus timetables, election results, and many more.

Last year, LocalGov Drupal was being used by 57 council websites across the UK. This year, that figure has jumped to 73! A fantastic achievement, with that number only set to get bigger.

The camp itself consisted of a Wednesday night social night, a day of talks and other sessions, followed by a day of workshops and sprints.

Wednesday Night

The social on Wednesday night was held at the National Videogame Museum in Sheffield city centre. On entry we got a couple of free drinks, and there was plenty of pizza to go around (perhaps too much pizza!).

This was amazing venue to have a social! After spending a while catching up and chatting with lots people we went into the museum itself and played some games for a while. 4 player Pacman and Ultimate Chicken Horse were particular favourites from the evening.

philipnorton42 Sun, 06/21/2026 - 18:49

A Drupal 7 migration in 2026 should not be treated as a simple technical upgrade. The statistics point to a wider operational risk that requires audit work, budgeting, content migration planning, and editorial interface decisions. Drupal 7 Has Not Disappeared, Even Though Official Support Has Ended Official security and compatibility support for Drupal 7 ended on 5 January 2025. Drupal.org explains on its Drupal 7 End of Life page that Drupal 7 no longer receives regular community security or compatibility updates after that date. In 2026, the question is no longer whether Drupal 7 will reach end of life. It already has. Public usage data still shows that many websites have not yet moved to a newer Drupal version or another platform. According to Drupal.org usage statistics, more than…

When an organization plans a new digital platform or modernizes an existing Drupal website, the discussion often turns to one question: should Drupal be used as a full content management and web platform, or should the organization move toward a headless CMS model? The right answer depends less on the trend and more on how content, services, users and administration work in practice. Drupal vs Headless CMS: which approach fits a large organization's digital platform? When an organization plans a new digital platform or modernizes an existing Drupal website, the discussion often turns to one question: should Drupal be used as a full content management and web platform, or should the organization move toward a headless CMS model? This is not only a technical choice. For larger…

Artificial Intelligence has dramatically changed the way content is created. Tasks that once required hours of research and writing can now be completed in minutes. Blog posts, product descriptions, FAQs, summaries, social media content, and even long-form articles can be generated using AI-powered tools with just a few prompts.

Inherited Drupal sites often leave teams with scattered checks, uncertain configuration, and limited visibility beyond the repository. Robert Menetray Caballero built DruScan from freelance audit scripts into a contributed module and optional dashboard that reviews configuration, logs, module updates, code quality, security-related signals, and score history. The tool’s privacy boundary is central: detailed reports remain inside the local Drupal environment, while DruScan receives only the data needed for cross-site monitoring, keeping it as an oversight aid rather than a replacement for Drupal judgement.

Search Across Multiple Drupal Sites with Pantheon SOLR Joel Steidl Thu, 06/18/2026 - 13:34 Drupal

Search feels like a solved problem. Until you're managing a network of Drupal sites and your users expect to find content regardless of which one it lives on, that is. At that point, the question stops being "how do we add search?" and starts being "how do we build a unified search experience across an entire digital ecosystem?"

The obvious workaround is to bring in a third-party Solr provider. That works, but it means another vendor, another bill, and another service to monitor and secure. For organizations already invested in Pantheon's managed infrastructure, it further fragments the operational footprint rather than simplifying it.

At Aten, this challenge comes up regularly with clients running multi-site Drupal architectures on Pantheon. The solution we've landed on keeps everything within the platform, using four contributed modules working together as a hub-and-spoke proxy. This post walks through the architecture, why it exists, and how to implement it.

The Constraint You Can't Route Around

Pantheon's managed Solr is excellent: zero server administration, mTLS-secured connections, schema management handled through a purpose-built API. But it comes with a hard platform constraint: each Drupal site environment gets exactly one Solr core, and that core is network-isolated to that environment.

There is no platform mechanism to point a second Drupal site at another site's Solr instance. Each site can only talk to its own.

This is a reasonable security tradeoff for single-site use. But for a multi-site architecture where you need a single search index spanning many sites, it forces you to think architecturally rather than just reach for a configuration option.

The Architecture: One Hub, Many Clients

The solution is a hub-and-spoke proxy. One Drupal site (the hub) owns the Solr core and exposes it to other sites over authenticated HTTP. Every other site (the clients) routes its search queries through the hub instead of connecting to Solr directly.

From Pantheon's perspective, only the hub ever touches Solr. The constraint is satisfied. From Search API's perspective, every client is talking to a Solr instance in the normal way. The architecture sits between those two layers.

Four contributed modules make this work:

ModuleInstalled onRolesearch_api_pantheonHubConnects to Pantheon Solr via env vars and mTLSpantheon_solr_apiHubExposes Solr to authenticated clients via HTTP proxysearch_api_solr_proxyEach clientAbstract proxy base; no direct configurationsearch_api_solr_proxy_pantheon_connectorEach clientRoutes queries through hub; manages API key via Key moduleWhat Each Module DoesHub: search_api_pantheon

This is the only module in the stack that speaks directly to Pantheon's Solr. It extends Search API Solr's standard connector and replaces the typical admin configuration form with auto-discovered values from Pantheon's environment variables (PANTHEON_INDEX_HOST, PANTHEON_INDEX_PORT, PANTHEON_INDEX_CORE, and others). On Pantheon environments, those fields are disabled in the UI; the platform owns them.

For transport, it swaps in a custom cURL adapter that uses the mTLS certificate Pantheon provisions at ~/certs/binding.pem. Schema uploads and core reloads go through Pantheon's proprietary endpoints rather than the standard Solr APIs.

Hub: pantheon_solr_api

This module is what actually opens the hub's Solr to the outside world. It exposes a set of Drupal routes at /solr-proxy/{action} that authenticated client sites can POST and GET against, and a standalone PHP file at /pantheon-solr-proxy.php for high-performance SELECT queries (more on that below).

Every request is validated against a shared API key before it reaches Solr. The key is read from a configured Key module entity (backed by a Pantheon Secret) and compared using hash_equals(), a timing-safe comparison that prevents key enumeration attacks. Only a hardcoded allowlist of Solr actions (select, update, update/json, admin/ping, admin/luke, config, and a handful of others) will be forwarded. Anything outside that list returns a 403.

Client registrations are tracked in Drupal config, keyed by the combination of each site's Search API site hash and index ID, the same namespace Search API Solr uses internally to scope documents.

Client: search_api_solr_proxy + search_api_solr_proxy_pantheon_connector

search_api_solr_proxy is a framework-only module. It provides the abstract SolrProxyConnectorBase class but is not useful on its own. search_api_solr_proxy_pantheon_connector is the Pantheon-specific implementation.

On each client site, the connector replaces the standard Search API server configuration (host, port, path, core) with a single hub_url field. A Guzzle middleware stack handles two things:

1. Auth injection: every outbound request gets an X-Pantheon-Solr-Key header carrying the API key from the Key module entity.
2. URL rewriting: SELECT queries are redirected to /pantheon-solr-proxy.php on the hub; everything else routes to /solr-proxy/{action} through Drupal.

Because client sites never manage the Solr schema directly, skip_schema_check is permanently enabled. The connector also auto-detects the Solr version by querying the hub's admin/system endpoint, falling back to 8.11.4 (Pantheon's current managed version) if the endpoint is unreachable.

How a Search Query Actually Travels

Here is the path of a typical user search on a client site:

1. Search API builds a Solr SELECT query.
2. The connector's Guzzle middleware intercepts it, adds the X-Pantheon-Solr-Key header, and rewrites the URL to https://hub.example.com/pantheon-solr-proxy.php?....
3. The request arrives at the hub's web root. pantheon-solr-proxy.php runs as a standalone PHP script with no Drupal bootstrap. It validates the API key, constructs the Solr URL from Pantheon environment variables, and forwards the request using the mTLS certificate.
4. Solr responds. The script returns the raw JSON response directly.
5. Search API processes the results on the client site.

SELECT queries bypass Drupal's bootstrap entirely. On a warm server, the round trip through the proxy adds approximately 5ms of overhead. Writes, admin actions, and schema operations go through the Drupal controller instead, which adds around 150ms. That's acceptable for infrequent operations.

Getting It Set UpOn the hub sitecomposer require drupal/search_api_pantheon drupal/pantheon_solr_api drush en search_api_pantheon pantheon_solr_api

Navigate to Administration > Configuration > Search and metadata > Pantheon Solr API. Select or create a Key entity pointing to the PANTHEON_SOLR_API_KEY Pantheon Secret. This is the shared key your client sites will use to authenticate.

Copy pantheon-solr-proxy.php (provided by pantheon_solr_api) to your hub site's web root. This is the fast-path script for SELECT queries.

On each client sitecomposer require drupal/search_api drupal/search_api_solr drupal/search_api_solr_proxy drush en search_api search_api_solr search_api_solr_proxy_pantheon_connector

Create a Search API server using the Pantheon Solr Proxy connector. Set the Hub URL to your hub site's base URL. Configure the Key entity to use the same PANTHEON_SOLR_API_KEY secret.

Create your Search API index on that server as you normally would, with any entity types, fields, and processors you need.

Then run the registration command:

drush pantheon-solr-proxy:register

This command auto-discovers your Search API server and index, reads the site hash and index ID that Search API Solr uses to namespace your documents, and POSTs that registration to the hub. Back on the hub, run:

drush pantheon-solr-api:update-index

Repeat the client-side steps for each site in your network.

A Few Things Worth Knowing

Schema management stays on the hub. Only the hub ever uploads schema files to Pantheon. Client sites have skip_schema_check forced on. If your search requirements across sites are different enough to require separate schemas, this architecture assumes you can reconcile them into a single configset. In practice, the search_api_solr jump-start configset handles most requirements.

Document namespacing is automatic. Search API Solr already scopes every indexed document with a per-site hash and index ID prefix. Each client site's documents live in separate namespaces within the same Solr core. Cross-site queries need to either search all namespaces or be scoped deliberately; your Views or custom query code controls this.

The API key is a Pantheon Secret, not a config value. Keys stored in pantheon_solr_api.settings Drupal config hold a reference to a Key module entity, not the raw key. The actual secret is resolved at runtime from PANTHEON_SOLR_API_KEY. This keeps credentials out of your config exports and codebase.

Building Across Site Boundaries

Unified search across a multi-site Drupal architecture is one of those problems that looks straightforward until you try to implement it on a managed platform. Pantheon's security model solves a lot of problems, but it introduces constraints that require a deliberate architectural response.

The hub-and-spoke proxy described here is that response. It works within the platform's model, keeps credentials out of the codebase, and adds minimal latency to the critical read path.

If you're building a multi-site Drupal ecosystem and working through the hard architectural questions around search, shared data, and cross-site workflows, get in touch with the Aten team. This is the kind of problem we solve.

Joel Steidl

B2C eCommerce usually gets all the attention, because that’s what most people engage with. They buy stuff from Amazon, Etsy, or a Shopify store without thinking too much about it. The customer comes to the website and makes a purchase. Usually, there is a portal to track the order and some transactional emails for updates, and finally, the package is delivered to their door. If they bought from a company that has its act together, they might spend the next 3-6 months being remarketed to because the company really wants to make this customer a repeat customer. 

But this B2C eCommerce experience, while ubiquitous and recognizable to most, is only scratching the surface.

The scale of B2B commerce is actually much larger than its B2C cousin. The global B2B eCommerce market is expected to reach roughly $37 trillion in 2026, approximately six times the size of the global B2C market. Yet despite that enormous footprint, B2B digital commerce remains far less mature than its B2C counterpart. Software that serves the latter doesn’t work for the former. The differences between B2B and B2C commerce run deep, from how deals get made to how orders get shipped to how platforms are architected. Different customers. Different requirements. Different expectations. To add further complications, businesses increasingly need to operate in both worlds simultaneously. 

Read more