About this talk
This talk covers strategies for integrating Drupal Canvas into existing Drupal platforms, particularly in larger, multi-site environments. The speaker discusses the advantages of Drupal Canvas over traditional methods, including improved component reusability and a new entity model for creating landing pages. They highlight various archetypes of Drupal setups, addressing risks and challenges associated with using Drupal Canvas, such as compatibility issues with existing modules and the need for developer familiarity with React. Furthermore, the speaker emphasizes the product's capability to streamline workflows by allowing front-end developers to create components independently from back-end developers. Overall, the talk advocates for the adoption of Drupal Canvas as a forward-thinking solution for modern web development practices in Drupal.
Full transcript
Hello everyone. I hope I you can hear me well. Um yeah, happy to have you. It's good to have such of a crowd. Thank you very much. Um so today we're going to talk about the strategies how to integrate Drupal canvas in in existing Drupal platforms. Here we talk about platforms which are not a small websites but are platforms where you have invested uh quite some time
and effort you know and you don't want uh and you would like this platform to benefit from Drupal canvas you know these are platforms that you cannot easily rebuild right um and just a note side note uh I have been doing a similar presentation on Drupalorn Vienna like a six months ago this was like a three months before um Drupal canvas to have it uh its official
release in December. uh the convers the the talk at this time was kind of a theoretical you know based on proof of concepts researches but now like a 3 months later uh we have already implemented Drupal canvas uh within existing multi-sight multibrand platform uh one that we started from uh scratch and we also have done very similar with something that is has been existing so we already
have some really uh stories to tell right and I'm I'm I'm very happy to uh to be here and to extend my presentation from Drupal convenience. Uh starting with just a uh short presentation. My name is Buan. I am originally from Bulgaria but uh in the last seven eight years I live in the beautiful town of Stasburg in France, you know. Uh if you haven't come, you're
welcome to come. It's a it's a great place especially around Christmas. Um yeah. Uh I'm part from the community for quite some time. Uh in June I will make like a 20 years. I will not have a gawa but I definitely are going to throw a party. So yeah uh if you are around uh I will invite you. Yeah. So yeah um yeah uh and uh just
to go to the topic uh just a very short agenda for today. We're going to compare the easiest way to build websites with Drupal. Today like what are the main building blocks versus the future building blocks which are provided by canvas. Right. Second one we are going to talk about the different strategies uh how to integrate Drupal canvas within the different archetypes. We talk about decoupled obviously
decoupled and also like a uh coupled drupal you know the the standard Drupal that is uh commonly used by many of us. Um we are talking about the risk and challenges because it is a great product Drupal canvas uh great module but it comes at a risk and I would like to share all the lessons that we that we learned the hard way so you don't need
to repeat them. Um and then finally uh I will spend some time talking about why Drupal canvas uh deserves our attention you know because I think that I heard many questions many conversations today uh uh I think it's the first time when Drupal canvas is uh on a big stage within North America you know in Europe already like a three months ago we already had a lot
of time to uh talk about but North America I feel it's a it's a first time when it's a uh become like a serious topic and it really uh there is this question why Drupal canvas why not layout builder we have spent so much time using layout builder why we need to change so this is something that we're going to talk about as well uh so without
a surprise uh one of the main building blocks within our Drupal website is a structure content you know usually for structured content we are going to use a content types field types for a visualization we're going to use a field UI display suit maybe layout builder maybe something else there are quite some modules which we can use four flexible landing pages which are part of each of
website. These are pages like a homepage uh campaign pages, topic pages, usually pages that are more unique and and require some flexibility. Usually today I guess you use paragraphs layout builder or block plugins you know like some uh in in some situation this is also uh something that I have seen that people are u using it. Uh the final main building block of course global regions. These
are header, footer, maybe some sidebars. Uh for this uh in a very traditional way uh within Drupal we use the so-called uh block layout. So we can position blocks in a different team regions and we can uh put some visibility rules you know when these blocks to appear or not. So these are the main building blocks of any uh within Drupal canvas. Uh first we start with
the structural content types. Um in fact uh structural content will stay. It is the most uh important uh topic today. Uh especially around AI the content the structural content should stay should be even more structured than ever right. Uh but where can it is uh how to visualize the structural content. You know there will be something called uh uh content templates and maybe you have heard it
already on a few presentation. So the content templates will be a way to control how to visualize uh your um content types right uh structured content types uh uh you can create as of now because it's a recent u uh fix I mean uh within a uh recent commits that come you can uh have a control of each of the uh display modes for each of the
content type and and you are in control to uh reuse the very same uh components uh that you're using to build landing pages to use for your content types which usually wasn't the case. Very often it happens that you build one component for flexible pages and some components for your search and content. So now actually you can use the very same components for the two type of
pages right uh yeah and example it is from Drupal CMS actually I strongly recommend if you want to try canvas Drupal CMS it is the go-to strategy you can install it you know there is a various way and to play with it and to experience what canvas is um yeah uh the next topic actually this is maybe where the most focus is paid right now as an
attention this is the flexible landing pages here there will be a much more disruption compared to the uh content types uh uh if I may say. Um so uh what is very clear is that um the landing pages today they're as usually a dedicated content type called landing pages campaign page homepage you know something uh something like this uh what is the new canvas page it is
not a content type anymore canvas page it is a entity it is a new entity type uh uh which come with pros and cons which we're going to talk about it so uh in the future we you will not create nodes you will create canvas pages and that's something that people should uh understand because you know there are some consequences from from uh from uh from this
fact uh the main building blocks will be so-called canvas components. The canvas components uh they can have a different sources. So uh a source is a kind of a plug-in where a different modules they can create like a to be exposed as a a canvas component. The different uh kind of a source plugins that are shipped with with canvas uh are uh single directory component, javascript components
and v plugins. So these are the main stable uh canvas components that you can use as of today. For the end user actually there is no any difference you know they do see all components you know where it matters is uh you know for the developers usually and what type of features you want to achieve with them. So for example uh uh single directory components and uh
JavaScript components are rather static components and uh if you want to show something like a latest news you cannot do it with them because these are static components. If you come from the React or Vue.js world, this is like a React component, something static, something that has attributes but doesn't have a uh usually doesn't have a dynamic capabilities. You can build things around with a JavaScript component
especially you can uh connect it to a um rest API and to pull dynamically data. But uh this is like additional effort I would say. Um but if you need a dynamic components out of the box, you have a block plugins. Block plugins. Uh these are you know views you can by default expose like a block you know views block all these uh things that you are
doing today within uh Drupal world you know if you want to build like a latest uh uh content or the most uh recent content you know and put it on the website on the website you just create uh views plug-in uh expose it as a book and this book uh immediately becomes available within within your Drupal canvas right there are two topics paragraphs and layouts which is
something very important I know that you use a lot um and uh and it's something that is a work in progress right now it is still not ready so once this uh I mean I will point to the meta issue that you can follow later on but once these two tickets are ready what you're going to take as a uh out of the box is that you
will be able to existing uh to reuse your paragraphs and your existing layouts as a canvas component so they will be available on the light on the left side of Drupal canvas so you can use them. Um yeah so this is about flexible landing pages. Uh then I will go to the global regions actually. Um here there is a new uh terminology uh or I'm not sure
about the name because it changes uh a bit. Uh but canvas regions uh so this is uh a way how you can override the the the teams uh regions I mean the the the regions defined by the team you can control them uh with Drupal canvas. Actually the power and the beauty here is that uh you can really use uh the power of uh canvas to have
a control of the layout uh you know uh to be able to uh give access to the end user to be able to change the header and the footer and to have much more flexibility especially if you're a multi-signed environment and you have a different department you know uh you might want to have a different layout of the homepage you know and that's something today with a
block uh plugins This is kind of a hurdle because at some point you have like a hund plug I mean 100 blocks with a different visibility rules which which become a hassle right with uh with canvas this is much easier to be uh um to be achieved. Uh and just once again to mention uh here the transition is rather easy because uh usually the menu navigation the
logo all these are block plugins which will be available out of the box to be used within your canvas So uh this is uh as is versus to be right now let's talk about the different archetypes that we set. I already mentioned in the beginning but I will just uh elaborate a little bit more of the different archetypes that we usually have within the Drupal world. I'm
pretty sure there is something that uh more exotic that I have missed but these are usually the the the main three. We have a decoupled Drupal. This is usually uh Drupal expose an API. You know there is a a front- end application usually on React and Vue. It consumed this API and what is very important is that uh routing mechanism of your website of your web application
it is managed by the front- end framework by react or Vue.js GS right the progressive decoupled it is um a solution in Drupal uh where the routing and this is a big difference with with the decoupled solution it is managed by Drupal right and you have uh some placeholders uh within the pages where you can embed a different front- end um applications right uh it could be
applications which are consuming data from Drupal or it could be applications which are consuming data from uh other data sources um so this is about the coupled and properly u the coupled uh the standard the multicide I think this is something that you know very well so I will not go to explain this one uh uh more it is a standard uh couple Drupal where you have
uh HTML pi pages created by Drupal itself um first one with the decoupled solution uh a few points uh and to kill the suspense actually Drupal canvas is still not ready for the decoupled Drupal so if you have a decoupled Drupal website maybe we can you can wait a little bit more but what is important is that actually um uh you should follow the project. Why? Because
first one Drupal canvas is a fully decoupled react application. It is a native citizen within the decoupled world which uh which is really powerful because you know many people are building decoupled websites which are pretty much read information from Drupal which is rather easy but to have a back office system which is completely decoupled which can manage the header the footer all the aspects of a website
that's something quite advanced you know this is usually the model used by many modern SAS uh solutions you know the many modern uh SAS uh uh headless solutions they are usually having a back office which is only exposing API and they have a various back office or front and front end applications of managing um uh the content or serving the content uh and uh that's something really
um u I think it's a great decision to be done like this um all this work that has been done by the canvas team it really boost the capabilities of Drupal to be a headless solution right and that's something uh which is uh shouldn't be neglected I think Drupal becomes more and more mature headless solution thanks for having Drupal canvas in the future we definitely see I
mean I was uh uh watching some a presentation of um um someone from the Drupal canvas team and I saw that you know the potential for having a food a full headless solution and managed by Drupal canvas is there but it's not a primary focus so please follow projects maybe don't migrate right now then let's talk about progress uh decoupled solution um I wouldn't I mean I
will focus only because the progressy decoupled solution usually have a pages which are rendered by drupal and some other pages which are really where you embed like applications like external applications I will focus mainly on this applications right so it's a rather simple solution uh usually um um yeah the uh first one probably the coupled solution ions uh and you know and canvas. This is something that
works very well together because usually when you build a previously decoupled solutions you uh today nowadays you create a custom solution you know you will create a custom content type you expose some slots within this custom content type where you can place a JavaScript asset injector you know there are different modules where you can place all these modules but the challenge here is that at some point
this gets out of control because you don't know uh where did I on which pages I'm using this application ation and how many times I'm using it which version of this application I'm using where I manage the configuration you know becomes quite of a uh unmanaged situation especially if you have many applications like this with with canvas this is exactly the opposite because all these components uh
you have a track you know on which pages are used which version is deployed and and also uh all these configurations they're managed via uh so-called JavaScript uh uh props So you have everything in a single place. Uh what is even be uh more beautiful is that these applications uh can be built by a front-end developer which doesn't have a experience with Drupal at all. Right? And
this really uh boosts the productivity of this front-end developer. So you can build this front end de uh you can build this application without touching or knowing Drupal. And that's something uh which I think it's a good way of uh welcoming more uh and other communities within our Drupal projects. Uh and the final thing that I want to mention is because um there is a uh I
heard some conversations you know about uh should we keep everything in a mon repository or like a two separate repositories you know this is a very good question I don't think that there is a straight answer depends on your use case depends on the team that you have if you have uh like a front-end developers uh which are working in a uh that they don't know Drupal
and for them having uh managing Drupal it is a kind of a problematic likely you might keep this aside in a separate repository. If you have like a more like a developers that they do know Drupal uh the monor repository it is the way to go but nevertheless the two options are pretty good and uh and uh and they will be working fine you know that's something
that you should have in mind um and just like how we are going to adopt Drupal canvas within a project like this usually this type of pages they do have and sorry for the progressively start of in the progressive of the couple pages but anyway um um So usually these type of pages where you embed these applications, they are not a big number, right? Uh and uh
and what you can do is just to activate canvas. Canvas will be working just fine with your existing uh page builder. So there is no conflict uh it will be just working fine. So and then step by step you can gradually start migrating some of these pages uh you know uh from uh uh from uh your custom approach for having a progressively decoupled pages to Drupal canvas
using JavaScript components. You know this is uh uh usually this is uh shouldn't take uh shouldn't be a big hurdle uh because once again I don't anticipate that you have many pages like this. This is the assumption that I'm uh working on. Uh and and and uh happily happily at some point you should all these pages should be migrated. Right? Let's say this is uh one of
the uh easy scenarios. Now I will go to one of the more complicated scenarios which is how to make Drupal canvas working for our standard couple pages. So first one there is no big bang here or I avoid please avoid it you know it should be everything should become step by step uh we will talk about learning Drupal canvas it is uh there is a learning path
and you don't want to start from day one replacing everything at once uh what I recommend you uh similar to the progressively decoup archetype uh you select a pilot you activate Drupal canvas on this pilot websites or one pilot right um and uh and then uh you start migrating the different building blocks one by one what I can what I can suggest is to start with the
lowh hanging fruits first one is the content templates this is something that you can definitely need to start uh that you can start uh uh as you can imagine this is something that is going to affect big part of your website because usually the majority of the the websites are like a structured content types so you can replace all this and already to see quite some of
the benefits of Drupal canvas. Uh second step uh will be uh really to um to replace your global regions. Once again as I explained usually the components that you're using in your global regions either language switcher block wo or menu navigation search block all of these are book plugins. So this should be like a once again a low hanging fruit that is working today. Um and then
becomes uh the case what about the landing pages you know uh about these complicated pages where we really want to start using canvas to to take maximum benefit. Um so first your approach will be not to migrate but if you create a new pages like imagine you have a new campaign this will be the best candidate you know uh you know to start experimenting within with uh
Drupal canvas. Uh so you can focus of creating new pages with Drupal canvas versus of migrating at this stage. Um yeah and preferably uh you should using the standard building blocks you know uh just once again uh we talk about SDC and block plugins right um uh and likely JavaScript components but this is with a asterisk because JavaScript components as you maybe know or you don't know
they do not support serverside rendering so if you have something which is critical from SEO IO point of view do not use JavaScript components, right? uh but you can still use it for non-critical um let's say uh components which are not you know uh uh so much important from SEO IO point of view which could be some dynamic content where you know uh this is a very
good candidate uh um to be used something about SDC because I'm going to mention something very important about SDC uh a bit later if you don't know uh SDC single directory uh component this is uh something that has been shipped since Drupal 10, right? Um, and it's something which is part from Drupal core, right? Um, it hasn't been seen as a big deal uh until Drupal canvas
uh adopting uh uh SDC. Right? Uh now we can see that SDC uh we can really see the power of SDC and you will see what I'm talking in a bit. Um yeah uh definitely along the way you would like to track the paragraphs and the layout support you know for the case uh you can anticipate the future migration. Um you know once this is done you
can start using your paragraphs and uh layouts. Um likely this should happen soon. Um what I can tell you is that once these modules are done uh you know you can keep creating new content you know uh and maybe start rebuilding some of the old content content reusing this uh new type of components with within canvas but this is one of the option you know uh I
mean there is another path this other path is actually which I'm kind of a thinking personally recommending uh is to make a migration from paragraphs and lay cloud builder to HDC components and uh block plugins and JavaScript components. This is something that I could imagine um that will give you the maximum flexibility and I will tell you why just in a bit. I do recognize that that's
not an easy task because usually this is not something that could be created such of a upgrade path cannot be created by a contrip module. um because it uh it is a very bespoke usually a solution within your within your website but definitely I do imagine this like a content migration you know using a migrate module where you can um use your website to read the content
and to put it within the Drupal canvas components. Uh still this is a theory at this stage. uh once I have something I will I I'll be happy to uh show you uh but why I insist on this migration right u what is very important uh that that I'm going to show you right now uh yeah this is a normal um acordon um component you know that
you have in many of your website usually the standard way to build this uh uh component is you know uh paragraphs uh sorry I mean you create paragraph or a book, right? And you put all the needed fields within this accordion. Likely you create like a multiple field in order in order to be uh um able to add like a multiple accord uh items within this uh
uh accordion. Uh within Drupal canvas at this stage uh maybe look similar. you will create a uh something called canvas pattern using uh some of the base components that you have and usually in this case the base components that we have this is a text component awardon container and aon item. So these are the three components that I create something called canvas pattern. Just to uh make
a p here canvas pattern um it is a way how to from your basic components you know something that is developed by developer. These are these base base components. You can uh aside builder editor could create a complex component you know just using these components and mix and match them uh within the canvas interface to create this reusable uh patterns. Pattern could be a section of your
page or it could be the whole page you know. So it could be quite uh um you know small and quite big. Um yeah but so far so good. Let's see what happens after there is a feature request. We need to have an image on the right side uh of aon item. Uh what do we do? The old fashioned way. Um we create a task for our
developers team. They add an image field. Um they put it in the backlog. They ship it luckily you know within two weeks. Uh all good within the Drupal canvas way. uh no code deploys is needed because in fact uh what the site builder editor will do he will reuse the pattern from the previous step. uh he will place it on the page and then he can just
pull another of the base components and put the image there right and actually uh and that's it you know nothing else uh is needed um yeah uh if but let's go for that uh we have another component um you know and this happens I know it happens a lot you know like this component we have something more something more you know but here we have like a
label uh uh batch label and we have a one button you know and uh yeah what we're going to do with the old way once again development cycle in two weeks if the backw walk uh and the velocity allows we're going to have this feature but with Drupal canvas this is not needed you know you can just pull the uh button u component and the batch label
component and to have this solution without any code changes right and that's a really yeah having a parag graph component. It is good but still drag you in the old-fashioned way of doing things and you cannot you can take some of the best features of canvas but you can get much more and this is where I'm talking about SDC Drupal paragraphs are great I think one of
the greatest drip modules out of the core right uh but this is way better uh and just something else in fact what you can do more is the site builder decide actually I can see this uh pattern you know uh this type of uh accord item appears more and more. So it the then the editor can create pattern on its own to save it and everyone else
are going to have an access to it and and they can reuse it as well. So that's really uh a lot of power. Uh so enough about the good stuff. Let's talk about risks because this is something quite quite uh uh uh important. Um so model compatibility Drupal canvas is way outside the Drupal comfort zone you know way outside the way how we build modules. It this
means that uh a lot of of the practices that we have been working with you know like a uh team rendering you know uh hooks are not working with Drupal canvas. This means that many contrip modules are not compatible with Drupal canvas. you know we talk uh uh many of them already are because uh uh there is a lot of effort this to be done and um
I know that there is a big initiative of how you know this duplication of effort to be avoided you know and this is something that it is seen as a problem and and there is a dedicated workforce uh to be solved uh but the fact is that modules like a scheduleuler they're not working many of the uh field types which lives in a uh custom sorry in
a country modules like address field like a map they do they are not supported by drop canvas right now there are workarounds but natively they are not supported and this is something uh you know to be uh well assessed before starting your journey because you might to have to anticipate some work to be done either to contribute to the community and to make this uh uh module
compatible which is the recommended way and and I'm I'm not going to send uh to say any other way this is the way you contribute to the community you make this module works and then everyone benefit from it. Uh the next big caveat which maybe not so much of a problem in US but in Canada it is a problem right and we really very close in Europe
it's even bigger problem right the moodling support it is still not there uh it is expected this to be ready end of Q2 I mean now Drupal canvas uh it has an official uh road map uh and 30th June it is the deadline to have this module uh I mean multilingual ready to work you can follow the meta issue form for more information. Uh the other uh
caveat uh that you are going to face if you once you start making this implementation entity references is used at scale with many of your Drupal websites. They are not supported by Drupal canvas. there is an issue that is working on it and also there is a workaround that we have been using um uh you know for our projects right uh the workaround is that you can
create like a a view a plug-in view uh a plug-in book view which you can embed uh instead of the field you can embed this block view to visualize your referenced entity this is the uh workaround that we have been uh using uh and then um a fining a final but super important training and this is not about just editors not just about site builders actually the
developers are going to be impacted big time you know uh it's really um I don't want to compare it in this way but if you remember some of you the shift between Drupal 7 and Drupal 8 yeah there is something like this and that's something to be uh anticipated maybe not at this scale but still it is a quite of a shift there is a new technology
that you should understand react so if you don't understand react that's something that you should understand um uh you should um um you know uh usually some simple tasks uh could take a while which usually before I mean of course that's a learning curve once this is warned and you know all these caveats you will be able to uh run quite quickly but you know there is
a this scroll walk and run uh you know uh situation that you have to uh um anticipate yes uh now the final section for my presentation it is really like a six reason why we have to do all this hurdle uh you know to have Drupal canvas. So the first good reason is Drupal canvas is finally and for real you know best-in-class editorial page builder experience you
know and it's not opinated by let's say a few developers uh but it's there is a quite some research done by the canvas team months of UX UI research a competitive analysis of a future forecast what type of what a site builder should be within in the new era of CMSS you know and that's something that uh you know uh I do see the value I mean
I just want to give an example the uh I mean the company that we have been doing this project is a uh fortune 500 company right uh they do have a quite of a big content team so the head of this content team she was telling that you know uh Drupal canvas is nothing else that she have seen in Drupal actually she she if I quote her
correctly she said that uh you don't need to have uh Drupal experience to work with Drupal and even more that you don't need to have any CMS experience to work with canvas which is something uh quite quite quite great. Um so uh definitely uh encourage you to to try. A second topic is really about um reusability of complex components. I already show you the example of patterns,
but have you ever wanted to copy a layout or a content from one site from one Drupal instance to another just with copy paste? You know, I think this is a request that I have seen a lot and I have seen so complicated API synchronization between these two websites. Uh this is not needed anymore. Actually uh a colleague of mine uh Lubumir, shout out for Lubumir, he
created issue Q. Now it is still not merged but this uh issue Q step on the um uh Drupal canvas API for copying uh uh sections and components from one page to another and now it makes it possible to copy components from one site to another. So just to show you the I mean it's a very quick video so you don't see a lot but uh so
you can copy the whole section or the whole page if you want you know you can go in the other website which is completely other u uh different domain and you know just copy paste and you have the very same components there. I mean very simple demo but you know it proves uh what I want to show you. [snorts] Um once again this is a real project.
It is not a demo done for canvas. You know I'm not from the canvas team. I'm an agency trying to get the best out of campus, next one, it's a really a value about progressively uh the couple Drupal and actually the able to mix skills from front- end developers which are they do not know Drupal which are quite some on the market right now as you know
the front end technologies are more and more popular. Uh, uh, AI uh, is trained on many of them. If you ask an AI without any particular uh you know context what type of comp I mean website to create it they will go with a react you know they will go with nextjs uh this is something that we need to leverage you know uh and uh this is
why if you have progress in the coupled approach of some of our canvas pages this is something that we can benefit from uh from uh all this um yeah and finally uh not finally but uh next in in in wine we talk about boost developer productivity. I will give you two examples within within our project. Uh usually the standard way of um just checking the time. The
standard way of building uh components within uh Drupal is we create a task for the backend developer. They create a paragraph, right? uh then we assign it I mean with the field that are needed and then we assign it to the front- end developer and the front front end developer style it you know and there is some back and forth at some point you know uh within
if you build a CD uh uh HDC component uh this is not needed because uh the front- end developer can start the HDC component uh because you don't need to create fields anymore you just create like the so-called com I mean the component props right so you don't need to create like anything within the back office, right? About this static component, you just have um this component
created from start to end from a front- end developer. This saves time, you know, uh and and it's something that uh it it really boosts the time to market. So you you you engage less people and with uh and with uh less you achieve more, which is uh you know really uh the a good description for productivity. Um, another example that I'm going to show you is
uh really about how to benefit from actually from uh from AI um uh you know agentic development model you know um uh uh uh when we are working with Drupal canvas because Drupal canvas uh I mean the the demo that I'm going to show you we have uh our developer is copying a Figma component a link to a Figma component um and and uh it gives this
link uh uh link to a Figma component to uh to a skew uh a quad skew. This skew is written by our in team and and it's something that uh it is has the context of the project and it has like it explains where the components are and you know some other things which are within the context of the uh project. So we have this console we
have this uh uh Figma to HDC skill. So we gave this uh to our uh uh shell script you know and and uh what you're going to see is that it will create uh HDC components uh actually it will be plural. It won't create just one component but because it will uh try I mean because the key is written like this it will try to understand what
components exist. So it will see that the button components exist and and it will and and it will not create button components because if you try to uh reuse them uh and also it will think about how to make uh uh these components more granular and more reusable. So it will create at the end like a two components and it won't create like a button component which
will be the uh end result. And now you can see here we can place this u uh component which in this component there is a swat created where we can already place the existing button components. So this is a real thing we have been using this you know to create uh uh our development for for the project that I have been talking. So uh this saves time.
The thing is that uh what we now see is that maybe there is no so much need to develop new components when you have patterns you know. So actually uh this goes in another direction which I don't have time to demonstrate right now but the question is how I create like a patterns uh I mean and don't develop components because actually with canvas you don't need so
many components at the end of the day you need just more patterns um yeah this is the example that I wanted to show you uh moving forward um yeah another reason that I didn't talk about it but it's quite important I have seen this a lot with many of uh uh many of the big platform which are a lot of a lot of around governance. But at
some point there is at this moment you know we want to create more immersive content you know and this immersive content is something which usually requires quite of some um you know um development cycles. uh maybe requires you know to uh use a another external JavaScript library within the whole CMS and to mess up you know the whole uh um in I mean the whole codebase just
for a sake of creating one um component which has some fancy uh animation. This is not needed anymore because uh uh with u especially with the campaigns you know if you want something immersive you can use Drupal canvas pages with JavaScript components to embed uh and to reuse external JavaScript libraries only in this particular component and you don't need to mess the whole codebase uh adding yet
another JavaScript library just to have like a few components for your campaign page for uh next year. So that's something that uh I do see uh use cases where uh canvas could be quite uh uh valuable and the final reason is really canvas is future ready. I mean I guess you saw uh the D keynote many of the AI examples they have been including canvas. I guess
you haven't seen any AI demonstrations with layout builder and paragraphs if there is anyone. >> Oh okay. uh and that's something quite important you know there is a big team behind canvas behind AI they work together uh and actually if innovation is coming in Drupal it will come around canvas of course around some other topics but in terms of page builder the canvas it is the future
of the page building in Drupal and uh if you want to make the right investment start experimenting with canvas when you feel that the right moment is come for it is coming for you start migrating. So this was from me. Thank you very much. Uh and so uh there is this QR code if you want to leave a feedback for the presentation you can uh scan it
and leave it and also if yeah I will just open the stage for question. Yeah please. >> Yes. So can you talk about um if I'm using cameras to build pages what's the difference like what's the benefits for SEO JEO part compared to the old way >> uh >> like the page rendering like yeah performance speed >> as long as you I mean the performance if you
use SDS uh uh SDC component and block plugins I would say it's even better because it has a very well isolated uh CSS and JavaScript because it's really Everything is bundled in a single component, right? If you use JavaScript components, that's another story. This is something where you have to be careful if you use because it could have uh uh because it is not server side rendered.
So the uh SEO and IO engines, they will not see this content. I mean usually. So uh and just something else before continue with the questions. Uh if you have any further questions uh or you want to talk with uh or you come with with with some other questions you can uh open the askjakawa.com website and to uh send your queries there. Any other questions? Yeah, please.
>> Um what strategy can you suggest for sites heavily using tweets? So we have a lot of sub themes. We uh have components using paragraphs and then we uh style that or arrange that using twe. >> Yes. we start uh adopting canvas how can we ensure that we migrate that >> yeah and maybe I need to repeat the question as well because there is no microphone uh
yeah uh uh the question is what type of strategies I would suggest for a websites which is having a base team many sub teams and heavy uh tweak for the overrides of the templates uh yeah strategy number three is the one way to go right but where the challenge will be here is uh yeah you can use paragraphs on some time and then the question is do
you want to migrate to SDC or not? migration from paragraph to SDC. Um it is a heavy lifting. We can talk about it like some there are some skills which we can share you know of how this migration could happen you know. Uh I mean so the heavy lifting is done by an agent and then the finetuning is done by uh by a person right but it's
a it is a trip you know it is a journey that is not a easy one. peace >> for projects that you're using both and components what does your workflow look like especially if you have multiple developments on the project how are you keeping the sources accurate >> yeah uh in fact uh uh in the project that we have been working we do not use JavaScript components
as much right actually there is only one use case which uh we talk about the third party integration which is pulling data from somewhere else you know so uh in this case uh if you put the JavaScript components uh uh away uh the workflow is not something different right from from the standard Drupal workflow. The only thing that you need to have in mind is that usually
many of the components will be written just by a front-end developer and not by the backend developer. This is the only change that I would see otherwise you have like a git workflow and everything works as uh usual. Yeah. Any other questions? Uh yes. Um in terms of the possibility of server side rendering given that we're talking about react apps um and particularly if you have an
aggressive caching strategy where you can serve you know serverside rendered react app out of cache um is that even possible >> uh I was I mean that's a question that actually was asked today uh on uh on um no or yesterday on um on uh one of the sessions from the Drupal canvas teams you know and I will rely on this answer. Uh he said that today
actually this is not possible right uh and they will be working to make it possible but once again the JavaScript components is something that we have to be extremely careful using because they do not benefit from the Drupal uh caching system. So we need to be extremely careful right that's >> but they could benefit from a caching as long as you can do server. Yeah, if it
but this is what he was talking that in the moment when there is a possibility for server side rendering then this will be possible right but in the moment it is not possible in the future yes absolutely >> so I just I think I'm asking the same question sort of just uh what about like for example metag or something uh like can can you do that >>
no right now JavaScript component doesn't support but once again JavaScript JavaScript component is one of the way Actually uh today in our project that we have done we do not use JavaScript component. So JavaScript component is just one of the options uh you can use metatax if you have serverside rendering without any problem you know uh I mean like a you have an XJS application you have
a back end and and front end you know and it and you have metatax without any problems right any other questions yeah please >> so kind of similar to question that gentleman asked we use paragraphs a lot those paragraphs are mapped to a DC >> Nice. That's very nice. That's a Yeah. >> So, can that situation work with canvas without complete having to do complete migration? >>
Great question. Actually, having this situation makes the transition from paragraphs to SDC way easier. >> I mean, because usually these SDC components, they will not be recognized automatically by canvas as a components as a building blocks. But with very small tweaking you know there are something that has to be added in the YAML files of these components you know just you know to make them exposed to
Drupal canvas right in this case you can start having these components already available within Drupal canvas. So actually you are way closer to having this full uh power of Drupal canvas. >> Yeah. Any other questions? Yes please. Um, we use uh layout builder for our landing pages, but I want [clears throat] to use the canvas pages in place of the landing pages or like instead of >>
like replace I want to replace. >> Yeah, it makes sense. >> But our landing pages are built of uh structured content from other content >> Is like is there a way to integrate that with canvas like pull in content that they've already created elsewhere that they can just plug in like a pattern or >> Yes. Yes. Absolutely. I mean in the general case landing uh p I
mean the layout builder is using blocks. In this box either you have like a static box which are like a title and uh let's say body text you know like something very static or you have like uh uh another block which is has a entity reference to another content type like a a few products or or a few case studies right and this is absolutely possible. I
mean uh I mean uh um it will be absolutely possible. Uh so there are two options right? First one, option number one, you can create a block a view block plug-in. You know, you can have exposed filters there which are like a configuration and there you can make a configuration. For example, please show me case studies which are with this category, right? And this is something that
we can do today at the end of Q2. The once the entity reference support for Drupal canvas is done, you will be also able to make this uh direct entity reference within from HDC components to these products. Yeah. So thank you. >> No problem. Any other question? Yes. >> So canvas is more of a visual builder. What about metadata behind the scenes data information components to manage
that or is that managed at all? Uh the metadata you you refer to SEO metadata or uh schema work schema. >> Yeah. Schema. Yeah. Uh no uh this is something that each of the canvas pages if you because there are two type of pages you know there are nodes which will be still there for structural content and to manage schema uh data in the usual way. You
you don't change this one. Uh and then you have like a canvas pages. the canvas pages in the right side bar they do have uh I mean fields to to manage all these uh schema or and metatags in the old way I mean in a similar fashion like notes so this is absolutely supported right >> yes >> so if instead of using the node page you're using
a canvas page um is there revision history either when it comes to the content or even the components themselves >> absolutely yes actually this is one of I mean it's a requirement to have canvas to do what it's what it does. Yeah, there is a revisioning on a canvas page layer. So you can roll back any any of the states of the canvas page but also the
uh components itself they do have a revision. Imagine you have a component with title and description then you want to add a another field in this component. Actually this component has its another revision. So you can maintain for time being the two revisions of the very same component. Right? So that's a but that's a totally different I mean it is something that doesn't exist today in Drupal.
So uh it I'm not sure that you can see the benefit but you know in a the long story short yes there are many revisions. Any other questions? No. Thank you very much and see you soon. Yeah. [applause]
