Drupal

Date:

2026-July-22

Description:

QA Accounts enables you to login to a Drupal site using a well known username/password combination. When 1.0 was released, it also was marked for security coverage. The module prioritizes ease of use rather than security and is only intended to be used on sites that are not accessible on the internet (e.g. behind firewall or other protection). The maintainers are choosing to remove security coverage.

Solution:

Ensure qa_accounts is not enabled on any publicly available site.

Reported By:

Jordan Barnes (j-barnes)

Fixed By:

Jakob P (japerry)

22 Jul 2026 5:59pm GMT

Some downtime during a platform migration is inevitable. Data, sometimes huge amounts of data, has to be transferred. Domain records need to be updated. The final checklist before launching is extensive.

However, any reputable agency will minimize this inevitable downtime, because every hour an eCommerce site is offline costs money. A migration that drags on for days is unacceptable, causing a direct hit to revenue and customer trust.

We've migrated eCommerce operations ranging from several thousand orders to several million, with product catalogs spanning a few hundred to several hundred thousand SKUs and customer records well into the hundreds of thousands. Through that work, we've developed a set of practices that consistently keep actual site downtime to a few hours, even on the most complex projects.

Here's how to minimize your downtime.

Start migration planning as soon as the architecture is set

When do you start thinking about data migration? As soon as the architecture is nailed down. As soon as entities and fields are defined, old data stores can be mapped to the new database.

22 Jul 2026 2:54pm GMT

I kept running into the same small frustration. My site has its own search, but when I ask an AI agent whether I have written about a topic before, it searches Google instead of using my site's search directly. As a result, it often misses relevant posts that Google has not indexed.

At the same time, the web is gaining a new audience. In addition to people visiting pages, AI agents increasingly access a site's knowledge and tools directly.

That combination led me to add support for /.well-known/api-catalog to my site. A request to https://dri.es/.well-known/api-catalog currently returns:

{
  "linkset": [
    {
      "anchor": "https://dri.es/search/json",
      "service-desc": [
        {
          "href": "https://dri.es/openapi.json",
          "type": "application/openapi+json"
        }
      ]
    }
  ]
}

RFC 9727, an IETF Proposed Standard, defines /.well-known/api-catalog as a predictable location for discovering a site's public APIs.

The catalog is a small JSON document written in the Linkset format. It advertises my search endpoint and, in turn, links to an OpenAPI document that tells software how to use it.

The JSON endpoint at /search/json predates the catalog and powers my site's search. However, it was not documented or easy for software to discover. The catalog now makes it explicit.

The OpenAPI document at https://dri.es/openapi.json tells AI agents exactly how to call the endpoint and interpret the results. It removes the guesswork, reducing the time and tokens agents would otherwise spend figuring out how the API works.

In short, the API catalog announces that my search API exists, while the OpenAPI document explains how to use it. An agent can start with just my domain, check /.well-known/api-catalog, follow the link to the OpenAPI document, and learn how to search dri.es directly.

The feature has been live for a few months, but I am only now writing about it. In the meantime, I have logged every request to /.well-known/api-catalog and /openapi.json. The result so far: zero AI agents have used it.

I found the same problem when I analyzed llms.txt usage: the AI crawlers it was meant for never use it, so I never bothered implementing it.

Unlike llms.txt, the API catalog solves a problem I have, and I do not need to wait for industry adoption. I recently created an Agent Skill, a SKILL.md file that directs my agents to check the catalog and use my site's search API whenever they need information from dri.es.

My agents now search dri.es directly and find posts that Google misses. And if any AI agent adopts API catalog discovery, my site is ready.

22 Jul 2026 2:22pm GMT

Matthew Saunders links his board candidacy to a question now facing Drupal: how the Association can earn community trust through measurable listening, accessible participation, and public accountability.

22 Jul 2026 1:18pm GMT

I've stepped into the role of interim CEO of the Drupal Association for a limited period, expected to last six to twelve months. My job in that time is to help put the Association on a durable footing. As I undertake that task, I want to start by being direct about where we are and where I'd like to see us go next.

