Last week’s AI releases put a familiar question back into view: who controls the technology that digital systems depend on? On 10 August 2026, Meta released Muse Glimmer, a 30-billion-parameter model optimised for local agent workflows, with its weights under the Apache 2.0 licence. Mark Zuckerberg, Meta founder and CEO, argued in an essay published the same day that superintelligence should be broadly distributed rather than concentrated in a small number of hands. On 14 August, Alibaba Group’s Qwen team released Qwen3.8-27B, another downloadable model with weights under Apache 2.0.

There is a catch in calling all of this “open AI.” Downloadable weights under an open-source licence do not by themselves establish that an entire AI system is open source. Under the Open Source Initiative’s Open Source AI Definition, the preferred form for modification also requires sufficiently detailed information about the data used to train the system, the complete source code used to train and run it, and the model parameters. Even so, downloadable weights can expand practical deployment choices by allowing organisations to run and adapt models on infrastructure they control rather than relying solely on a vendor-hosted service.

Drupal is relevant here not because a content management system and an AI model are equivalent, but because the project has spent 25 years working within open-source principles. Drupal marked its 25th anniversary on 15 January 2026, and the Drupal Association’s Open Web Manifesto describes the open web through principles including freedom, decentralisation, participation, choice, privacy and security. The comparison should remain limited: a content management system, model weights, training data, source code and computing infrastructure are different layers with different licensing and governance problems. The shared principle is practical: leave organisations room to choose infrastructure, modify systems, and avoid unnecessary dependence on a single provider.

The larger question is whether those principles are becoming easier to recognise beyond software-development communities. AI is forcing organisations to consider what happens when a technology provider changes terms, raises prices, closes a service or simply stops fitting their needs. Drupal cannot answer AI’s licensing, computing, data-governance or portability questions, and open source does not guarantee independence. What Drupal can offer is a 25-year example of why choice, modification and exit matter when digital infrastructure becomes important enough to depend on.

As AI becomes another dependency inside websites and digital services, that old open-web argument has a new place to land. The question is no longer only what an AI model can do, but how much control remains with the people and organisations that build on it.

Follow The DropTimes on LinkedIn, X, Bluesky, and Facebook, or join #thedroptimes on Drupal Slack.

This issue of Editor’s Pick was written and curated by Kazima Abbas.

If AI can generate an application from a description, is software still worth anything?

I have lived with a version of that question longer than most.

I released Drupal for free more than twenty-five years ago, and later co-founded Acquia, which has grown into a large enterprise software company built around Drupal.

Granted, Drupal is free in a different way than AI-generated applications are free, but I'm not sure that changes the basic question of how to build a successful business around either one.

Open Source made code abundant by giving people broad rights to use, modify, and redistribute it. AI is lowering the cost of producing code. One lets you copy the software; the other makes it cheaper to recreate software.

Free code changes what customers pay for

Because anyone could use Drupal for free, Acquia could never build a durable business around access to the code. From the start, we had to make money another way.

We built that business around helping enterprises build, run, and manage Drupal applications throughout their lifecycle. That includes hosting, but goes well beyond it: the tools and services needed to develop, deploy, secure, scale, monitor, and improve applications in production.

Proprietary SaaS typically bundles access to the application with the hosting and operations required to run it. With Open Source, organizations can run the software themselves or choose who hosts and operates it.

As AI makes applications cheaper to recreate, the traditional SaaS bundle of software and operations comes under pressure. Customers may become less willing to pay for access to application functionality without becoming any less willing to pay to run and manage applications in production. For Open Source businesses those economics are not new.

Dependability becomes the product

Software can be free, or nearly free, without becoming cheap to depend on. The more people and organizations depend on a system, the more of its value comes from operating it securely, reliably, and at scale.

Once people depend on an application, the cost of its failure has little to do with how much it cost to build. An application that costs $1,000 to build can still cause a $10 million failure.

