25 Jun 2026

feedDrupal.org aggregator

Dries Buytaert: Launching Drupal's Outside AI workstream

Earlier this week, in "Drupal's role in agentic workflows", I argued that Drupal's AI future has two parts: helping people with AI inside Drupal, and helping agents use Drupal from the outside.

So we are splitting Drupal's AI strategy into two workstreams. Inside AI is led by Christoph Breidert, who has been driving that work already. Outside AI, the new workstream, is led by Scott Falconer.

The easiest way to think about the difference: with Inside AI, a person uses Drupal, and Drupal uses AI to help. With Outside AI, a person uses an agent, and the agent uses Drupal.

We launched the Drupal AI Initiative one year ago, in June 2025, with a published strategy. A year later it spans 32 organizations and more than 50 contributors, shipping against a public 2026 roadmap through two paid delivery teams.

So far, most of that work has focused on Inside AI, though much of the foundation also supports Outside AI.

Outside AI will serve three kinds of users:

If we are successful, agents will recommend Drupal to new users, help Drupal developers move faster, help agencies win more work, and use Drupal as the trusted layer for content management and governance.

Thank you to everyone who helped bring the Drupal AI Initiative to this point. Together, the community has turned an ambitious idea into real momentum.

I'm excited about what comes next! Want to get involved? Join the #ai-initiative channel on Drupal Slack.

25 Jun 2026 3:44pm GMT

Drupal AI Initiative: Drupal AI Initiative: introducing Inside AI and Outside AI

By the Drupal AI Initiative

A year ago, we launched the Drupal AI Initiative with a published strategy and a bet that AI would matter enormously to Drupal's future. Today the initiative spans 32 organizations and more than 50 contributors, shipping against a public 2026 roadmap.

As the work has grown, it's become clear that our AI strategy needs to cover two distinct areas. While innovation and product development remain core goals across everything we do, we are organizing our day-to-day execution into two workstreams: Inside AI, led by Christoph Breidert, and Outside AI, a new stream led by Scott Falconer.

The unified AI initiative leadership team - made up of the existing initiative members - will continue to shape our overarching roadmap, while Christoph and Scott ensure that vision is executed. We will outline this leadership team and other key supporting roles in an upcoming post.

The core difference: Inside AI brings AI tools into the Drupal interface to assist the people using it. Outside AI makes Drupal the platform external AI agents reach for and act on.

Inside AI

Inside AI is AI inside Drupal, for the people using it: assistants, in-product workflows, page-building, and the rest of the user-facing surface. This is the work the initiative has been driving for the past year, and it continues against the 2026 roadmap already in flight.

Outside AI

Outside AI is AI outside Drupal, acting on Drupal. A person, agency, host, or developer is using an external agent or builder tool, and that agent needs to start with Drupal, connect to Drupal, inspect Drupal, change Drupal, verify Drupal, migrate into Drupal, or launch Drupal.

What's next

You'll see public roadmaps from both streams. Inside AI continues against its existing 2026 roadmap; Outside AI will publish its own outcomes and milestones, with a first proof of direction targeted for DrupalCon Rotterdam. Where both streams need the same capability, the answer is usually one shared Drupal contribution, not two parallel builds.

Get involved

The initiative is open, and both streams need contributors - whether you write code, test against real agent workflows, work on documentation, or bring a use case from your own agency or organization.

Not sure where to start? Come say hello in Slack and we'll help you find a first contribution.

25 Jun 2026 3:26pm GMT

The Drop Times: DrupalCamp Kortrijk Speakers Preview Configuration, Performance, CSS and Editorial UX

For Drupal teams, small technical choices often decide how maintainable a site becomes. DrupalCamp Kortrijk speakers are using that practical layer as the entry point for sessions on configuration, performance, CSS and editorial work.

25 Jun 2026 3:03pm GMT

Acquia.com - Drupal Blog: Vibe Coding Drupal: A Force Multiplier for Contrib

Maintainer burnout threatens Drupal's 50,000+ contrib modules. How vibe coding with AI is becoming a lifeline for open source.