The Drupal stewardship the Association provides costs more every year. That includes running Drupal.org, providing the project infrastructure and putting on DrupalCon. For a long time our events paid for most of it. That stopped being enough several years ago, and we have been covering the gap from our reserves. That is not sustainable, and pretending otherwise would not serve anyone. The Drupal Association releases its financials and 990s every year. (The 2025 audit is expected to be released by the board soon.) An analysis of even just the last few years of publicly available financials tells this story plainly.

And that is only the part we actually fund. Some of the most critical work of all, like responding to security issues and managing releases, still runs entirely on donated volunteer time or corporate underwriting rather than from an ongoing operating budget.

The answer is not to ask more of the volunteers, agencies and contributors who have carried this project for two decades. The community's generosity is the heart of Drupal, and it always will be. The real challenge is that the large enterprises and governments that rely on Drupal every day have never had a clear way to understand or pay for the maintenance they use. So the cost has been shouldered by those most engaged in the community and, increasingly, the DA's cash reserves instead.

Changing that is my priority. Over the coming months I'll be focused on three things.

First, understanding the true cost of the work. I'm modernizing our financial reporting so we can see the full cost of every program and event, including the staff time each one requires, which our current reports don't fully communicate. That will give the board, the staff and the community real transparency into where money goes, which programs deliver the most value and where we're choosing to invest.

Second, funding each kind of work in the way that fits it. Not every program should look the same. Our utility and infrastructure services can move toward a usage-based model for the enterprises that depend on them. Our ecosystem advocacy needs focused support, because it strengthens Drupal and the Makers who build it. Our digital-public-good work, the parts that belong to everyone, can be sustained by philanthropy, contribution and as part of the utility and advocacy work. The aim is a regenerative model, where what these utility and advocacy services reinvest into all the ongoing costs that Drupal has as a thriving digital public good, a cycle that can sustain itself rather than a subsidy running down without constant new funding sources.

Third, collaborating with open source colleagues. These challenges aren't ours alone. I want to explore a co-creating shared standard for sustainable use certification with other open source projects facing the same challenges. Working together as a broad open source ecosystem, we can make supporting the open source software that organizations depend on an easy, standardized, normal and expected cost of doing business rather than ad hoc, voluntary and charitable, as it is now.

This matters beyond our own budget. Stewarded open source is no longer just a code repository. It is critical digital infrastructure. To keep it healthy, all of open source needs reliable ongoing funding from operating budgets as a standard line item. That is how we turn an extractive pattern into a regenerative one, and how Drupal and the community stays strong, open and community-governed for everyone who builds on it. Funding our ongoing work properly is how we protect that.

Those are my thoughts. I'm looking forward to hearing yours. Over the next several weeks I'll be inviting all parts of the Drupal ecosystem to share what you think, and I'll reflect back what I hear as we go. I intend to earn your trust through what we do over the next several months. Thank you for building this project, and for caring enough to hold the Association to a high standard.

One final note of transparency on my own situation: I own Palantir.net, a Drupal Certified Partner, and I take that conflict seriously. As of July 20, I have stepped back from day-to-day operations there. To prevent any interference and guarantee strictly arm's-length dealings, we have built a robust and legally-vetted conflict-of-interest framework directly into my interim contract.

21 Jul 2026 6:38pm GMT

Inserting boilerplate text into CKEditor in Drupal

Drupal

Drupal 11.x

Planet Drupal

jstrecker 2026.07.21 @ 14:38

Don't Repeat Yourself. It's a rule that we learn for writing code. And guess what: it applies just as well to writing content. If you copy and paste the same thing in lots of places, it's going to be a real hassle if you need to go back and change it later.

I'm building a Drupal website to share info about food pantries in my area. As I began entering data about pantries, I realized that I was copying and pasting text across nodes more than I wanted to.

21 Jul 2026 6:38pm GMT

Scott Falconer links his board candidacy to a question now facing Drupal: how the project can grow without allowing AI adoption, enterprise influence, or vendor dependence to weaken community control.

21 Jul 2026 2:56pm GMT