As AI makes enterprise applications easier to create, adapt, and integrate, they still have to be deployed, secured, scaled, monitored, and run reliably over time. As software cost comes down, dependability becomes a differentiator.

Linux is abundant; dependable cloud infrastructure is a service worth paying for. Drupal is abundant; dependable digital experience infrastructure is a service worth paying for.

Acquia has lived with those economics for nearly 20 years. Drupal made the code abundant, so we built our business around helping organizations build, run, and improve what they created with it. As AI makes code cheaper to generate, that business model may start to look a lot less unusual.

Either way, more software companies will have to answer the same question: if the code is abundant, what are customers really paying you for?

Drupal 11: Migrating From Jadu Into LocalGov Drupal: Part 2

This is the second article in a series of articles looking at migrating from Jadu into a LocalGov Drupal (LGD) site for Central Bedfordshire. In the first article we looked at the Jadu API and setting things up so that we could make calls to the API and parse the XML data using the migration systems available.

In the last article I mentioned something about the Jadu API that caused me a lot of headaches. The API contains most of the information for a page, but critically, the Jadu API contains no information about the path of a page. There is basically no way to get the URL of a page in Jadu from the XML API.

I'm quire sure that this makes creating anything useful in the API a real pain since referring back to the site needs to be done with manually placed links, but it's clearly like this by design. I couldn't find any documentation on why it is like this, but it almost feels like vendor lock-in. Please correct me if I'm wrong here.

If you migrate a page from one system to another then it is highly important that you maintain the URL structure of the site. If you change the URL of a page then you need to add in a step that adds a redirect from the old system to the new so that all of your search engine results, the existing links from other sites, and any user bookmarks that have been created work correctly. This is critical to get right for a public facing council site like this.

Since I was migrating into a LGD site, it made sense to use the Drupal path auto system and LGD path management plugins to manage the paths on the Drupal site. We therefore needed to know the existing Jadu URLs so that we could create these redirects.

To get the URLs during the migration caused quite a bit of experimentation, but I did solve the issue with a solution that had a high success rate.

philipnorton42 Sun, 08/16/2026 - 19:06

Webform is the most popular module for building forms in Drupal. You can use it for a simple contact form or for a long form with conditional logic, file uploads, and email alerts. Either way, you build the whole thing from the admin interface without writing code.

In the video above, you will learn how to build a form with Webform in Drupal CMS. You will create a Customer form, add conditional logic, send a confirmation email, split the form into pages, view submissions, and embed the form on a Drupal Canvas page.

Watching someone not need a developer Imagen A man who runs an insurance agency showed me software he built himself, after paying a development company for months and getting nothing. I sat there listing everything that could go wrong with it, and then realized nobody had asked me to. If building is no longer the hard part, I don't know what the rest of us still bring, and I'd rather work that out in the open than pretend I already have. Imagen Carlos Ospina · Technical Account Manager / Drupal Advisor Sat, 08/15/2026 - 19:48 what is next in the AI era Drupal Drupal Planet AI vibe coding no-code agencies freelancing developer career Add new comment

Drupal can be the best SEO platform on the market or an invisibility cloak — the difference is configuration. The module stack, the architecture decisions, Core Web Vitals, and the crawl traps, from a team that does Drupal engineering and SEO under one roof.

Drupal on $5 shared hosting is how good sites die slowly. Here's what Drupal actually requires, what each hosting tier really costs per month, and the caching stack that makes the same site feel five times faster.

Acquia is excellent and expensive — and it's not the only way to run serious Drupal. Here's a working comparison of Acquia, Pantheon, Platform.sh, and the managed-hosting-plus-agency model, with real prices and an honest account of who should pick what.

Drupal's enterprise security reputation is earned — but it only protects sites whose teams actually patch. Here's how the advisory process works, what Drupalgeddon taught everyone, and the hardening checklist we apply to every site we support.

Higher education is Drupal's biggest fan base — and its biggest source of cautionary tales. Multisite sprawl, departmental politics, and 400 unmaintained microsites: here's how universities make Drupal work, and what it costs.