25 Jun 2026 1:38pm GMT

Droptica: Text in images and SEO: why image-based content kills visibility - and how to fix it

Texte dans les images SEO : corriger le contenu image | Droptica

When a CMS is too hard to use, teams paste text into graphics and upload them as images. The page looks right - but search engines and AI answer engines cannot read that content at all.

See what image-based content costs you in SEO, GEO, accessibility, and day-to-day management - and how structured Drupal components fix it page by page.

25 Jun 2026 11:06am GMT

LakeDrops Drupal Consulting, Development and Hosting: Three Players, One Direction: ECA, FlowDrop, and Maestro

Three Players, One Direction: ECA, FlowDrop, and Maestro

Three musicians playing instruments in a wheat field

Jürgen Haas

ECA, FlowDrop, and Maestro all draw boxes and connect them with arrows, so people keep asking whether three Drupal workflow modules means a split community. Not quite. Dries Buytaert, Randy Kolenko, Shibin Das, and I are writing a shared orchestration design spec, disagreeing productively in writing. One axis explains all three: how much state a run carries. ECA reacts statelessly to any Drupal event across the whole request surface. Maestro holds a durable process that can wait days for human approval. FlowDrop spans the axis with a typed, inspectable dataflow graph that runs sync, async, or stateful from one definition, and Shibin is refining it toward strictly serializable data, ideal for building complex AI agents. Nothing is frozen. The word "orchestration" itself is contested in the spec glossary. Composition already ships: maestro_eca_task lets a Maestro process hand off to ECA. The bigger vision, ECA reacting to content, calling a FlowDrop AI flow, then routing through Maestro for human approval, is a picture we are building toward, not a release. But bridges are the start, not the finish. The real work is building a shared foundation, common primitives and APIs so the three tools stop reinventing the same concepts under different names. The spec's vocabulary synthesis shows the embarrassing similarity: Trigger, Step, Condition, Workflow, Run. The keystone is a defined contract for handing data between steps and between tools, one that works beyond Drupal's border for AI agents and external systems. Three tools is the right number because the stateless-reactive and instance-stateful ends pull architectures in opposite directions. Specialization beats a mediocre merger.

25 Jun 2026 11:00am GMT

Droptica: Zero-training CMS: delivering Drupal that content editors use immediately

CMS sans formation: Drupal dès le premier jour | Droptica

If your CMS needs a two-hour training session before anyone can use it, the CMS has a UX problem. The fix is not better training. It is a system that doesn't need any.

See the Drupal admin UX patterns, staging-first handover approach, and how Edenred Polska's marketing team started building production pages with no formal training at all.

25 Jun 2026 9:22am GMT

Tag1 Insights: Building a Production-Ready Drupal Module in a Weekend with AI: The LinkStash Story

At Tag1, we believe in proving AI within our own work before recommending it to clients. This post is part of our AI Applied content series, where team members share real stories of how they're using Artificial Intelligence and the insights and lessons they learn along the way. Here, Dénes Szabó (Drupal Developer) built LinkStash, a production-ready Drupal 11 bookmarking module, in one weekend using Claude Sonnet 4.5.

The Browser Tab Apocalypse

You know the feeling. It's Tuesday afternoon, you have 47 browser tabs open across three different browsers, and somewhere in that digital haystack is that one article you absolutely need to reference. Chrome has the documentation you bookmarked last week. Firefox has the GitHub issues you were reviewing. Safari has... honestly, you can't remember what Safari has anymore. Your browser's "Reading List" feature is laughing at you. Your bookmarks folder looks like a digital hoarder's attic. And don't even get started on those "bookmark this page to read later" services that require uploading all your data to someone else's server.

As a Drupal developer, I looked at this chaos and thought: "I could fix this. I have the technology. I have the skills. I have... absolutely no time to actually build it because I'm too busy managing 47 browser tabs."

So naturally, I decided to see if AI could help me build it in a weekend instead.

The Experiment: Can AI Build a Real Drupal Module?

