What Is Drupal Canvas? The New Page Builder for University Websites

Drupal Canvas is a visual, component-based page builder that lets editors assemble pages directly in the browser. Version 1.11.0 arrived in September 2026, it requires Drupal 11.3 or later, and more than 8,000 sites report using it. In this article we cover what Canvas actually is, what a platform needs before it can run, how it sits alongside Layout Builder and Paragraphs, who should be allowed to use it, and whether it is ready for a university website today.

Canvas has been written about mostly as an announcement. The coverage explains the features and stops there, which leaves a university web team without the answers it needs. Does this replace the Layout Builder that department sites already run on? What has to change in the theme first? Who gets to use it once it is installed, and what stops a department from rebuilding its landing page in a way nobody approved? Below we work through those questions with the facts as they stand in September 2026.

What is Drupal Canvas?

Drupal Canvas is a visual page builder. Editors drag components onto a page, arrange them, preview the result and publish, all without leaving the browser. Behind that interface sits a React application talking to Drupal's core APIs, which is why it behaves differently from the administrative screens around it.

The project states its purpose in two halves. Site builders should be able to theme and build an entire website in the browser without writing code beyond basic JSX and CSS. Content creators should be able to compose content on any part of a page without relying on a developer. The Canvas initiative page adds a third point that matters for institutions: because Canvas is built on Drupal's structured data and fine-grained access controls, what an editor assembles stays structured content rather than becoming an opaque block of markup.

That last distinction is the reason a university should read Canvas differently from a commercial page builder. Content that keeps its structure can still be reused, translated, searched and migrated later.

From Experience Builder to Canvas

Anyone who followed Drupal news through 2025 will have seen this project under another name. Canvas was originally developed under the working name Experience Builder, and the rename happened before the 1.0 release. Searches for Experience Builder still return material describing the same project, which is worth knowing when reading older posts or watching conference recordings from that period.

What Canvas needs to run

Three requirements decide whether Canvas is available to an institution at all.

• Drupal 11.3 or later. This is the hard gate. A platform on Drupal 10 cannot install Canvas until it has completed a major version upgrade, which turns a page builder decision into a platform roadmap decision.
• Composer 2.7 or later, plus administrative access. Specbee's walkthrough also documents a dependency conflict that appears when drupal/core-dev is present in the project, tracked as issue 3534774.
• A theme that exposes Single Directory Components. Technically optional, practically essential. The section below explains why this is the part most institutions underestimate.

On the version itself, the project page records release 1.11.0 on 8 September 2026 against Drupal ^11.3, with 8,315 sites reporting use. Stable releases are covered by the Drupal security advisory policy, which is the question a university security review will ask first.

What Canvas changes for a university web team

The daily friction on a campus platform is rarely the software. It is the queue. A department wants a landing page for an open day in three weeks. The available template does not fit the content, so the request goes to central web services, joins a list, and the page ships late or ships wrong.

Canvas addresses that specific bottleneck. A department editor assembles the page from components the institution has already approved, sees the result as visitors will see it, and publishes without a ticket. The developer time that would have gone into a one-off layout goes into the component library instead, where it benefits every unit.

Institutions are already framing it this way. Syracuse University publishes a Canvas guide for editors on its SUpal platform, aimed at marketers and content creators, and the five capabilities it lists put brand consistency and reusable custom components alongside drag-and-drop editing. That ordering is the point. On a campus, the value of a page builder is not freedom on its own; it is freedom inside boundaries the institution has drawn.

Canvas, Layout Builder and Paragraphs compared

Most universities already run one or both of the older tools, so the useful question is not which is best but what each one is for.

Layout Builder arranges pre-approved blocks into regions of a page. Paragraphs models repeatable content structures as fields, so an editor fills in a form and the theme decides how it renders. Canvas renders the design system live and lets the editor compose against it, which is why it reads as true what-you-see-is-what-you-get rather than an abstract arrangement of boxes.

In practice these coexist. A programme page may keep its structured Paragraphs fields while a campaign landing page is built in Canvas. Deciding per content type rather than platform-wide is what keeps the migration manageable.

Is Layout Builder being deprecated?

No. Layout Builder does not appear on Drupal's list of deprecated and obsolete core modules, which is the authoritative place such changes are recorded. Much of the Canvas coverage implies a replacement is underway, and for an institution running hundreds of department sites on Layout Builder that implication is expensive to act on.