It feels like the right moment to share something I have been looking forward to announcing. The holidays are just beginning, and the Enterprise AI Summit (28 September, Rotterdam) is coming together.

We have been reviewing sessions over the past weeks, and three cases in particular stood out, each solving real problems for real organisations.

Here is a first look at three of the sessions we are excited to share.

THE EUROPEAN PERSONNEL SELECTION OFFICE: CANDIDATE SUPPORT IN 24 LANGUAGES

EPSO is the body responsible for selecting staff across EU institutions, and every year, thousands of candidates ask questions in all 24 official EU languages. With a small team, an enormous volume of work, and zero tolerance for wrong answers, EPSO needed a solution that could keep up.

Antonella Picarella will show us what that solution looks like: an AI-powered support tool on Drupal that now handles 93% of incoming questions automatically, across all 24 languages, with no hallucinations detected on manual checking.

Read more about this session: https://summit.enterprisedrupal.eu/epso.html

THE AMERICAN DIABETES ASSOCIATION: FROM PILOT TO PRODUCTION

When the content is about people's health, accuracy is not optional, and neither is speed.

Hemant Gupta will walk through how the American Diabetes Association moved AI from pilot to daily use across their Drupal platform: editorial assistance, bulk alt text generation, in-editor AI tools, and Word-to-Drupal content pipelines. Editorial teams are using it, the results are documented, and so is the process that got them there.

Read more about this session: https://summit.enterprisedrupal.eu/ada.html

WORLD CANCER DAY: MODERATION AT SCALE, WITH A HUMAN HEART

On World Cancer Day, hundreds of thousands of personal cancer stories are shared in a single day, reaching 500,000 requests per hour with just a small team behind it.

Charles Andrew Revkin and Diego Costa will share how the World Cancer Day team uses Drupal and AI to scale a deeply personal campaign without losing the human touch.

Read more about this session: https://summit.enterprisedrupal.eu/wcd.html

JOIN US ON 28 SEPTEMBER IN ROTTERDAM

The full schedule is taking shape. If you want to see what AI actually looks like when it is deployed, trusted, and working, this is where you will find it.

More information and tickets: https://summit.enterprisedrupal.eu

21 Jul 2026 1:36pm GMT

Migrating custom Drupal modules? Learn what breaks, how to audit the damage, and when to port vs. rebuild, with tools that automate the fix.

21 Jul 2026 10:11am GMT

We take over projects from other agencies and see them through to completion - even if they are stuck, have errors, or require urgent intervention.

21 Jul 2026 7:25am GMT

In recent months, a number of Acquia customers have independently made the same strategic decision: to migrate hundreds of websites from WordPress and other platforms to Drupal.

Some of these sites will move to Acquia Cloud, while others will move to Acquia Source. Drupal CMS played an important role in these decisions by making Drupal more approachable for marketers and site builders.

Why are different organizations making the same choice? One key reason is the cost of CMS fragmentation.

A few months ago, a CMO told me that her team had purchased a new digital asset management system (DAM). The estimate to connect it to the organization's websites came back at nearly $100,000 and three months of work.

Why so much? The organization ran three CMS platforms: Drupal, WordPress, and Contentful. The DAM had to be integrated with all three. That meant not only three integrations, but also three sets of expertise, three rollout plans, and three ongoing maintenance responsibilities. One new capability had become three separate projects.

Organizations are under pressure to move faster and reduce costs. CMS fragmentation makes both harder by creating recurring duplication. Integrations, security practices, governance policies, design systems, and technical expertise must all be developed and maintained across multiple platforms.

Some of this duplication can be reduced by standardizing hosting and portfolio governance across multiple CMS platforms. That is valuable, but it addresses only one layer of the problem. Each CMS still has its own extension model, editorial experience, security considerations, and required expertise.

This fragmentation usually happens for understandable reasons. Teams often make technology decisions independently, and different sites can have genuinely different requirements.

A marketing team may need to launch a campaign site in days without involving developers, making SaaS solutions attractive. A team responsible for a high-traffic enterprise application with custom integrations may need the flexibility and control of an Open Source solution running in a PaaS environment.