The goal was ambitious but clear: build LinkStash, a personal bookmarking tool, as a production-ready Drupal 11 contrib module suitable for release on drupal.org. Not a prototype. Not a proof-of-concept. A real, tested, documented, standards-compliant module that follows all of Drupal's best practices and passes the strict quality requirements for the official repository.

The feature list was substantial: entity system with full CRUD operations, browser bookmarklet for one-click saving, automatic metadata fetching with SSRF protection, smart domain-based auto-categorization, video embed support for YouTube and Facebook, Views integration with filters, 100% PHPCS compliance, PHPStan Level 1 static analysis, and a full test suite. Oh, and proper documentation including README, CHANGELOG, and API docs.

You know, just a light weekend project. What could possibly go wrong?

Why Claude Sonnet 4.5, Not Opus?

Here's where it gets interesting. Everyone assumes you need the biggest, most powerful AI model for serious development work. But I deliberately chose Claude Sonnet 4.5 instead of Opus, and here's why: it's way cheaper, significantly faster, and (here's the kicker) equally clever for code generation.

For structured development tasks with clear requirements, Sonnet 4.5 absolutely shines. It understands Drupal architecture, follows coding standards precisely, writes comprehensive tests, and generates production-quality code. The speed difference is noticeable: responses come back in seconds instead of tens of seconds. When you're iterating on test failures or fixing PHPCS violations, that speed compounds into serious time savings.

The cost difference? Even more dramatic. We're talking roughly one-fifth the cost per token. Over the course of building LinkStash, which consumed an estimated 200-250K tokens across multiple development sessions, Sonnet 4.5 probably cost around $3-$5 total.

That's less than a fancy coffee, for a complete, production-ready Drupal module. Let that sink in.

The Human-AI Collaboration: How We Actually Built It

AI didn't build this module alone. This was a collaboration, and understanding the dynamics matters.

What AI did (the heavy lifting):

What I did (the professional supervision):

When I Had to Intervene: The Learning Moments

The most surprising part wasn't what went smoothly; it was where AI stumbled and needed human expertise.

The constant mystery. AI kept trying to use EntityStorageInterface::SAVED_NEW, but that constant doesn't live in that interface. It's a global constant in core/includes/common.inc. I had to explicitly correct this: "This constant does not exist in this interface. It's defined in common.inc. Fix it." The AI course-corrected immediately.

The access control saga. All seven access tests were failing despite correct permissions and entity ownership. AI tried using AccessResult::allowedIf(), which should work, but didn't in Drupal 11's kernel test environment. After systematic debugging, I suggested trying explicit conditionals instead. That fixed it instantly; it was a behavioral quirk AI wouldn't have discovered alone.

The vocabulary ID confusion. Tests were creating a tags vocabulary, but the actual config created linkstash_tags. AI confidently wrote tests that failed due to this mismatch. Human pattern recognition caught it: "You're testing against the wrong vocabulary ID."

The YouTube ID format. AI used 3-character test IDs (abc, xyz), but YouTube video IDs are exactly 11 characters using base64url encoding. The regex pattern [a-zA-Z0-9_-]{11} doesn't lie. Once I pointed out that YouTube IDs are standardized at 11 characters, AI immediately generated valid test data.

These weren't AI failures; they were collaboration points. AI had the speed to generate code and tests. I had the domain expertise to catch subtle Drupal-specific issues. Together, we debugged faster than either of us could alone.

The Development Speed

The numbers are worth a look:

Here's what "one weekend" actually delivered:

The security model deserves a callout: SSRF protection blocks private IP ranges, local thumbnail storage prevents IP leaking, and all data is isolated per user. All three plugin systems are also fully extensible, other developers can add custom content fetchers, categorization rules, and media providers. The module ships with sensible defaults but is built for extension.

Could I have built this solo in a weekend without AI? Absolutely not. The test suite alone would have taken days. Could AI have built this without supervision? Also no. Those subtle Drupal-specific issues required experienced judgment calls.

But together? We shipped a release-ready beta in 48 hours.

The Numbers: What Did This Actually Cost?

Let's break down the economics.

Time investment:

Token usage:

