About this session

Drupal Canvas is Drupal’s visual page builder: editors drag components onto a page and assemble in minutes what once took days or weeks. But as Mike Herchel, Lead Evangelist at Acquia and founder of premium theme shop Dripyard, puts it early in this session, Canvas is nothing without components — if there’s nothing to drag onto the page, there’s no page builder at all. Drawing on his experience building Dripyard’s component library, his work as a Drupal core frontend framework manager and CSS subsystem maintainer, and his first weeks at Acquia, Herchel walks through what separates components that delight editors from components that confuse them.

The heart of the talk is five qualities every Canvas component should have: flexible, usable, portable, robust, and accessible. Herchel shows how container queries let a component adapt to wherever an editor drops it, why props should be planned around the 80% editorial use case and labelled in plain language (“inside spacing,” not “padding”), and how an editor-only “Canvas edit mode” toggle can switch off JavaScript so nested items inside a carousel stay editable. The accessibility section covers semantic HTML, unique IDs, accessible names, and no-JavaScript fallbacks, before building up to a layered colour system: brand colours in theme settings, a gradient of shades generated with OKLCH relative colour syntax, and semantic tokens that keep text contrast accessible no matter which theme an editor applies to a parent component.

The final stretch surveys where Canvas itself stands: content templates for visually styling content types, the new page templates that replace global regions, and patterns — groups of components Herchel calls an underused easy win for editorial teams. He closes with a candid wish list (exposed slots, restricted slots, fieldable Canvas pages) and a Q&A on the question many teams are asking: how to move an existing theme to single-directory components and Canvas incrementally, with AI doing the repetitive work — and a human watching what it writes.

Pull quote

“When an editor drops that component, they should not be surprised at the way it’s going to look.”

Key takeaways

• Good Canvas components are flexible, usable, portable, robust, and accessible; plan props around the editor’s 80% use case and use editor-friendly labels such as “inside spacing” instead of “padding.”
• Container queries let components adapt to wherever an editor drops them, and an editor-only “Canvas edit mode” toggle can disable JavaScript (for example, on a carousel) so nested items can be edited.
• A layered colour system (theme-setting brand colours, OKLCH relative colour syntax, semantic theme tokens) lets editors change themes on parent components while text contrast stays accessible.
• For content templates, make component fields optional so they can be mapped; page templates replace global regions, and patterns are an underused way to speed up page assembly.
• On the wish list: exposed slots, restricted slots, and fieldable Canvas pages. In Q&A, Herchel recommends converting existing themes to SDCs incrementally with AI assistance — and an audience member cautions to closely monitor what the AI writes.

 

Chapters

• 0:00 Introduction
• 2:07 What is Drupal Canvas?
• 2:55 Component types: SDCs and code components
• 5:03 What makes a good component
• 6:00 Flexible components and container queries
• 9:28 Usable components for content editors
• 11:55 Canvas edit mode and component grouping
• 14:44 Robust components inside and outside Canvas
• 17:26 Portable components
• 18:35 Accessible components
• 21:42 Design system and color theming
• 27:33 Content templates in Canvas
• 29:38 Page templates and patterns
• 31:41 Canvas wish list
• 33:01 DrupalCon Orlando
• 34:26 Q&A

Transcript

Introduction

Mike Herchel [0:04]

Hello, DrupalCon!

Audience (unidentified) [0:05]

Woo-hoo!

Mike Herchel [0:06]