Government teams don't pick Drupal because it's trendy — they pick it because of the security process, accessibility tooling, and data ownership. Here's the honest case for it, the procurement traps, and what a government Drupal build really costs.

Thirty Years of Palantir demet Fri, 08/14/2026 - 11:42

What three decades has taught us about what lasts

Thirty years ago last month, between my sophomore and junior years of college, I started a company called Palantir Internet Services, later known as Palantir.net. I had been building personal websites for nearly two years at that point and was captivated by this revolutionary new medium that allowed anyone, anywhere, to publish something that anyone else in the world could read.

While the internet touches nearly every part of our lives today, in the summer of 1996 it was still seen by many as a novelty. There were only about 250,000 websites on the web, and while Amazon and eBay had already launched, Google, Facebook, and Wikipedia were still years away.

That fall, I met Tiffany Farriss, and together we built Palantir into a company that developed websites for clients of all shapes and sizes. As college students, we were featured in a news story on CNN and profiled in a front-page Chicago Sun-Times article. Our first paying clients were colleges and universities, and then for several years we partnered with Chicago design firms who were making the transition from print to the web.

During that time, we built and deployed several versions of our own in-house content management platform, eventually deprecating it in 2007 in favor of the newly released Drupal 5. Putting our energy into contributing to an open source project not only brought us new business opportunities but also introduced us to a community we are proud to still be part of today.

Along the way we grew into a full-service digital consultancy, bringing our strategy, design, build, and support services to public sector agencies, higher education institutions, nonprofits, and healthcare organizations whose needs are genuinely complex and whose work has a profound impact on others.

Only a handful of companies in our industry have been around as long as we have. Over the years, we've watched it go through several transformations: the dot-com bubble of the late 1990s, the rise of "Web 2.0" and social media in the mid-2000s, and the emergence of smartphones and the mobile web in the late 2000s.

Today, we are in the middle of one of the web's biggest transformations yet, as generative AI has fundamentally disrupted the traditional ways that online content is both created and consumed. The business models that built the web are no longer sufficient for an environment increasingly dominated by bot traffic and bot-created content. As more money has flowed into generative AI, we've seen less of it invested in other forms of online infrastructure, and that shift has affected us and many others in our industry.

At the same time, these tools have already demonstrated their usefulness for automating manual and labor-intensive work, from code review to content audits. We believe that when used thoughtfully, generative AI can improve the online experience and make vital information more accessible to more people.

And that's why, in an era of slop and enshittification, we feel it's more important than ever to recommit to our mission and vision. Palantir exists to help others discover, create, and share knowledge, and to strengthen humanity through the work that we do and the way that we do it.

We may not be able to predict the future, but 30 years of experience gives us a lot of perspective on where things have been and where they might go next. Technology keeps changing, but it's people who decide where to put their time and attention. That's the choice we've made so far, and it's the one we will continue to make.

I know this blog post's title implies losing my (programming) skills, and I will gladly address my feelings about how agentic coding has caused my problem-solving and coding to atrophy from lack of use. The main focus of this post is about losing, specifically deleting, my overly verbose and complicated skills and AGENTS.md files.

I was inspired to write this post after recently switching to the latest OpenAI GPT 5.6 models with Codex and OpenCode as my harnesses for Drupal development. In a previous post, I discussed that one approach to working with AI is to accept that every beginning and end of a session is like onboarding and offboarding a new team member. To help onboard an AI, we need to provide documentation, guidance, and workflows, typically implemented as AGENTS.md and agent skills.

AGENTS.md and agent skills are instructions added to your context to nudge the AI in the right direction. After switching to a more intelligent frontier model, I began to suspect I needed to rethink my assumptions about what the AI was capable of and how much initial context was required for the AI to succeed at a task. So I removed all my assumptions, deleted my AGENTS.md and skills directory, and started fresh.

Losing my agent skills