Actual costs (Claude Sonnet 4.5 pricing):

Traditional development cost (rough estimate):

The AI-assisted approach wasn't just faster; it was two to three orders of magnitude cheaper while maintaining professional quality standards.

The Future: Where Do We Go From Here?

Building v1 in a weekend was exhilarating, but it's just the beginning. The roadmap has two more phases.

Phase v2 (enhanced features):

Phase v3 (advanced capabilities):

The best part? Now that the architecture is solid and the plugin systems are proven, adding these features becomes incremental. Each new feature is just another plugin implementation or service extension. The hard architectural work is done.

Was It Fun? (Spoiler: Yes, Incredibly)

Nobody warns you that AI-assisted development is fun.

There's something magical about describing what you want, for example, "Now we need a plugin system for content fetchers that can pull metadata from any URL with SSRF protection," and watching structured, working code appear in seconds. Then catching a subtle bug, pointing it out, and watching the immediate course correction. It feels less like programming and more like conducting. You're directing the architecture and reviewing the output, not typing every curly brace.

The debugging sessions were particularly entertaining. When all seven access tests failed, AI and I became detective partners:

Me: "Add debug assertions before the access check. Let's see if the user actually has permissions."

AI: Adds assertions. "Okay, permissions confirmed. User owns the entity too."

Me: "So why is AccessResult::allowedIf() not working?"

AI: "Let me try explicit conditionals instead..."

Me: "That... actually fixed all seven tests. Interesting."

That back-and-forth, that collaborative debugging energy, reminded me of pair programming with a really fast typist who never gets tired but occasionally needs you to remember obscure Drupal API behaviors.

The satisfaction of running ddev composer run-tests and seeing "187 tests, 846 assertions, OK" flash green? That hit the same way shipping your first module to production does. Except this time, we'd done it in a weekend instead of a month.

The Real Lesson: Augmentation, Not Replacement

If there's one takeaway from this experiment, it's this: AI is an amplifier, not a replacement.

I couldn't have built LinkStash in a weekend alone. But AI couldn't have built it without me either, not to production quality, not with proper security considerations, not with the architectural decisions that make it extensible and maintainable.

What AI gave me was force multiplication. Instead of typing boilerplate entity code, I specified requirements and reviewed output. Instead of writing 187 tests manually, I described what needed testing and verified the results. Instead of formatting documentation, I outlined structure and AI filled in details.

I stayed in the driver's seat for architecture, security, and critical decisions. AI handled the mechanical work of code generation, test writing, and standards compliance. Together, we shipped something neither of us could have done alone in the same timeframe.

And honestly? For a problem that's been in the back of my mind for months, "I really need a better bookmarking solution," going from idea to a release-ready beta in one weekend feels like the future.

Now if you'll excuse me, I need to actually use LinkStash to bookmark all the tabs I've accumulated while writing this blog post. The irony is not lost on me.

LinkStash is available at drupal.org/project/linkstash. Built with Claude Sonnet 4.5 via Claude Code. Source code, documentation, and contribution guidelines are available in the project repository.

Development metrics: 1 weekend, ~15 human hours, ~240K AI tokens, $3-5 compute cost, 8,000+ lines of code, 187 tests, 0 PHPCS violations, live on drupal.org.

If you're weighing whether AI can carry real weight on your next Drupal contrib module, or you want to talk through where human oversight still has to stay in the loop, let's start a conversation! We'd love to hear from you.

This post is part of Tag1's AI Applied content series, where we share how we're using AI inside our own work before bringing it to clients. Our goal is to be transparent about what works, what doesn't, and what we're still figuring out, so that together, we can build a more practical, responsible path for AI adoption.

Image by Mahmoud Ramadan from pexels

25 Jun 2026 12:00am GMT

24 Jun 2026

feedDrupal.org aggregator

Droptica: Component mindset: teaching clients to think in components

Komponenten-Mindset: Kunden in Komponenten denken | Droptica

The real deliverable of a component-based CMS is not the paragraphs. It is the moment your client stops asking for "a new page" and starts asking for "a new component."