Yeah! It's the last day. It's exciting, hopefully, for a little bit of everybody. It went by very, very fast. This is Building for Drupal Canvas: Lessons Learned from Real-World Use. My name is Mike Herchel. I am a lead evangelist at Acquia. I have been at Acquia for somewhere around a grand total of about a month and a half now, but it's been awesome. And believe it or not, I am in marketing. I'm an evangelist, so I get to talk about Drupal, but I'm also a developer. I'm an owner of a company called Dripyard that was started a couple years ago. Dripyard makes amazing custom— or amazing premium Drupal themes. It's a collection of— a large collection of components that's tied together with a great design system, and it just works really wonderfully. A lot of what I'm talking about in this presentation comes from that experience. I am also a Drupal core frontend framework manager, which means that I get to commit code and influence how Drupal's frontend works. I'm also a Drupal core CSS subsystem maintainer, which means I get to work on Drupal core CSS, and I'm an advocate for free open source and especially Drupal. As mentioned earlier, I work at Acquia now. I am super proud that I work at Acquia because Acquia is the largest contributor to Drupal. Let me see if I can get rid of this. There we go. Acquia is the largest contributor to Drupal by far, and I'm really, really proud of that. As mentioned, my company is Dripyard that makes beautiful premium Drupal themes, and you should all go to dripyard.com and check that out. I have a lot of really great blog articles there.

What is Drupal Canvas?

For those of you who do not know what Drupal Canvas is, I am going to do a very, very quick intro. I'm assuming most people know, but I don't want to be— I'm not 100% certain. Canvas is a beautiful visual page builder and page editor. You can edit your content, as you can see right here, and then you can also create new pages and you can quickly assemble landing pages using Drupal Canvas. In this case, we're adding patterns in there and you can see— what would normally take days or even weeks in some instances, you can assemble a full landing page in a matter of minutes or hours.

Component types: SDCs and code components

But Canvas is absolutely nothing without components. If you have Drupal Canvas but no components, there's literally nothing to drag onto your page. So this is kind of getting into the meat and potatoes of this presentation. I like to group components into kind of 3 general-ish types. We have base components that are things like headings, text, images. And these components are generally used to assemble more traditional components, things like cards, promos, heroes, and things like that. But you have another category of layout components. And these are— this lays out your grid system. Can arrange various different components next to each other, establish spacing between components.

There are 2 different technologies that Canvas supports. It supports single-directory components. And it supports code components. Most of the concepts I'm talking about in this presentation apply to both. But the code examples are from single-directory components. When you compare the two, single-directory components has advantages that it's server-side rendered. They're typically faster because they do not require any type of JavaScript library, front-end library. And they also work all throughout Drupal. They work outside of Canvas. I have a couple asterisks on number 1 and 2 right here because we will hopefully be releasing a server-side rendering component for code components in October. Code components have the advantage of being faster to deploy. You don't have to go through a whole deploy cycle. You can push your code components because they can live in config. Artificial intelligence tends to work very good with React, which code components are typically built on React. Most importantly, frontend developers from outside the Drupal ecosystem can find it much easier to pick up. They don't have to learn Twig. They don't have to learn the library system. They don't have to learn all these Drupalisms.

What makes a good component

When you're creating components, there's a lot of— there's more thought process than a lot of people put into it. A component needs to be flexible. It needs to be— and when I say flexible, it needs to be— you need to be able to put it— you need to be able to modify it so it fits your editorial needs. It needs to be usable so it doesn't overwhelm the content editor. The content editor needs to know how to use it without having to look at a manual. It needs to be portable, not just between— it's not going to be portable inside and outside of Drupal, but it would be really nice if it's portable between themes, between different websites that you have. It should be robust. And it needs to be accessible.

Flexible components and container queries

So let's talk about making it flexible first, right? So what you see to the right is just some basic— a Twig array that sends a bunch of props from a component and outputs some CSS classes. And it's very easy to overwhelm your editors with too many options within their component. You want to think about the 80% use case for that editor. You don't have to put everything in there. But in this particular case, we allow this section component to have spacing on the inside and outside. You can see an option of making a component flexible. These are icon cards. And as we— as we go through these— as I modify these icon cards, I'm changing the layout into landscape. I'm changing the size of the icon. And I'm also removing the background color. And what's interesting about this is if I have multiple groups of icon cards on the same page, I can have a different visual feel between the different icon cards. But if you look at the form on the right-hand side, it's not overwhelming. It kind of makes sense from the editorial point of view.

