A few years ago I said Drupal needed infrastructure innovation, and I finally took the time to do something about it. While I really like DDEV, I'm really not a fan of having to use Docker for everything so I'm trying to do something about it.
theodore September 22, 2026European Digital Identity Wallets are moving from technical framework and pilot programmes towards services that people will be able to use across the European Union. The European Commission says Member States must make wallets available to citizens, residents, and businesses by the end of 2026. For Drupal teams, that makes digital identity less a future policy topic and more an application-architecture question.
The wallet model changes what an online service can ask a user to prove. Instead of treating identity as one complete profile, users can present particular identity data or attestations and disclose only the information required for a transaction. Commission figures say more than 550 companies and public authorities across 26 Member States, Norway, Iceland, and Ukraine are participating in large-scale pilots covering government services, banking, education, health, transport, telecommunications, and other uses.
The relevant role for a Drupal application is the relying party. Under the European framework, organisations that use wallets for digital services must register their intended use and indicate the data they plan to request. That puts the request itself inside a defined trust and registration model rather than leaving every application to decide independently what identity information it wants to collect.
The technical exchange is also more specific than adding another login provider. For remote presentation flows, the EUDI architecture uses OpenID for Verifiable Presentations to carry requests and wallet responses between wallets and relying parties. A Drupal service could potentially use a validated result from that layer for authentication, account linking, permissions, eligibility checks, or workflow decisions, but the material reviewed for this issue does not establish a production-ready Drupal integration that provides those functions today.
Data handling may prove more consequential than authentication itself. A wallet may be able to prove that a person has a particular attribute without requiring the service to collect a larger identity record, and the European framework is designed around data minimisation and selective disclosure. The application still has to decide what happens next: whether the verified attribute becomes persistent Drupal user data, whether only a derived result is retained, or whether the information can disappear once the transaction has been completed.
Those decisions sit above the wallet protocol. Drupal already provides accounts, permissions, fields, workflows, access rules, logging, and application-specific data models, but none of those automatically determine which verified identity attributes an organisation should retain. Connecting a verifier to Drupal therefore solves only part of the problem; the rest belongs to application design, data governance, and the legal requirements of the service being built.
The EUDI technical framework is still developing as deployment approaches. Version 3.0.0 of the EUDI Wallet Architecture and Reference Framework, published in July 2026, updates Wallet-Relying Party registration and introduces the concept of Relying Party Services alongside other changes. For Drupal projects in European government, education, and other identity-sensitive environments, the question is not simply how Drupal accepts a wallet, but which verified facts the application actually needs after the wallet has done its job.
Follow The DropTimes on LinkedIn, X, Bluesky, and Facebook, or join #thedroptimes on Drupal Slack.
Kazima Abbas wrote and curated this issue of Editor’s Pick.
Every update on a multilingual Drupal site must reach each market language - not just the source page.
Drupal multilingual websites can use AI-assisted translation drafts inside Content Translation workflows so editors review and publish without copying text between tools. Maciej Lukianski explains shared fields, editorial ownership, document links, and keeping localized pages consistent for people and AI search.
This is the first post in a three-part series about the impact of the AWS Open Source Credits program on the Drupal community. Part one covers our testing infrastructure. Part two will cover the community programs we host beyond code. Part three will cover what the AI era is doing to open source infrastructure, and what we're building next.
Drupal is one of the open web's longest-running content management projects, in continuous development since 2001, and a recognized Digital Public Good. It runs a large share of the public web: government portals, universities, hospitals, cultural institutions, and international organizations, including the European Commission and agencies across the UN system. The Drupal Association is the small non-profit that keeps the project's home online. We build the tools that enable our community to build Drupal.
Since 2025, the AWS Open Source Credits program has supported the infrastructure behind that work. This series is our thank you, and impact report about what that support has made possible.
The scaleDrupal's collaboration happens on git.drupalcode.org, our self-hosted GitLab instance and one of the largest in open source. It hosts 42,382 contributed projects: 39,003 modules, 2,400 themes, and 979 distributions, alongside Drupal core itself.
The Drupal community opens more than 5,300 merge requests every month, about 65,000 a year, from 8,000 unique contributors annually. Drupal core alone has 15,256 issue forks.
Every one of those merge requests runs through continuous integration (CI) before it can ship. Our GitLab CI runners autoscale on AWS, accounting for roughly a third of our entire cloud footprint. In the last year they executed ~4.1 million jobs, consuming ~159.8 thousand compute hours. That's 438 hours of compute per day. (Data from Aug 26, 2025 – Aug 26, 2026).
Velocity is a contributor experience challengeHere's what autoscaling CI means for a community like ours. A contributor in Singapore, Mumbai, or Rotterdam pushes a change and gets test results back in minutes. There is no fixed pool of test machines, no queue where contributors wait on each other, no rationing of who gets to test what.
If elastic capacity, funded by credits, means those contributors have never had to deal with longer queues, capped concurrency, or asking volunteers to test less..
We care about this because contributor velocity is essential to the success of Drupal. The Drupal Association engineering team is small, just 4 people. We don't build Drupal; thousands of people do that. Our job is to make sure the tools are available and fast when they need them.
Velocity and safety are the same systemIt would be easy to frame fast CI as a developer-happiness story and stop there. But for a project with Drupal's footprint, that same infrastructure is a safety system.
In the last twelve months, the Drupal Security Team has coordinated 163 security advisories across core and contributed projects. Every fix behind those advisories was developed, tested, and released through the same AWS-powered pipeline as any other change. The sites that depend on those fixes find out through us too: about 667,000 Drupal sites check in with our update infrastructure every week to learn whether they need to act. That's a conservative floor, since it only counts sites that phone home.
We also operate Drupal Steward, a protective service that shields sites during the most dangerous window in security response: the hours between a public advisory and a site's own patching. AWS powers that too.
Drupal powers governments, public utilities, and health systems worldwide, making our testing pipeline critical public infrastructure. Every automated test directly protects the security and stability of the websites people rely on daily.
A smooth transitionFor two decades, much of Drupal's infrastructure ran on donated hosting at the Oregon State University Open Source Lab, which has been a quiet hero to dozens of open source projects. As the lab restructures, we have been migrating essential services to AWS. Credit support meant that migration happened without cutting contributor capacity, and without asking a small non-profit engineering team to do more with less at the worst possible moment.
Our thanks to the OSU Open Source Lab for twenty years of partnership, and to AWS for making this next chapter possible.
What's next in this seriesWhile compute numbers show our scale, the human impact matters just as much., In our next post: the community programs we host that have nothing to do with code, and why we think that infrastructure matters just as much.
The Drupal Association is a 501(c)(3) non-profit. If your organization depends on Drupal, or on the health of open source infrastructure generally, you can support our work.
Your marketing team already knows who the VIPs are. They maintain the segment in Mautic, they send it a campaign every month, they add and remove people as orders and behaviour change. Then somebody asks for a VIP banner on the website, and the website turns out to know nothing about any of it. So "VIP" gets built a second time, as a Drupal role or a checkbox on the user: two definitions of the same audience, maintained by two teams, drifting apart from the first week.
The second problem arrives with the first. Personalisation on Drupal usually means varying the page per visitor, and a page that varies per visitor is a page nobody else can be served, so the banner meant to lift conversion ends up slowing the site down for everyone.
We build and run Mautic-driven marketing for our e-commerce clients, so we kept meeting both problems on the same projects. Mautic Audiences is our answer, now on drupal.org as free software (GPL-2.0-or-later) for Drupal 10.3 and 11, covered by Drupal's security advisory policy. It reads the segments and tags you already maintain in Mautic and turns them into native Drupal primitives: block visibility, Twig, tokens, JavaScript, Views, Search API and, since 1.1, a field.
What editors can build without a developerPlace any block, scroll to Visibility, pick Mautic segment, type vip. Save. That is the whole configuration, and it covers most of what people actually ask for:
Anonymous visitors count: someone carrying Mautic's tracking cookie has an audience with no login, which is what lets a campaign link open a personalised page at all. Editors check their work by appending ?ma_preview_segments=vip to any URL, which shows the site as a member of that segment sees it.
Themers get the same decision as a one-liner that brings its own cache metadata, and there is a token for metatag patterns and a JavaScript call for whatever has to happen after the page is served:
{% if is_in_segment('vip') %} <p>Free shipping today, your VIP perk.</p> {% endif %} Content that knows who it is forThe module started by answering "who is this visitor?". Version 1.1 adds the other half, "who is this content for?", in a bundled sub-module.
Add the Mautic audience field to any bundle and editors pick, from the real list of segment names, who a piece of content is meant for. By default that is a targeting hint templates and listings read. Per field, you can turn on Restrict viewing to the selected Mautic segments, and content with a segment picked is then refused to everyone outside it. Content with nothing picked stays for everyone.
A gate that only closes the page is not a gate, so the sub-module also ships a Views filter that keeps whichever rows each visitor is entitled to, and a Search API processor that adds the condition at query time rather than keeping items out of the index. Its README lists what none of it can cover, exports, feeds, custom code that loads entities without an access check, because a promise of restriction with holes in it is worse than no promise.
The interesting part is what it refuses to exposeSegment names and tags are business intelligence: cancelled-subscription, risk:churn-90d, coupon:VIP-50. Ship them to the browser and you have published how you categorise your customers, and sometimes a working coupon code, to anyone with DevTools open.
So the client-side API answers questions instead of listing facts. It will tell you whether this visitor is in a segment you name; it will not tell you which segments exist or which ones they are in. The endpoint that returns an actual list starts empty and returns only what an editor has allowlisted. The field type has no formatter at all, and reading its values takes an administrative permission, which covers JSON:API, REST and Views alike.
It stays out of your render pathAudiences are read from local storage on every render, never from the Mautic API, so a slow Mautic never sits in front of a page, and an outage degrades to an empty audience rather than an error. Cache contexts key on the resolved audience rather than on the visitor, so two people in the same segments share a cache entry and a page with two gated blocks has four variants, not one per visitor. Anonymous personalisation does cost you Drupal's Internal Page Cache on the pages that use it, which docs/cdn.md deals with head on.
Get it composer require drupal/mautic_audiences drush en mautic_audiencesIt needs Advanced Mautic Integration for API connectivity, a Mautic instance with API credentials, and PHP 8.2 or later. A bundled sub-module wires Klaro into the resolver, so visitors who have not consented resolve to an empty audience without any code.
The project page, the issue queue and the documentation are at drupal.org/project/mautic_audiences. If you run Drupal Commerce, Commerce Mautic Connect pushes the abandoned carts, customer metrics and coupon tags into Mautic that this module reads back. Issues and merge requests are very welcome.
There will be a security release for a widely used contributed module on September 23, 2026 between 17:00 and 21:00 UTC.
We are announcing this release in advance because the affected contributed module is used on a significant portion of Drupal sites, and the upcoming release will include a significant number of advisories. The advisory with the highest risk score for the release is currently rated as critical.
Drupal core is not affected.
Advisories may be published in batches (a few at a time)The current rate of advisories may require changes to our practices going forward:
These changes are intended to make the process easier for the team and to make communication from the team easier to follow.
No special release proceduresThe planned update does not require special release procedures.
Coordinated By:Snapshots have been a beloved feature of DDEV for years, but in v1.25.4 there is so much more.
Read on (or watch, or both) to see:
A DDEV snapshot is a physical, "hot" backup of your database — mariadb-backup/xtrabackup for MariaDB and MySQL, or pg_basebackup for Postgres — not a text-based mysqldump. Because it copies the database's on-disk files instead of dumping SQL statements, it's much faster to create and restore, especially on large databases. All the basics about snapshots are in the docs.
Normally snapshots live in .ddev/db_snapshots/, and the filename encodes the database type and version, for example mariadb_11.8. That's why a snapshot only restores against a matching engine and version — restoring a mariadb_11.8 snapshot into a mariadb_10.11 project will fail.
Snapshots are compressed with zstd by default. --uncompressed skips the decompression step on restore, trading a much larger file on disk for a faster restore. Postgres doesn't support uncompressed snapshots.
Core CommandsIf your project has multiple Git worktrees, snapshots taken from other worktrees of the same repository are available too — by name, with --latest, or through the interactive list.
Snapshots as Migration CheckpointsTake a snapshot before each step of a migration or update: ddev snapshot --name=pre-migration-step3. If a step breaks something, restore the last good snapshot instead of restarting the migration from scratch. (ddev snapshot restore --latest can be a great technique if you do this religiously.)
ddev snapshot --list becomes a log of checkpoints, and ddev snapshot restore <name> or restore --latest jumps back to any of them instantly.
This builds on the workflow described in DDEV Database Management: snapshot, ddev restart --reset-database, restore. It's also a natural lead-in to seeding a new database volume directly from a snapshot, covered next.
The seed SnapshotDDEV projects have always automatically created a database named db to help you get started fast. But it's been an empty database, with no content. Now, in DDEV v1.25.4+, the seed snapshot has been added. You can create a snapshot named seed (with whatever content you want) and when somebody starts up a project for the first time, the content on the seed snapshot will automatically be loaded. You can even check the snapshot named seed into your Git repository if you don't object to its size, and it can help folks new to the project to get started that much faster. (The seed snapshot is only used when there is no database; your changes to the database are kept as always.)
To add the seed snapshot to Git:
git add -f .ddev/db_snapshots/seed-* git commit -m "Add default seed db for clean startup" Seeding New Projects with --seed-snapshotIf you want to start a project with an alternate seed snapshot, ddev start and ddev restart accept --seed-snapshot=<name-or-path>, which seeds the database volume from a snapshot instead of the stock seed database. This only applies when there's no existing database — DDEV errors otherwise, telling you to add --reset-database or use ddev snapshot restore.
<name-or-path> can be a short name from .ddev/db_snapshots/ or a full path:
ddev start --seed-snapshot=$HOME/tmp/mysnapshot-mariadb_11.8.zstThis works for every database type DDEV supports, unlike the baked-dbimage technique below, which is MariaDB/MySQL-only — it's restored the same way ddev snapshot restore does, just at volume-creation time.
Combine --seed-snapshot with --reset-database to reseed an existing project in one step:
ddev restart --reset-database --seed-snapshot=<name> -Oy-O (--omit-snapshot) skips the automatic snapshot save of the database being thrown away, and -y skips the confirmation prompt.
This is the lightweight alternative to baking a seeded database image: no custom image or registry, just a snapshot file — good for local or small-team use where a shared registry is overkill.
Seed Snapshots + --reset-databaseOnce you have a seed snapshot, ddev restart --reset-database -Oy repeatedly returns the project to that known-good state — handy between test runs.
Building a Seeded Database ImageYou can also create a replacement database image that has an alternate seed database built into it. This is especially great for delivering huge databases, as the process can be handled by the image, or an upstream process. All the image building does is copy a base_db.zst or base_db.mbstream into the /mysqlbase/custom directory of the DB image.
For teams that want to share a ready-to-go database via a Docker image registry instead of a snapshot file, build-and-push-seeded-image.sh is an example that builds a real multi-arch (linux/AMD64, linux/ARM64) image with a snapshot baked in:
build-and-push-seeded-image.sh --snapshot=uncompressed-2g \ --output-image=randyfay/uncompressed-2g:v1.25.4 --push \ --base-image=ddev/ddev-dbserver-mariadb-11.8:v1.25.4This technique relies on mariadb-backup/xtrabackup, so it doesn't support Postgres.
Uncompressed seeds make for a much larger image and a slower push, but a faster, decompress-free container startup. It's worth comparing the actual image sizes to see the bandwidth cost of each trade-off.
Using a Seeded Image via dbimage:Point a project at the seeded image using dbimage in .ddev/config.yaml (or .ddev/config.local.yaml):
# .ddev/config.yaml or .ddev/config.db.yaml or .ddev/config.local.yaml # Example dbimage dbimage: randyfay/uncompressed-2g:v1.25.4Then:
ddev restart --reset-database --omit-snapshot -y Examples and resourcesThis article was edited and refined with assistance from Claude Code.
Reposted from Acquia with permission from Acquia. Authored by Martin Anderson-Clutz (mandclu)
Drupal Canvas AI shifts content platforms from reading to writing, using governed context layers to help enterprise AI agents automate safely.What changes when an agent stops reading your content and starts writing it?
For the last two years, the conversation about AI and content has mostly been about reading. Retrieval, summarization, a chatbot that answers a question from your knowledge base. That problem is largely solved, and it is solved almost everywhere. Any serious platform can find a relevant paragraph and hand it back.
The shift that actually changes the job of a content platform is quieter. Agents have moved from "answer my question" to "do the work." They are no longer only reading your content. They are starting to write it, assembling pages and populating components and publishing the result. The category we have called content management for twenty years was built for the first job. It was never asked to do the second.
Where the Real Cost LandsAt this point a fair objection turns up: is this not exactly why we keep a human in the loop? It is. Any content platform worth running in an enterprise keeps a person between the agent and the published page. A system that lets an agent push unreviewed work straight to production is not showing you the risk of agentic content. It is showing you that it was never built for the enterprise to begin with.
So the risk worth talking about is not the rogue page. Review catches that. The risk is waste.
A read and a write still fail in opposite directions, and the cost is what separates them. When a retrieval system returns a weak answer, one person spends a moment sorting it out and moves on. When an agent produces a weak write, a layout that misses the brand or a component wired to the wrong relationship or a draft that ignored a business rule, someone has to notice it, correct it, and often send it back to be generated again. Every one of those steps costs the reviewer's time and burns the tokens that produced the work in the first place.
That cost lands on the exact person the agent was supposed to help. The promise of agentic content is leverage, so the specialist spends their time on judgment instead of assembly. A guessing agent quietly reverses the trade. Rather than assembling the page themselves, the reviewer now inspects a draft they did not write. They hunt for the places it went wrong and explain what to change. That is not leverage. It is rework wearing the costume of automation, and it scales the wrong way, because an agent that guesses does not guess once. It guesses across every draft, at machine volume.
This is why context is the whole game. A human in the loop is cheap when the work in front of them is already right, and expensive when it is not. Give the agent structured, governed context and the review step becomes a quick yes. Hand it flat fields and hope, and the review step becomes the job you were trying to automate, now done twice.
Every Generation Answered to a Different ConsumerIt helps to look at what actually changed, because the content platform has served three different consumers over its life.
Content Management System Headless and Composable Agentic Content Platform Primary consumer A person in a browser A front end serving a person Software that acts Content flows Outward, to one presentation Outward, to many presentations In both directions How editorial judgment is applied By hand, page by page By hand, page by page Encoded as context up front, confirmed at review Measure of success Editorial autonomy Reuse across channels Safe, accountable machine actionFor most of that history, judgment stayed with the editor. The system stored content and rendered it, while a person decided what was true, what was on-brand, and what was ready to publish. Headless moved content to more places, but it did not move that responsibility. A human still stood between the content and the world.
Agentic content management changes that. The agent now does the assembly the editor used to do, which means the judgment the editor brought to the work has to come from somewhere. A platform that carries it, with the business rules and the content relationships and the standards for what good looks like, hands the reviewer a draft that already reflects those things. A platform that cannot leaves every one of those calls for the person to supply by hand, one draft at a time. The judgment does not disappear. It moves back onto the reviewer the agent was supposed to free.
The Distinction the Category Is MissingHere is the line most tooling blurs, and the reason so many agentic demos fall apart the moment they meet a real enterprise. Content is not context.
Content is what you publish: the page, the article, the product description, the campaign.
Context is everything an agent draws on to produce that content safely. Your brand voice. Your content model. Your business rules, your reference material, and the relationships that connect all of it. Context is what turns a vague prompt into a result the organization would actually stand behind.
Most systems collapse the two. They hand an agent a set of flat fields and hope it infers the rest: the tone, the relationships, the governance that always lived in the editor's head. Guessing works beautifully in a demo and breaks in production, because the fields never carried the context to begin with. The agent was handed the output and asked to reconstruct the reasoning behind it.
Treating context as a governed layer of its own, with clear owners, review, version history, and scope, is what separates an agent that produces a plausible draft from one an enterprise can trust to publish. The prompt gets simpler. The result gets more accountable. The organization decides in advance what the agent is allowed to know and do.
What Structure Actually Buys YouHere the shape of the underlying system stops being an implementation detail and becomes the whole question.
An agent that writes needs things the read era never demanded. It needs to see the page as a structure it can reason about, with components, order, and resolved values, rather than a wall of markup it has to pattern-match. It needs to work inside the governance that already exists, the roles and permissions and workflows the organization spent years getting right, instead of routing around them. And it needs its output to land in a reviewable state, with a record of who initiated the work and what produced it, so a person can still say yes or no before anyone sees it. Structured context is what makes that review a quick confirmation rather than a second round of work.
None of that can be added after the fact. A platform that stores content as flat, disconnected fields cannot suddenly expose relationships it never modeled. A platform with shallow governance cannot suddenly supervise an agent it was never designed to hold. These are properties of the foundation. Either the structured content and the mature governance are already there, or you are trying to pour a footing under a building that already stands.
For years, careful content modeling and granular governance were treated as overhead, the slow and unglamorous work that held teams back. The agentic era inverts that. The same rigor is now what lets a team move quickly and safely at once, because it is exactly what an agent needs in order to act without guessing.
Where This Gets Real: Drupal CanvasPlenty of tools can turn a prompt into a layout now. That trick is becoming table stakes, and it is the wrong thing to be dazzled by. The real question is whether the layout that comes back is on-brand, relevant, usable on the devices your audience actually reaches for, and built on terms you control. The answer depends on the foundation under the prompt, and that is what Drupal Canvas is designed around.
Four differences show up the moment you move past the demo.
The first is how layouts get built. Canvas assembles them from Twig-based single-directory components, React-based code components, and Drupal blocks, so you work with the component technologies your team already knows rather than adopting one proprietary format wholesale.
The second is where the context comes from. Because Canvas can ground its work in the Context Control Center, the agent is not inventing your brand from a prompt. It is working from the voice, content model, business rules, and relationships your organization has already curated and approved. That is the difference between a layout that is merely plausible and one that is on-brand and relevant.
The third is the model underneath. Through a provider-agnostic AI layer, Canvas is not wired to a single vendor's model. You use the one that suits the task in front of you, and you change your mind later as the field moves, without re-platforming to chase whatever shipped this quarter.
The fourth is where the output can go. Coupled or decoupled, you manage the content once and render it across the front ends and devices your audience uses, so a traditional site and a headless build stay open to you from the same system.
Any one of these helps on its own. Together they are the distance between generating a layout and producing one you can put into production: on-brand because it is grounded in your context, usable anywhere because the output is ambidextrous, and built with whatever model best fits the work.
The Engine Behind It: The Drupal AI InitiativeNone of this is a single product feature or a one-vendor bet. It comes out of the Drupal AI Initiative, the funded and coordinated effort in the Drupal community to make the platform both a great place to build with AI and a safe place for agents to act. That initiative is the engine behind the capabilities that put Drupal in front on the things that matter here: structured content an agent can reason about, governance it has to respect, a provider-agnostic model layer, and the freedom to publish coupled or decoupled.
The work runs on two fronts. One brings common AI features directly into Drupal so they operate together instead of as disconnected add-ons. The other makes Drupal legible and callable to agents and tools working from outside, measured against an Agent Readiness scorecard that keeps the progress honest. Because it is happening in the open, on standards-based foundations, the improvements compound for everyone building on Drupal rather than accruing to one company.
The Context Control Center is a good marker of the pace. It turns the context an agent can draw on into a governed content entity, with ownership, workflow, revisions, translations, and scope, and its first stable release is expected in the days ahead. That moves the grounding layer from promising to production, which is the exact piece most platforms are still treating as a roadmap.
If you want to see where this is heading, DrupalCon Rotterdam has two AI Summits dedicated to it. I will be presenting at the AI Dev Summit, and my colleague Scott Falconer will present at the Enterprise AI Summit, one track for the people building with these tools and one for the people who have to answer for them in production.
Design It In, Do Not Patch It OnFaced with a fast-moving category, the tempting move is to wait for a winner and buy in later. The trouble is that the properties that matter here do not arrive as an upgrade. Structured content, relationship-aware data, a governed context layer, model choice, and the freedom to render coupled or decoupled are either in the foundation or they are not.
So the question for a content team is not which AI feature to switch on. It is harder and more useful than that. When an agent stops reading your content and starts writing it, does your platform still carry the judgment that used to live with your editors? Content answers to a person. Context is what lets software act in their place. The teams that see the difference, and that build on a foundation treating context, structure, and governance as first-class concerns, are the ones who will let agents do real work while keeping a hand on what ships.
File attachments: Image1.pngLaunching your site isn’t the end of the work. That’s the bad news.
Even after you settle back into your day-to-day, your website still needs you. There’s still so much you can and should do.
The good news: the work spreads out across the year, and the effort rises and falls. But measuring your data and making steady improvements is needed to keep your website effective long after launch.
About a week ago, I wrote about the simplytest.me rewrite and closed on what was next: site templates and recipes. You can now launch a sandbox for a site template. I'm excited that people can now easily try out all the site templates on Simplytest.me.
Compound field was released as an alpha release two days ago. It's getting a lot of people excited. Let's install it and see how it works.
markconroy 18th Sep 2026