I had a hunch that some of my installed agent skills were costing me extra tokens and not adding enough value when I read a Reddit thread about "are you guys still using the superpowers skill?" Superpowers nudges coding agents to adopt a pragmatic workflow that includes brainstorming, specs, plans, tests, and review....Read More

Your Agent's Performance Review is Your Performance Review kdollof Fri, 08/14/2026 - 10:07

At Ai4 in Las Vegas, the CIO of the NATO Support and Procurement Agency told a room of executives that if you can't reconstruct what your agents were doing, you have no reason to believe anything they produced. No traces, no trust. Set the red lines first, let the agents work inside them, and check afterward what they actually did.

 95% isn’t 95%

An agent that's right 95% of the time at every step is right about 36% of the time across a twenty-step process. Not 95%. Thirty-six. Krishna Gade, who runs Fiddler, put an even starker number on it: 90% a step, a hundred-step process lands a rounding error from zero.

That number usually gets deployed as an argument about model reliability. I read it as an argument about controls. If accuracy decays that badly by step twenty, the trouble started around step three and nobody was watching.

Amazon's session on brittle agents supplied the reason. Difficulty is a property of the procedure, not the agent. The same models, run against different standard operating procedures, scoredclose to 100% on some and 57% on others.Moving to a better model doesn't fix a problem that lives in the procedure either. The same team found that handing an agent too many tools collapses its accuracy rather than just slowing it down.

That matches what I see in practice. The worst agent failure I've dealt with didn't look like a failure at all. The agent ran, produced output, and kept going past what I'd asked for into adjacent work nobody wanted. Nothing broke. No error surfaced. I got a clean deliverable answering a question I never asked, and the cause was an agent file that didn't say clearly enough where the mission ended. Write the guardrails badly and you get confident work product outside the scope of the request.

Traces are the precondition

Coronado's point lands harder than it first sounds. Traces are the precondition for every other control here, because a procedure you can't see is a procedure you can't fix. At Phase2, when we put an agent into a workflow, we can follow it end to end.

Another speaker, a VP of AI and data science, sharpened the point: validate the whole trajectory, not just the final response. Her escalation model tiered the response to severity, with minor signals logged for scheduled review, moderate signals assigned to an owner for investigation, and severe signals triggering a pause. Her framing of the kill switch is the part I'd steal. Shutting everything down is rarely the right move. The useful capability is isolation, cutting off one tool, one action, or one segment of users while the rest keeps running.

The reviewer shouldn't always be you

The NATO CIO's architecture included a role that most teams skip. Alongside the agents that search, extract, and synthesize, he ran skeptic agents and evaluators whose job was to argue with the work.

I run the same pattern, and it's the single practice I'd move to the top of anyone's list. When agent work matters, there's an adversarial reviewer checking status and progress at each turn. That reviewer is why the twenty-step math never gets a chance to play out. Errors get caught at step three.

Gade's sharper point was about how little of this anyone actually inspects. Teams sample their trace logs at 10%, sometimes 1%, and then describe themselves as monitored. A 1% review rate leaves 99% of the exposure unexamined. He also argued that the cost of evaluation should run somewhere around 10 to 20% of what you spend deploying an agent. That's a budget line, and he meant it as one.

I don't have a universal review rate to offer, and I'm suspicious of anyone who does. What I do is front-load. The first five or ten runs of a new agent get read in detail, and whatever I learn goes back into the prompting before the agent goes anywhere near production work. After that, depending on the scope and the depth of the project, it might be one turn in five or one turn in ten. I read the output myself again toward the end of a cycle, looking for drift. What I never do is hand an agent a large workflow and let it execute the whole thing unattended.

Where the employee comparison holds, and where it stops

One piece of advice for anyone deploying their first agent:treat it like an entry-level employee. Be specific about the ask. Give it the ground rules. Show it concrete examples of what good looks like and what a wrong answer looks like. Almost everything people find surprising about agent behavior is explained by having skipped that step.