I'm a big fan of container queries. Does anyone use container queries on a regular basis here? I see a couple hands going up. So container queries are supported everywhere. If you're using something like Tailwind, Tailwind supports container queries. The examples here are native vanilla CSS. But container queries enable a component to adapt to the container that it's in, not just the viewport width. Traditionally, we have worked really hard to make our websites responsive. When you make it responsive, items can adjust based on the browser width. But not necessarily container width. In this example right here, we have— the card layout element will listen to the width of the card element, which is an ancestor element. And then if the width is larger than 600 pixels on the card, not just the browser, it changes the gap, and it changes to a grid layout. You can— an example of this working right here is I'm resizing the browser. And this is something that normal media queries can do. It's switching that card from a landscape mode to a portrait mode. But what if I go into the browser— into a Canvas editor? If I go into the Canvas editor and I shrink the container, I also want it to go into a portrait mode. Within the Canvas editor, there's no way to restrict where the editor is going to drop a component. You don't know if they're going to drop a component in a section layout, in the root slot, or within another type of component. The component that they drop in there needs to adapt to almost anything. It needs to be that flexible. It should not— when an editor drops that component, they should not be surprised at the way it's going to look.

Usable components for content editors

Your components need to be usable. And when I'm talking about usable, I'm not necessarily talking about for the end user. I'm talking about for the editor. There's that fine line that I talked about a little bit earlier about flexibility versus usability. I've seen many components where the right-hand side list of props is a little overwhelming. And the editorial team should not have to take notes or look at manuals for every single one. It's important to group the props together. And I said order your props properly, which I guess if you're ordering props, it's all properly. But group your margins together. Group your paddings together. Group your spacings together. Group your colors together. Your editorial team should not have to know CSS when they're adjusting the props. And an example of this is on the right-hand side, I have props, and they're labeled with margin and padding. That's not great. Like, an editor should not know— should not have to know what a margin is versus a padding. It should be labeled something like inside spacing or outside spacing or something like that. And once again, plan for that 80% use case.

You're going to want to test this as an editor within Canvas. You know, don't just have your AI agent write and just assume it's going to work. You want to see how it works, see if you can select the parent element. An example of— and you typically want to apply editor-specific tweaks. A situation that we frequently run into is when you have components nested within each other, the child component will butt right up next to the parent component. And that doesn't allow the editor to select that parent component until they go to the layers panel, which might be complicated. They might not know what to do with that. If you do it properly, you can check for a— you can add a CSS class when Canvas is in editorial mode, add a little bit of extra padding, and that allows that content editor to select the parent component.

Canvas edit mode and component grouping

We also, on certain components, will provide a little toggle as a prop called canvasEditMode. And canvasEditMode allows— it turns on additional kind of niceties when you're in that Canvas editor. I'm going to show this as an example right here. There is a carousel right here that you can kind of see operates as you would expect a carousel would. But when I go into the Canvas editor, I want to edit the actual cards. I can't do that because the JavaScript's initialized. So I toggle Canvas edit mode. And if you toggle Canvas edit mode, then I can drag and drop. I can move things around. I can edit the props. I can do what's expected. Now it's important to know that this Canvas edit mode will only ever affect the visual layout or the interactivity when you're in the editorial— the Canvas editor interface. It's not going to affect when you're previewing, and it's not going to affect on the front end ever. To do something like this, it's not terribly difficult. Like for an example for the carousel is we check to see if we are in Canvas editor mode. I'm going to show you some— some JavaScript that shows you how to set that up. But we check for that, and if it's in editor mode, we just do not enable the JavaScript. And then we will also change around some CSS. To detect it, if you're in edit mode, we have 2 different ways. We have— or 2 different parts of the same way. We have a little bit of preprocess that checks the route. And if we see— if the route matches, we add a CSS class. And then we have some JavaScript that does some additional checking to see if we are in preview mode or if we're in editor mode. The JavaScript's a little bit more complicated than this, but this is the general preview right here.

Drupal Canvas allows you to group components together. Once again, the human mind functions by grouping large amounts of things together. If you can group components into cards, into form elements, into basic elements and things like that, your editors are going to be able to find and understand the components a little bit quicker. They're going to have an idea of how to use those, where to use those, and what they're going to do.

Robust components inside and outside Canvas