What is true is that Drupal's site-building direction is still being settled in the open, and community discussion continues about how these tools relate over time. Treating that as an open question rather than a settled migration is the accurate reading.

Single Directory Components: the prerequisite behind Canvas

Canvas does not invent a new component format. It discovers components the way Drupal core already does, through Single Directory Components. An SDC keeps a component's Twig template, CSS, JavaScript and assets together in one folder, with a component definition file that declares its properties and slots using JSON schema.

That definition file is what makes Canvas usable. When a component declares proper property schemas and examples, Canvas generates the right editing widgets automatically. When it does not, the editor gets a component that cannot be configured properly in the interface.

For a university this is where the real project sits. A custom theme built over several years rarely has its components in SDC form. Converting them is not a side task, and the order matters: components that appear on the most pages earn conversion first.

There are established routes from both older tools. Paragraph types convert by analysing the existing structure, creating a component folder and mapping fields to properties and slots. Layout Builder custom blocks convert the same way, with complex nested layouts becoming container components. A phased approach works better than a single cutover: convert the most-used components first, build new pages in Canvas while the team learns it, then move high-value pages such as the homepage and campaign pages, and let the long tail follow during ordinary updates.

Canvas on a multisite platform

On a platform where faculties run separate sites from one codebase, Canvas is installed and configured per site, while the component library lives in the shared theme. That split has a useful consequence: the central team improves components once and every site inherits them, but each faculty decides when to start using Canvas. Adoption does not have to be simultaneous. The wider trade-offs of that architecture are covered in managing university websites with Drupal multisite.

It also suggests a low-risk pilot. Rather than rebuilding the institutional homepage, enable Canvas on one department site or a new microsite, run a term with it, and decide from evidence rather than from a demonstration.

Who gets to use Canvas

A page builder that lets an editor assemble any page from any component is a governance question before it is a technical one. The institution has to decide which roles can use Canvas, which components each role sees, and whether a page built in Canvas goes live directly or waits for review.

Drupal answers the first part through the permission system. Access to Canvas is granted by role like any other capability, which means the same structure that decides who can edit a department page decides who can build one. We set out how to build that structure in Drupal user roles and permissions for universities.

The second part is workflow rather than permission. A contributor who can assemble a page but not publish it is a permission decision; a page that waits in review until a communications officer approves it is a workflow decision. We covered that layer in content approval workflows for universities.

A workable starting position is narrow. Give Canvas to central editors and a small group of unit editors first, keep the component library small enough that every component has been reviewed, and widen access once the institution has seen what people actually build with it.

Is Canvas ready for a university website today?

The honest answer depends on what the site is and how much change it can absorb this year.

The arguments for adopting now are real. Canvas is covered by the security advisory policy, more than eight thousand sites report using it, and releases are frequent enough that reported problems get attention. For an institution already on Drupal 11.3 with a component-based theme, a pilot costs little.

The arguments for waiting are equally real. Version 1.11.0 in September 2026 describes a project still adding capability rather than one that has settled. Core version constraints have moved across releases, so pinning a version without checking current requirements is a risk. The Composer conflict noted above is the kind of friction that appears in an actively developing project. And the wider question of how Drupal's site-building tools relate to each other is still being worked out in the community rather than announced as a decision.

For most universities that points to the same conclusion. Canvas is worth piloting now and worth planning for, but rebuilding a main institutional site around it this academic year is early. A department site or a new microsite gives the team real experience at a fraction of the risk.

Planning a Canvas pilot

The sequence that keeps a pilot useful is short. Confirm the platform is on Drupal 11.3 or can get there, because everything else depends on it. Audit the theme and list which components already exist as Single Directory Components and which do not. Pick the ten components that appear on the most pages and convert those first. Choose one department site or a new microsite as the pilot rather than a rebuild. Decide which roles get access before the first editor logs in. Then run a full term and review what people built, not what the demonstration promised.

The Drupal platforms that the Drupal4edu team at Drupart builds for institutions such as Sabanci University, Işık University and Yildiz Technical University are designed around a shared component library and a central team that maintains it, which is the groundwork a tool like Canvas depends on. You can read more about our approach on the Drupal for education page.

Frequently asked questions about Drupal Canvas

Latest update: 21.09.2026 18:07