See the four phases of the component mindset shift, what changes in the agency relationship, and how Edenred Polska went from planning to abandon Drupal to commissioning new components on a regular basis.

24 Jun 2026 6:40pm GMT

Droptica: Drupal extranet: how to build a secure portal for clients, partners, and sales teams

Drupal extranet : construire un portail sécurisé pour clients, partenaires et équipes commerciales | Droptica

Not every login wall is an intranet. Often the people you most want to serve privately are clients, partners, and sales agents - not employees.

Learn how to architect a Drupal extranet with gated content, per-user dashboards, role-based access, and the security, caching, and SEO decisions that keep partner data private.

24 Jun 2026 5:45pm GMT

The Drop Times: Andy Marquis Outlines Custom Field’s Role Alongside Paragraphs in Drupal

When Paragraphs-based content models grow deep, Drupal teams can inherit slower rendering, heavier databases, and harder migrations. Custom Field maintainer Andy Marquis explains where field-based structured data offers a leaner alternative, and where Paragraphs still belongs.

24 Jun 2026 4:31pm GMT

Centarro: How Centarro Handles Critical Drupal Security Releases

Critical security vulnerabilities don't wait for a convenient time. They arrive on their own schedule, and how quickly your team responds can mean the difference between a routine update and a serious exposure.

A highly critical advisory with a 48-hour window

On May 18, the Drupal Security Team issued PSA-2026-05-18, a pre-announcement for a highly critical security release affecting every supported branch of Drupal core. The advisory scored a 20 out of 25 on the security risk scale. No authentication required, no special access needed. The release window was two days later, on May 20, between 17:00 and 21:00 UTC.

The Drupal Security Team urged site owners to reserve time for immediate updates because exploits could be developed within hours or days. They took the unusual step of providing best-effort patch files even for end-of-life versions of Drupal 8 and 9 because the potential impact was that significant.

If you're running a site that processes orders and manages customer data, you can't put something like this off until the next sprint.

Coordinating across every client

When the pre-announcement landed, we reached out to all of our support clients and worked directly with their teams to determine priority, assess whether the vulnerability applied to each site's specific configuration, and plan accordingly.

Read more

24 Jun 2026 3:03pm GMT

Droptica: Drupal Paragraphs spacing: solving the gaps in component-based layouts

Drupal Paragraphs : marges et padding pour corriger les lacunes | Droptica

You can build a beautiful paragraph system and still watch it fall apart the first time an editor stacks two white sections together. Spacing is the detail that quietly decides whether a component-based layout feels polished or broken.

Compare three approaches to Drupal Paragraphs spacing, see a concrete Twig and CSS implementation with margin and padding controls, and learn which real-world scenarios editors run into on production sites.

24 Jun 2026 1:11pm GMT

23 Jun 2026

feedDrupal.org aggregator

Aten Design Group: Drupal Metatag Module Basics for Content Editors

Drupal Metatag Module Basics for Content Editors

Abstract city with woman looking into the void.

Joel Steidl 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 Often

Page Title

What 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 Description

What 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 URL

What 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 Title

What 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 Description

What 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 Image

What 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.

Abstract city with woman looking into the void.

Jon Bowman

23 Jun 2026 8:38pm GMT

Droptica: Drupal Paragraphs: from unusable to empowering content editors

Chaotic CMS editing on the left transforms into modular Drupal Paragraphs components assembling a clean webpage on the right.

Having Drupal Paragraphs installed is not the same as having Paragraphs working. If your editors upload images instead of editing text and file developer tickets for every small change, the problem is usually the implementation - not the platform.

See what separates broken setups from empowering component libraries, the five principles behind editor-friendly Paragraphs, and how proper configuration drove a ~24% conversion lift without a rebuild.

23 Jun 2026 8:23pm GMT

Palantir: Freedom is Not Free: A Model for Open Source Sustainability

Freedom is Not Free: A Model for Open Source Sustainability Tiffany Farriss speaks at a white podium with a laptop, addressing an audience in a room with large windows overlooking a city skyline. demet

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:

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.

23 Jun 2026 4:49pm GMT