Your components should be robust. And when I say robust, I'm a big fan of having your components be able to work inside and outside of Canvas. There's a hyperlink at the bottom of this slide where I give a lot more code than what I have on the right-hand side right now. But Drupal Canvas handles images much different than standard Drupal. And if you try to mix and match them, you're going to have a bad time. So in the logic that you see on the right-hand side, which is Twig, we check to see if the image source exists. If it does exist, we load Canvas's image component. Other than that, we just render the image, which is typically a render array. If you go to the— the hyperlink at the bottom shows a whole bunch of extra stuff that we do in there to remove markup and to make things function just a little bit extra better. Extra better. You know, by giving options to override lazy loading, override alt text, and things like that.

I'm a big fan of being able to support third-party modules. If you haven't used it, Drupal, I think it's 11.3, includes a really, really great new API called the Icon API, and it allows themes or modules to create a YAML file. The YAML file will point to a directory where you have a bunch of icons. The icons can be things like SVGs. They can be icon fonts or even images or something like that. By default, Drupal core only gives you that API, but there's a contrib module called UI Icons that gives you a little icon picker. Within UI Icons, there's a submodule called Canvas UI Icons that gives you an icon picker within the Canvas UI. And this is super nice, but how does this module know what to— like, to load that widget? It looks for a particular shape for the prop. And so you can see I have a hyperlink that shows where you find that shape. But the point is that if this module exists, you will have an icon picker. And if it doesn't exist, you will just have a normal— you will just have a normal field where you can type in the name of the icon.

Portable components

Ideally, your components should be as portable between your projects as possible. It's very common to be able to want to take code from one project, move it to another project. To do that, the first— the easiest thing to do is abstract commonly used styles out to CSS variables. That allows them to be easily overridden in things like subthemes or however else you want to do that. And it kind of abstracts things really nice. You want to do any type of logic prior to moving into the component. So in this particular case, we have a props object that we could easily pass into the component and then kind of split that object out within the component. But that props object might not exist within my next Drupal project. So in this particular case— like in this section— in this slide right here, we obviously split up into the multiple different props which are kind of derived from that one object.

Accessible components

Accessibility is obviously its own subject. And making components accessible could easily eat up a full 45 minutes, but there's some low-hanging fruit that I see a lot of Drupal sites kind of fail on. You want your components to be accessible. Like, there's a whole range of HTML5 elements that a lot of people don't know about. Things like the search tag or the dialog tag. All these semantic tags will give additional context to assistive devices like screen readers. You want to— you have no guarantee that a component is only going to exist once on a page. Components can exist multiple times on a page even if you don't want 'em to. So you do not want to hardcode any type of IDs. So in this particular case, we're using the random function to kind of create a specific ID. There is a clean unique ID filter that you can also use that comes with Drupal core. The clean unique ID filter sometimes has some cacheability issues, so I tend to use random because it works. It appends like a 6-digit random code.

And then you also want to have accessible names. The button for this particular component is just a magnifying glass that indicates a search, you know, it'll open up a search dropdown. If you're a screen reader, you do not see that magnifying glass, so you want to insert some type of accessible names. Drupal core comes with the visually hidden CSS class where it will allow screen readers to see it, but it is not going to be visual. So it's not gonna get into the way of, like, any type of design. And I'm a big fan of making sure your software— or your components work at a minimal level if there is no JavaScript. Sometimes JavaScript won't load on slow Wi-Fi connections or slow conference connections or if you're in a subway or out in the boonies somewhere. There's a CSS media feature. You can see @media scripting none. And then you can adjust your CSS styles if JavaScript is not available. And noticeable focus states. And this— I'm concentrating— or I want to highlight the outline-offset property, which is, in my opinion, like criminally underused. Outline-offset will move that focus outline either out or in. And moving it in can be a very good idea, especially if your elements, like a button, is directly next to another component. You don't want those outlines to be obscured because they might not be visible. You can move them inside, and as long as it's very apparent, it's— it'll work.

Design system and color theming