Each decision can make sense for the individual project while creating significant duplication across the organization.

More than 15 years ago, I argued in a post about Acquia's product strategy that organizations should standardize on a common CMS while choosing the right operating model for each site.

Today, the case is even stronger. Websites depend on more integrations, digital experiences are more complex, and AI is becoming another shared capability that organizations need to deploy across their portfolios. With multiple CMS platforms, every new capability becomes harder and more expensive to deploy safely.

Standardizing on a single CMS lets teams reuse more of their design systems, security practices, integrations, and expertise across sites. Marketers get a more consistent way to create and manage content, while developers spend less time implementing the same capabilities on unrelated platforms.

But standardizing on Drupal does not mean forcing every site into the same architecture or operating model. Organizations can share a common CMS foundation while choosing a different balance of convenience and control for each site.

That is where Acquia Source and Acquia Cloud fit together.

Acquia Source provides the SaaS operating model. It is designed for teams that value speed and simplicity. Acquia manages the underlying platform, while marketers and site builders customize experiences through the user interface, reusable components, and supported integrations. Developers can extend sites through custom components, APIs, webhooks, and other supported tools without managing the Drupal codebase or installing arbitrary modules.

Acquia Cloud provides the PaaS operating model. It is designed for sites that need deeper customization and more developer control. Teams can build custom Drupal modules, use contributed modules, manage code through Git, run CI/CD pipelines, and integrate Drupal more deeply with other systems.

Both are built on Drupal. This gives organizations a shared foundation for skills, content practices, design systems, security, and integrations, while allowing each site to choose the right balance of speed, simplicity, flexibility, and control.

A site can begin on Acquia Source when speed and simplicity matter most. If its requirements later grow to include custom modules, deeper integrations, or more developer control, the organization can export its source code, database, and files and move to Acquia Cloud or another Drupal environment without adopting a different CMS.

I have been calling this "Open SaaS": the convenience of SaaS combined with the ownership and portability of Open Source. Organizations can choose a different operating model without leaving Drupal or surrendering control of their sites.

When organizations standardize this way, the economics change dramatically. We have helped some customers save tens of millions of dollars each year by reusing shared capabilities instead of rebuilding them for different platforms.

The goal is not to operate every website in the same way. A campaign site and a mission-critical application require different levels of speed, flexibility, and control, but they do not need unrelated CMS platforms.

The goal is to create operating leverage across an organization's digital portfolio. Each site can use the operating model that fits its needs, while teams reuse investments in content, design, integrations, security, and expertise.

Then, when the organization adds a DAM, a personalization engine, an analytics platform, or an AI capability, teams can build on shared work rather than start over for each CMS. The result is faster execution, greater returns on digital investments, lower costs, and less risk.

One CMS foundation with multiple operating models makes that possible.

20 Jul 2026 10:10pm GMT

In recent months, a number of Acquia customers have independently made the same strategic decision: to migrate hundreds of websites from WordPress and other platforms to Drupal.

Some of these sites will move to Acquia Cloud, our Drupal PaaS, while others will move to Acquia Source, our Drupal SaaS. Drupal CMS played an important role in these decisions by making Drupal more approachable to marketers and site builders.

Why are different organizations making the same choice? One key reason is the cost of CMS fragmentation.

A few months ago, a CMO told me that her team had purchased a new digital asset management system (DAM). The estimate to connect it to the organization's websites came back at nearly $100,000 and three months of work.

Why so much? The organization ran three CMS platforms: Drupal, WordPress, and Contentful. The DAM had to be integrated with all three. That meant not only three integrations, but also three sets of expertise, three rollout plans, and three ongoing maintenance responsibilities. One new capability had become three separate projects.

Organizations are under pressure to move faster and reduce costs. CMS fragmentation creates a recurring tax through duplicated integrations, security practices, governance policies, infrastructure, technical expertise, and more. It also fragments attention and makes it harder to share improvements across teams and websites.

Organizations pay that tax every day through higher operating costs and slower execution, not only when they introduce new capabilities. When it consistently slows their ability to improve digital experiences, it can become a competitive disadvantage.