The comparison stops at correction. A person you coach on Monday shows up Tuesday having absorbed it. An agent doesn't. The fix has to be written down somewhere the agent reads (the prompt,  agent file or skill definition) or the same failure arrives again on the next run wearing the same confident tone. You're not managing something that learns from you, you're maintaining the procedure it executes.

Whose name is on it

Phase2 Principal AI Technologist Chris Johnson’s panel on code quality got to the part that most governance conversations avoid: an agent's recommendation should be assigned to a specific owner, and you're accountable for what the code does regardless of how it got generated. One panelist described a customer who talked an agent into going beyond its scope and making offers it had no authority to make.

Here's where I land. An agent's performance is attributable to whoever owns and runs it. That means agent performance management already sits inside somebody's performance review, whether or not anyone has said so out loud. The agent doesn't get a rating. The person who deployed it does.

The stakes aren't theoretical. EY's Responsible AI Pulse survey found that 99% of the large enterprises it surveyed had already taken a financial hit from AI-related risk, with average losses conservatively put at $4.4 million. In the regulated industries where a lot of our work sits, bad output carries financial, reputational, and legal exposure at the same time. That's why I don't believe in running these things without human oversight, and why the review rate question deserves a real answer instead of a policy statement.

The practice I keep coming back to started with a specific annoyance. Across projects, I kept catching numbers that were subtly wrong, usually when data came in through an MCP connection or out of a large Google Analytics or Search Console export. So I built a skill that makes the agent construct a databank first. Every statistic used anywhere downstream has to verify against that file. Nothing gets asserted from the model's memory of what it read three steps ago. It's my own method rather than an agency standard, though it's spreading internally. It works for a reason that has nothing to do with the agent being smart. It works because the check now lives inside the procedure.

Coronado had a better line for this than I do. “Put your agents in the basement and keep the job upstairs.”

Build as many as you want down there. The performance review still has one name on it.
 

Publication Date Mon, 08/17/2026 - 10:07 Joe Thomas AI Content Architect Featured Blog Post? No Has this blog post been deprecated? No Summary Agents fail confidently and quietly. Notes from Ai4 on traces, adversarial reviewers, review rates, and why agent output lands on its owner's review. Topic Artificial Intelligence Events Blogimage_081726.png Promo Image

Questions, story leads, and feedback on future Drupal coverage are on the agenda for contributors and community members joining the monthly meeting.

Members still weighing their choice can read The DropTimes' interviews with seven candidates to compare their priorities before casting a ballot.

Today we are talking about Open Source sustainability, becoming your own content creation machine, and how drupal influenced some of that with guest Jeff Geerling. We'll also cover AI Metering as our module of the week.

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

Topics

• Jeff's Timekeeping Icebreaker
• Jeff's Drupal Origin Story
• From Drupal to Hardware Tinkering
• Staying Motivated on YouTube
• What Conferences Are Really About
• DrupalCon Memories and Community
• Why Jeff Moved to Hugo
• PSA Tornado Warning Detour
• Keeping Up with Drupal CMS
• PHP Perception Shift
• Fast Drupal Setup
• COVID Streaming Boom
• Picking Video Projects
• Decommissioning Builds
• YouTube Algorithm Risk
• Vintage Time Server
• Creator Starter Tips
• Supporting Maintainers
• Books and Crohns
• Local Control Trends
• AI Workflow Boundaries
• Timing Obsession
• Kind Drupal Culture

Guests

Jeff Geerling - jeffgeerling.com geerlingguy

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan Mike Anello - drupaleasy.com ultimike JD Flynn - dorficus

MOTW Correspondent

Mike Anello - drupaleasy.com ultimike

• Brief description:
  • AI Metering module - helps keep track of your users' AI token usage on the site. Includes cost estimation, token limits, and local LLM fallback options.
• Module name/project name:
  • AI Metering
• Brief history
  • How old: created in June 1 2026 by Jérôme Tchania (codeitwisely)
  • Versions available: 1.0.1