So, we have a whole bunch of great components now, but how do we hook them all together? And this is where your design system comes into effect. A good design system needs to be easy to— you should be able to easily select and change your brand colors. You should limit your content editors from shooting themselves in the foot. Flexible, but not overwhelming. And allow changing of the colors per component. Override it easily with custom code. And then also enforce that proper contrast for accessibility. A content editor should not have to know that text needs to be 4.5:1 contrast ratio or 3:1 contrast ratio depending on the size. I'm going to show you the end result on how we do it and then dive into details. You can see in this particular component, we have a— we kind of have a promo with multiple different icon cards. As I change the theme of the parent component, the text on the child components will automatically adjust. And this is super cool because as the editor changes that background color on a parent component, they don't have to worry about changing the color on any type of child components.

So we do this in 3 different stages. So the first thing that we allow our content editors to do is change the theme settings where they select a primary color and a secondary color. There's a new feature in Drupal Canvas called Brand Kit where you can do the same thing there. But once again, if you put that in Drupal Canvas, it's only going to work with Drupal Canvas. Or it's only going to work if Drupal Canvas is installed. So after we— after we have the primary and secondary colors defined within configuration, we output those colors to a style attribute on the HTML element. And from there, you can see we create a primary color. And that's mapped to that theme setting primary color. From there, we create a whole range of colors. And we're using relative color syntax. Relative color syntax is supported by all modern browsers. And I'm going to— there's a couple hyperlinks at the bottom that will explain it. But I'm going to walk you through it. We're using an OKLCH color space. LCH stands for lightness, chroma, and hue. And so right next to where it says primary 100, we say we want to create a new color. So we're going to use the OKLCH color space. And we're going to— within that parentheses, we have 4 different values. We say the base color, which is going to be primary. And then we have lightness, chroma, and hue. Lightness is the only one we modify. So you can see, as we kind of work down here, we're going from, like, 98% lightness down to 1% lightness. The chroma and the hues are just passed as C and H, which means that they're not going to change. So we're going to have a whole gradient of colors based off of the primary color right here. We do the same thing for our secondary colors, and we also have a palette of neutral colors, which are basically the grays.

From the primitive layer, we create a semantic layer. We have this concept of themes where you can have, like, a primary theme, a secondary theme, a light theme, a dark theme, a white theme, a black theme. And that's where you change your background colors. Within each of the themes, we have the exact same CSS variables. So we have 3 surface colors, 4 text colors, 3 border colors. There's also success colors. There's more types of colors defined below. But as you change between, say, the primary— from primary to light to dark to secondary, you can see that the semantic variables stay the same, but the mapping changes. And this ensures that as they stay the same, it always meets that contrast criteria. When we get to the component CSS, the component CSS, whenever it uses colors, it will always use those semantic tokens. So you can see the background color, we're using surface. Text color, we're using text color loud, et cetera, et cetera. So we're never going to have contrast issues. And this is a really big deal. And it gives those— it gives your editors hyper-flexibility to do this. And they don't have to worry about any type of contrast. Once again, seeing this in action, you can see the text color is dark, the icons are primary, but as I change an ancestor element, I change a theme on the ancestor element, everything nested is going to automatically adapt. So you can kind of see how that works right here. And what's really cool is you can have multiple layers of themes. I can go— say if I had a card in there, I can also set my card to primary, and that could exist within a black, and everything functions as you would hope.

Content templates in Canvas

I want to talk a little bit about Drupal Canvas because this is a Drupal Canvas session. Hopefully you were all in Ted's session a little bit earlier. He gave you a TED Talk. Content templates have come a long way with Drupal Canvas. Content templates allow you to drag and drop and create— visually style your content types. It allows visual editing of all view modes, but currently only supports nodes. There's changes coming down where it's going to support all entities, including users and other things. There is currently no option to override like a single node. So currently with Layout Builder, you can set a default pattern and— or a default layout, and then you can override a certain node. Canvas does not yet have that, but once again, that's coming. Canvas does not support all field types. So a couple tips. When you're creating your components that's gonna be using content templates, make all your fields optional. And the reason that I— that this is a good idea is because if you have a content type with a required— with an— if you have a content type with an optional field but it is required within a component, you cannot map that data. But if the reverse is true, if the content type has a required field but that field is optional within your component, you can map it. Currently, it's best practice to make your field optional, make your fields optional, and then you can wrap it with an if statement or something like that. There is a module called Canvas Field Components that can support more complex field types, like maps, tags, and things like that that Canvas does not support out of the box. Martin is the author of that.

