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 windowOn 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 clientWhen 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 moreYou 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.
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 DoesThe Metatag module lets you manage information about your content that is not visible on the page itself, but is visible to:
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 ScreensAs 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:
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 ConfigurationYou 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:
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 isThe page title appears in browser tabs and is often used as the main headline in search results.
Why it mattersThis 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 practicesSummer Programs for Kids | City of Example
Meta DescriptionWhat it isA short summary that often appears below the page title in search results.
Why it mattersWhile it does not directly affect rankings, it helps people decide whether a page is relevant to them.
Best practicesExplore fun and educational summer programs for children ages 5–12. Registration now open.
Canonical URLWhat it isThe canonical URL tells search engines which version of a page should be treated as the primary one.
Why it mattersThis helps search engines identify the authoritative version of content when similar or duplicate pages exist.
For editorsIn most cases, this is handled automatically. You usually will not need to change it.
Robots (Index / Follow)What it isInstructions that tell search engines whether they should:
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 appropriateThese 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 isThe headline shown in social previews when the page is shared on social platforms.
Helpful tipThis 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 isA short summary shown beneath the title in social previews.
Helpful tipFocus on clarity and relevance. This text helps people decide whether the content is useful to them.
Open Graph ImageWhat it isThe image displayed alongside the title and description in social feeds.
Why it mattersA clear, relevant image helps your content stand out and be understood at a glance.
Best practicesYou 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:
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.
KeywordsModern search engines largely ignore this field. You can usually leave it empty unless your organization has a specific reason to use it.
Content LanguageThe 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:
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 TagsThese fields are often used for:
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 TakeawaysMost 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:
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 BowmanHaving 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.
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.