• Maintainership
  • Actively maintained - yes
  • Co-maintained by Carlos Ospina (camoa)
  • Security coverage - yes
  • Test coverage - yes
  • Documentation - yes
  • Number of open issues: 9 open issues, 4 of which are bugs against the current branch
• Usage stats:
  • Sites: 78
• Module features and usage
  • Obtains token costs for all modules from LiteLLM
  • Can be configured to send email when the token limit is being approached.
  • Per user and per role reports.
  • LLM fallback to Ollama

Open-source software still depends on infrastructure and human maintenance that carry real costs. Farriss argues that institutions should plan for those costs before contracts are awarded.

The most dangerous moment in a Drupal-to-headless migration is the one where everything looks fine. The content exported. The article titles are all there. Then an editor opens a launch-ready page and half the images are missing, the "related articles" block is pointing at a press release from 2019, and one product's category is now, somehow, a staff bio. Nothing errored. Nothing turned red. The references just quietly stopped meaning what they used to mean. That is the trap, and it lives in taxonomy, media, and entity references specifically because Drupal stitches your content together with numbers instead of names. Drupal is a house where everything is labeled by drawer, not by name Picture a house where nobody wrote what anything is. Instead, every object has a little tag: see drawer 47 . The cookbook says "pairs with drawer 112." The remote says "belongs to shelf 9." It works…

Read the rest at Replatform Radar

Traditional content staging servers have had their day. At DrupalCon Chicago 2026, Tag1's Peta Hoyes and Ray Stuart (presenting for Fabian Franz) made that case and showed exactly what replaces them. Their session, Workspaces is Revolutionizing Drupal Core: Unlock True Enterprise Content Management in Drupal, covered the core architecture, live demos, and a Q&A with the room.

We have expanded and organized the questions from that session into a standalone reference on how Workspaces works for enterprise content teams.

Want the full session? Watch the full recording. > Getting Started: What Workspaces Is and How to Turn It On Q. What is Workspaces?

A. Workspaces is enterprise content staging built into Drupal core. It lets a privileged user preview a large set of changes exactly as a site visitor will see them, then publish the whole set at the click of a button. Instead of maintaining a separate staging site, each workspace is an isolated set of staged changes that layers on top of your live site. You stage, collaborate, and publish without touching production until you are ready.

Workspaces has been stable in Drupal core since version 10.3 (June 2024) and ships with every Drupal 11 installation. It is no longer experimental. It is core infrastructure, and it is free and open source.

Q. How do you get started?

A. Core Workspaces turns on with a single command that most Drupal teams already know:

drush en workspaces

For enterprise use, you also want Workspaces Extra (WSE), which installs the same way most contributed modules do:

composer require drupal/wse

That is a low barrier to entry for enterprise capability out of the box.

Q. What does WSE (Workspaces Extra) add on top of core?

A. If core workspaces are content branches, WSE is closer to the full deployment pipeline you already have for code. WSE adds scheduled publishing, preview links for external stakeholders, rollback of an entire published workspace, access control, menu staging, task monitoring, and the ability to move content between workspaces when needed. WSE Config stages configuration changes alongside content, and WSE Theme lets you preview an entirely different theme staged in a workspace.

Q. I already know git. How should I think about Workspaces?

A. If you understand feature branches, you already understand Workspaces. The mental model maps almost exactly:

• Your Drupal site is the repository.
• A workspace is a branch.
• Live is the main branch.
• Saving content is a commit.
• Previewing a workspace is your working copy.
• Publishing is a merge.

The workflow is the same one developers take for granted: create a branch for your campaign, make your changes, preview the complete state, get approval, then publish. Content teams simply have not had this tooling until now. As the session put it, if your dev team would not ship code without branches, why would your content team ship content without workspaces?

The Core Problem: Why Enterprise Teams Still Struggle with Content Management Q. What do we mean by true enterprise content management?