Page templates and patterns

Page templates are relatively new. They were released less than a month ago. It replaces the concept of global regions in Canvas. And honestly, I'm like super, super excited about that because the implementation of global regions was not— it didn't work as you would expect. But page templates, in my opinion, have been awesome. It allows you to adjust those header and footer regions of the themes, and then you can assign— and you can assign a page to a template. So this allows you to do things like have a different header and footer on an individual page or something like that. I haven't used this in production yet, but I played around with it, and so far I really, really love it. Patterns are groups of components, and patterns, in my opinion, are a little underused. I don't see them by default in things like Drupal CMS. It's an easy win for an editorial team to drag a whole tree of components that includes heroes, images, text, proper heading levels, and everything onto the page and quickly assemble your pages. It also gives your editorial team references to how to do things properly. Once patterns are placed in the editor interface, you edit their— you change them individually. So if I drag a pattern from the sidebar onto the— into the interface, I can make those changes, and it's not gonna affect that original pattern. But I can create new patterns if I'd like. There's a couple contrib modules that allow to centralize editing of pattern— patterns if you want that functionality. The differences in these contrib modules are mainly within the UI, so if you're interested in this type of thing, you should probably just check it out.

Canvas wish list

I have a wish list. And I want to be very— Ted's like, no. I have a— I want to be very, very clear that I am not shitting on Canvas, because I love Canvas. So like— but there's a couple things that I really, really want. And some of them are coming. The first thing is exposed slots. Exposed slots will allow— an individual— to have a region within an individual node that can be edited, but like per node. And that's going to be huge. Restricted slots will allow a component author to indicate what other components can be nested within this component. So if I have a slot that is called card container, I do not want editors to drop, say, hero into a card container. I want them to drop cards into a card container. There's no method currently in Canvas to enforce that. But that's coming. And I would love Canvas to be fieldable. Right now you can't create a view of pages very easily or filter them or anything like that. There's modules that enable this. But out of the box, it does not support that.

DrupalCon Orlando

That is the majority of my talk, but I want to talk a little bit about DrupalCon Orlando because I am from Florida. So this is going to be in March. Let me get through this again. And we are organizing a trip to the Space Coast. So if you are a space nerd like me and you want to go to the Space Coast with a whole bunch of Drupalers, come to Orlando. In addition to that, we're having a talent show. This has been announced. There's going to be the first ever Drupal talent show, and if you have any type of talent, if you're really good at guitar or really horrible at guitar or you can juggle, go to the hyperlink at the bottom. It's on the Drupal Association blog, and sign up. And if you're not— if you register early, you will get a one-of-a-kind PHP Drupal elephant. This is only for early birds. I just kind of want to get everybody to come visit me in Orlando because it's going to be awesome. You can ask me questions about Canvas. You can ask me questions about components, or you can ask me questions about DrupalCon.

Q&A

Audience (unidentified) [34:26]

Thank you.

Mike Herchel [34:29]

Thank you. Someone has a question, or I'm going to call on somebody. Sally? Will there be alligators? Yes. In Canvas, yes. Over here.

Audience member 1 (unidentified) [34:59]

So I have a theme with traditional Pattern Lab-based, you know, atomic design. What does the future look like? Is it easy to convert to, you know, Canvas and, you know, single-directory structure? And what does the effort look like?

Mike Herchel [35:20]

Yeah. So the first step that you're going to want to do is convert to single-directory components. You can organize your single-directory components by atomic design if you'd like, you know, with the whole atoms, molecules, and things like that. If you're doing it manually, it takes a little bit of work. It's not complicated, but it's the type of thing that LLMs can easily do if you give it examples. You know, one of the best things that it's really— it's always a good idea to use SDCs if you're not doing that. And one of the benefits that you're going to have by using SDCs is it's going to split off the CSS. It's going to make everything a little bit more componentized, which will increase your— which will make your developer experience a little bit better. You don't have to kind of jump around. So to answer your question, you can convert it. I would heavily use AI if I were to do it because it is going to be very repetitive. It's not terribly complicated, but yeah.

Audience member 1 (unidentified) [36:25]

All right, thank you. Just one word of advice if you want to do that, make sure you're monitoring what the AI is doing, because in my case, it wrote about 130 hooks and preprocess functions when it was converting my theme. So yeah, you might have to say, what the hell are you doing? And, oh, I'm— oh yeah, yeah, you're so right. I will rewrite that for you.

Mike Herchel [37:01]

Yeah, what I would—

Audience member 1 (unidentified) [37:03]

Just a heads up. I mean, it's good, but you have to know that.

Mike Herchel [37:06]

You'll probably want to point it at some examples within Canvas. There are sample components and example components. Matt, is it true that there's sample components within Canvas AI that it can learn from? Didn't you talk about this earlier? He's giving me a— he's like, no. So yeah.

Matt Glaman [37:32]

To clarify Mike's assumption. For my demo, when I did the SDCs and agents and doing the page building, I had it look at the Mercury theme from Drupal CMS, or Byte, whatever it is. It went into their SDCs and then was like, oh, I know what to do now. Canvas itself does not have any sample data or evals, whatever you want to call them, that it could reference, but if you point to Drupal CMS, it goes for it and understands it.

Mike Herchel [38:00]

That's good information. Thank you.

Audience member 2 (unidentified) [38:02]

Thank you. We are soon going to Drupal 11 in our company. We have single-directory components, so I don't know anything about Canvas. I've listened and listened, so how easy, how fast I will get to this normal node page to Canvas, how complicated is that? Is that enable Canvas and you choose your components and it will work, or I will have a week of working getting this set up?

Mike Herchel [38:37]

I would do it incrementally. Install Canvas. If you haven't started converting everything to single-directory components, you can start today. Single-directory components are enabled in 10.3 by default. Convert everything over to single-directory components. At that point, when you install Canvas, you can run Canvas concurrently with things like Paragraphs, Layout Builder, whatever else you're using. There are AI either modules or scripts where you can copy over individual pages. You can maybe play around with those. I can't tell you how effective those are, though.

Audience member 2 (unidentified) [39:21]

Okay, thank you. Just a question. If you start with SDC, then they all live in this base theme somewhere, I guess, if you want to reuse them, but they're still kind of part of a theme at some point, so you're not— or did you find a way to have some package where you have your SDCs that is not part of a theme?

Mike Herchel [39:43]

Yeah, with Dripyard, we play— we have a base theme where the vast majority of the components live, and then of course they're pulled into Canvas via that way. And when components are overridden, they're overridden in either the child theme or they are the library— you can extend the libraries for the individual components if you just want to make CSS tweaks and stuff like that. But that enables you to update those— keep those components updated and things like that, if that makes sense. All right.

Audience member 3 (unidentified) [40:30]

Ted. So back to the little elephant. So if that's truly one of a kind, is it only the first person who registers for Orlando will get that one? Will they have to pass it to the next person?

Mike Herchel [40:41]

This is currently one of a kind because it's a prototype.

Audience member 3 (unidentified) [40:44]

Oh, all right.

Mike Herchel [40:44]

Thanks for the clarification. But when you register, you will get your own one of a kind.

Audience member 3 (unidentified) [40:48]

But it'll be 2 of a kind at that point.

Mike Herchel [40:50]

No, because it's going to be slightly different.

Audience member 3 (unidentified) [40:51]

OK.

Mike Herchel [40:53]

Have your name engraved on it.

Audience member 3 (unidentified) [40:56]

Yeah.

Mike Herchel [41:02]

All right. Thank you, everybody.

This transcript was generated from the session recording and corrected for names and Drupal terminology. Timestamps link to the moment in the video. Spotted an error? Suggest a correction on drupal.org.

Session page template for DrupalCon Rotterdam 2026. Video and transcript published by the Drupal Association.