A. For a CMS to truly meet enterprise requirements, it needs to provide tools for both creating content and managing the end-to-end governance of that content. Content governance covers everything from procedures to technology that a complex organization needs to make sure its content meets its standards for brand, legal compliance, and accessibility. There can be a lot of content stakeholders with diverse concerns. Strong content governance is what stops all of that from devolving into chaos.

Drupal has been working toward this in core for a long time: granular user roles, workflows, content moderation in Drupal 8. With Workspaces in core, Drupal has closed another major governance gap. Content staging and review in the CMS.

Q. Why is content staging and review in context more important than ever?

Modern enterprise websites are composable. Content comes from multiple systems, dynamically laid out in the CMS, with edits and updates automatically propagating across the site. The governance of large-scale changes (adding new products, migrating a department, launching a campaign) needs to happen in the context of the overall site, with all the pieces of the puzzle present. Until Workspaces, Drupal hasn't had a clean solution for that.

Q. What about the impact on the people who need to manage content?

A. External staging sites mean content managers work in two or more places. And what most content managers do not love is remembering which autogenerated subdomain from a git branch ID is the one they are supposed to be updating. Workspaces keeps everything inside a single Drupal installation.

The Reality of Modern Drupal: Complexity Behind the Scenes Q. What happens when you need to stage more than one set of updates at a time?

A. More staging usually means more problems. With traditional staging servers, each parallel workstream typically means another environment, another subdomain, another database sync, and another deployment pipeline to track. Workspaces eliminates that. Each workspace is isolated, teams can work in parallel, and there is no artificial limit on concurrent campaigns or content initiatives. Tag1 has tested workspaces with more than a thousand entities changed in a single workspace.

Q. If changes are happening on live while I work in a workspace, can I pull those changes in?

A. Think of a workspace as a shallow copy. Only the changes you explicitly make are tracked in the workspace. If someone modifies different content directly on live, those changes are not in your workspace and will not be overridden when you publish. Your workspace only ever contains what you put there. The one edge case is the same entity being modified in both places, which Workspaces intentionally prevents (see the collaboration section below).

Governance and Control: Who Sees What, and When? Q. How do you deal with permissions for users who should not see work happening in workspaces?

A. Each workspace is isolated with granular permissions. Design, content, legal, and translation teams can work in parallel workspaces without visibility into each other's work unless it is deliberately shared.

Q. Can previews be shared with external reviewers, including anonymous users, and how does that work with permissions?

A. Yes. WSE preview links handle this. Create a dedicated role with preview access, assign it to the reviewer, and share the link. The reviewer does not need a full Drupal account, so this works for anonymous users too. The workflow is straightforward: prepare the role, generate the preview link, share it.

Infrastructure and Performance: Will This Break What Already Works? Q. If I have a CDN or Varnish cache, will Workspaces need anything extra?

A. No. There are no changes to your anonymous content delivery. The active workspace is live 100 percent of the time for anonymous users, so the workspace system is invisible to them. The same caching setup that works for your anonymous visitors keeps working. The only thing to confirm is that your configuration is appropriate for the content editors using the site, which is standard practice.

Q. How about performance?

A. This is the most important architectural property of Workspaces. When the active workspace is live, which it is 100 percent of the time for anonymous users, the workspace system is invisible, and your production site performs exactly as if Workspaces did not exist. That has been true since the architecture was first built in the Content Preview System (CPS) in 2014, and it is why Workspaces has run on some of the highest-traffic sites in the world for over a decade. Inside a workspace there is some overhead, but that is editorial traffic, a tiny fraction of your total load. Editors get a full-site preview, and visitors get full production speed.

Content Safety and Security Q. If public files are uploaded inside a workspace, are they accessible to users who know the URL?

A. Yes. File entities in Drupal aren't revisionable, so the Workspaces module can't scope a file to a workspace the way it scopes nodes. The moment a file is uploaded to public://, it's written to the default live storage in sites/default/files and served directly by the web server, with no Drupal access check in the request path.

So even when the node or media entity that references the file lives only in an unpublished workspace, the file itself is already on disk and reachable at its direct URL by anyone who has or guesses it. Publishing state doesn't gate it. Public means public, and only the obscurity of the filename keeps it from being found.

If the file needs to stay private until publish, use a private:// file field, which routes downloads through Drupal so access checks apply, or a module like File Unpublish, which keeps public files of unpublished media entities inaccessible until the entity is published.

Configuration Management: The Gray Area Teams Care About Q. How does WSE Config interact with Drupal's configuration export/import system?

A. Once a workspace is published, whatever is live is what you would export, the same as always. For sites that manage configuration directly on the site rather than exporting it to code, this is largely a non-issue. For sites with strict configuration management workflows, WSE Config is still maturing (the session described it as almost production ready), so test it in a non-production environment before you rely on it in production.

Collaboration and Conflict Management Q. What happens when two people edit the same content in different workspaces?

A. They cannot, and that is deliberate. Once an entity is modified in a workspace, it is tracked there, and another editor cannot modify it in a different workspace. This is a feature, not a limitation. Automatic merging of structured content fields, entity references, and media relationships leads to data corruption, and every system that has attempted it has run into fundamental issues.

Workspaces takes the same approach as a well-run development team: coordinate through communication. Shared workspaces let teams collaborate, content ownership keeps responsibilities clear, and WSE lets you move content between workspaces when needed. If content is locked, discarding the change frees it again. The absence of automatic merging is a safety guarantee: your workspace will never contain content you did not put there.

Q. How does Workspaces handle deleted content?

A. Deleting content in a workspace is a special case, because the content needs to disappear from your workspace preview while staying visible on the live site until you publish. Workspaces solves this with the Trash module. Within the workspace, deleted content drops out of listings, views, and search results, but on the live site it remains visible until publish. Content deleted in a workspace stays recoverable until you publish, and this integration also removes an older constraint so that any entity type can participate in workspaces, not just those with a publication status.

Content Moderation and Workflows Q. How does Workspaces work with content moderation and Drupal's workflows?

A. Workspaces integrates with Drupal's core Workflows module. You can move an entire workspace through workflow states such as draft, review, approved, and published, so the whole collection of changes moves through the approval process as a unit. Your legal team reviews the complete workspace, your content manager approves the entire set, and when it reaches the publish state the whole workspace deploys atomically. The Content Moderation and Workspaces integration is nearly complete, with one remaining issue to resolve in core, and the simplified content workflow initiative will make the two work together for more complex scenarios where different entities need different approval paths.

Ecosystem and Future Considerations Q. Does it work with Canvas?

A. Yes. Workspaces is compatible with Canvas. The implementation differs, because Workspaces aligns with the Layout Builder approach rather than Canvas's own, but the two work together.

Q. Why is Workspaces a good fit for AI content generation?

A. Workspaces gives AI content generation the boundary it needs. AI content tools are scaling quickly, and Drupal's AI module integrates dozens of providers with automators that can bulk-populate fields, generate summaries, and translate content. But AI is non-deterministic: it can hallucinate and produce errors. Workspaces provides the natural safety architecture. Think of a workspace like a pure function: everything inside is safe and reversible with no side effects. An AI agent can generate content, edit fields, and populate entire sections inside a workspace, and nothing touches live until a human reviews the changes and publishes. The workspace diff makes that review straightforward. The result is governed automation, where AI helps and humans stay in control.

Q. What is on the roadmap?

A. The architecture is sound, and the remaining work is about closing the last gaps and proving the system in the wild. Content Moderation and Workspaces are nearly integrated, with one issue left in core. WSE Config, which stages configuration changes alongside content, is almost production ready. WSE Theme lets you preview an entirely different theme staged in a workspace. What the system needs most now is real-world testing: try it with your contrib modules, test it with your custom entity types, and report bugs when you find them. Every production deployment proves the architecture.

Workspaces is stable, it is in core, and it is the right architecture for content governance at scale, including AI content generation.

Ready to see it in action? Watch the full session recording. >