Hi everybody it's Sam at Mixed Up Craft, thank you for watching my tutorial today. So this one starts a little bit different to my normal tutorials because usually I make two of everything but in this instance I don't need two Christmas wreaths. So I have already started putting a lot of it together because I need a lot of pieces for this because I want it to be a very full and large wreath. So what I've done is I've got all these pieces here. So first of all I'm going to start laying down the base and then I'm going to start introducing other bits into the wreath and I'll talk you through that as we go.  I will try not to keep it that long because I will speed up a lot of bits but I will talk you through each stage. So first of all I've picked up these here. These are Duke glitter ribbon rolls and you get 2.7 meters and from that this is the last piece. I've got all of those pieces that you just saw me that you know I just had on screen. So what I've done is the width of this is five and a half so I've cut each piece by five and a half so I have five and a half by five and a half square you know sections and then for each one I'm tying them together using this candy cane pipe cleaners. You get 60 in this pack from Simply Creative. I've shared this in tutorials before and I've shared links to it so I should find them quite easily for you. They're either 99p or 199 they're very inexpensive but you can use any kind of pipe cleaner it doesn't matter but I wanted the candy cane because there may be parts of it where you see this and it just will all add to the final you know finished piece. So all you want to do is concertina folds you want to start with a you want to start and end with a mountain fold so it doesn't matter how many folds you have in between as long as you start and end with that mountain so I can just get another one in there there we go. You just want to have that rolled you know piece on all of the sides there to give you that nice bow effect and then I'm just going to pop that around there and then you just want to twist really tight the pipe cleaner so it holds that bow in place okay it's as simple as that. Now I don't actually know how many I'm going to need yet because I haven't done it so I'm just going to bring my ruler in now this here is a this was I picked this up from the craft show and I shared this in one of my what did I get videos but this one here in fact the ruler is not going to work let's use my grid so where are we one two three four five six seven eight nine ten eleven twelve thirteen fourteen fifteen it's a sixteen inch ring but I've got the inner ring and the outer ring so what I'm going to what my idea is is to put a load of these really tightly around the middle ring and then a load around the outer ring so you'll probably see me cut some more of these but that will be done high speed because I've showed you that I don't need to show you how to make every single one because they're exactly the same I'm not a wreath expert this is I mean I've made something similar years ago but it was something that I gave away when I moved abroad so it's nice to actually make something again but all you want to do is pop the two sides over the metal there in fact I'm going to pop it on that one just to start it off and then just twist them again like you did now I'm not going to cut any of these off yet because I may want to attach other things because you can thread it through you know I might want to loop something else around there so they're quite handy because they're that bendy metal so I'm just going to keep them at the back but now you can see I've got that bow on there so I'm going to go around again and you can slide these around you know you can really kind of you know just manipulate it to you know sit where you want really and the more that you pack into it you know the tighter it's going to be and I want this full this is going to be very very big it might even almost touch in the middle but that's what I want so I'm not really being too precise on where I'm putting these at the minute I'm just sitting them on tying them off because I can always move them quite easily and you know it's very easy to add more in as well but you can see they're no real pattern because they move very easily but I'm just going to go around and cover that inner circle and probably start on the outer one if I've got enough and then you might see me cut some more if I need to add more again okay so I think I'm happy with where I am at the moment I've still got one two three four five so they might come in handy you know once I start moving things around I might find some gaps but it's pretty full right now you can see it's a really nice size I think now we're probably looking at let me look on my max well my mat's 24 inches wide and it is yeah it's it's hitting the ends so yeah it's a really nice size I'm really pleased with it so far all these bits here the the wires like I said I'm keeping them on until the very end because then I can just snip them off on the back I'll just flip it over so you can see how it looks you can see everything is attached to the wire there so it's nice and strong it's definitely not coming apart it feels really solid actually so okay so I'm just moving on to like the accessories and stuff and I keep forgetting that I need to kind of film little bits just so you know where I am so the merry Christmas if any of you saw my what did I get video when I came back from the craft show I picked up this it's just one of those wooden laser cut ones so I've just popped some white acrylic over it now I'm kind of in two minds whether or not I'm going to add some gold leaf to this I need to kind of lay it all down once you know I've got all these pieces ready and also when I when I picked up these pine cones I didn't want to keep them brown I did say I'm going to do something with them and all I'm doing is just with that same white is just kind of brushing up so you're just coating the tips of them it is a little bit of a messy job but I love doing this kind of thing and you just get a really nice effect and I think it just ties everything together because apart from the the jute that that craft you know that brown color I don't want too much brown actually on this wreath that's just the main brown that I want so by adding this white it I think it shows up the pine cone more than it does if it's just like that that can get quite lost whereas now it's got that white highlight on the ends so that's all I'm doing so again with this one here you just brush up you might have to go over a few times get the odd bit coming off there just to kind of fill in those because this is a really thick one but can you see it just really does show off the shape of the pine cone I think so I'm just going to work my way through that these ones here they all come like this and they are from dewcrafts again I shared those ones they're the large decorative berries but I don't want the wire and the actual ends of the wire is quite sharp so I've just pulled them all off so I just need to pull that one off but I just wanted to show you how they come but you just pull the wire off and then you're left with these glittery little balls and again these ones here are the smaller ones so these are your you get 24 pack they're the decorative berries and again I may pull them off I'm not sure because what is quite nice with these I've got covered in white there I don't really want to touch it too much but you can twist the wire around like your pokey tool or something and that can look quite nice but again it might be a bit sharp so I'm not sure I want to do that and then I also pulled off the wire from the tote stores because I don't need that just some hot glue and this is going to be yeah I'm really looking forward to putting it all together so a lot of prep doesn't take long this isn't taking me long to do so far I'm about let's say just over an hour in so you can get quite a lot done and this kind of paint dries really quick as well so I will be back when everything's finished and I'm ready to stick it all down okay so I think I'm pretty much almost ready to put everything together I just want to make my big ribbon bow which I'm going to show you in a moment but there is the Merry Christmas so I've just added glitter over the top of it and it looks really nice that's dry my pine my pine my pine cones are pretty dry actually I think we're ready to go with those I was a little bit aware I think it's on the bottom but be okay and then the Ponsettia flowers that's how they look so lovely and big I've made these before on the channel so if you just click on this link here you'll be able to see how I made them and it's using this one here which is the ultimate Ponsettia dye set it's beautiful so many of you have already received it and said you just couldn't believe how large the dyes are they're so nice you can do this in all different colors and you can certainly do them in maybe like bright yellows and things like that for Christmas and for like springtime pink colors you could do like a birthday bouquet so many nice ideas with that then I've also got these little trees here I think I'm going to go for the little ones I've also got the larger ones here I don't know if I kind of laid them on the wreath and I thought they might look a bit too big I've got these really cute little gingerbread men they were actually a garland there's loads more I've just got a few here so you can see they're all joined but I've just kind of snipped around by their hands I just thought they'd look cute on there I've got this which I want to hang underneath the flower so it will actually dangle from the wreath I think that might look nice and that was attached to it so but it looked a bit naff and you could see all the glues and everything but I've just removed it you can see how it was but I will probably use these bits at some point but I just wanted to do the bow so what I've got here is some wired ribbon it isn't the one that I really wanted but it wasn't wired the other one so it's not really going to work but I think once the bow's been made and everything else is added it should still look really nice so you want to basically make um I've done this a while ago in a class so I'm just trying to remember how you do it but you want to make a loop it's entirely up to you how many loops you make them and how big that you make them so if I just give you an example so that is a loop okay but then you will end up going like this in the in the center of it and then that will become one of your you know ribbon kind of loops so if that's the size you want then perfect and I think that's probably about the size I want you're gonna I'm going to have quite a few of them so it will be quite big so my loop so each side of the loop is what's this one two three four five six seven eight nine so 10 inches okay so it's 20 inches all together because that's like I said there you can see and then I'm going to go back around and down again so that's my second loop and then up again so my third loop four and fifth look at that it fits perfectly I'm not too worried about having a tail I just want a big it's almost like you know those kind of bows that you've put on like the top of a car or something so where I've got my two ends I wonder if they're at the same end yeah so there's the end of the one in the middle and there's the end of this one so what I'm going to do is bring the loop out this way and then have it so that they meet in the middle that way I can pinch them together like that okay kind of do like a concertina so again I've got a valley on each side because we're going to pull all of these pieces out in a moment like so and then I'm just going to grab some of my pipe cleaner here pop it in the middle and twist that really tight okay so right now you'll have something like that and then you can kind of bend this up and start pulling out so as you pull each one out so pull it out and then twist it okay and then I'm going to pull the next one down in fact no I'll pull the top one down because that's bigger sort of the big ones at the bottom so pull it out it doesn't matter if they all come out because you can start but once you add it onto the reef you'll end up kind of you know playing around with it anyway as well but pull that out that's the end of that one actually so I need to twist that off like so and then you can open them back off but you have to twist them just because it kind of helps shape it really yeah I'm happy with that until I start putting everything together anyway so I'm just going to sit that to one side and I'm going to put this all on high speed but I'm going to start laying everything down so let me just bring the wreath in just so you can get an idea of what I've got in mind okay it doesn't quite fit in but I can get an idea so that's probably going to go up there you can see the big bow is going to be here and I do have some more ribbons so I may well be able to do like a nice tail hanging down but I don't know about these so I might have maybe one there one here so I just don't know I actually think I'm not going to do them and I'm just going to cover it with these with a little Christmas tree with the little like star and the little candy cane are quite like those little kind of groupings this is going to go at the bottom I don't know whether to have this going right through the middle or at the top so like I said I'm going to be playing around a lot I'll talk you through exactly what I ended up doing I've also got all these which I want to kind of stick on first so yeah I just need to kind of get my head around exactly how I want this to all come together okay so this is what I've done so far so you would have seen me kind of because it was hard to keep this all in shot but I really like these little sprigs and they're from that where the bobble was so on this piece here so I want to get some more bits like that because I think they're going to look really nice nestled in just to add a little bit more green but I just need to tidy up underneath because you can still see a few of the pipe cleaners coming through but again if I just bring it up close you can see there's so much going on on this I absolutely love it now I do have this lovely ribbon here I've got more of it but I'm going to have that as my hook so I'm going to kind of do something like that and then with the pipe cleaners have that right at the top here and then at the very bottom I still want to have this kind of hanging down but I think the easiest way to do that is I'm just going to use probably this pipe cleaner actually if I thread that through yeah and then I'll be able to just literally loop it and so I want to make sure you can see it you can't see anything right now I'm so sorry but this is just such a big piece you see it hanging down there probably needs to be a bit longer actually you do feel like that I think that'll look right and kind of split it apart like that I'll have to do that when it's hanging you'll see that in the pictures and you'll see it obviously hanging the ribbon I can just attach behind it that's about all I can really show you it's it's pretty much done I just need to get some more of these little sprig pieces here you can see they're just they just look really nice I like just they kind of finish it and they can certainly be like popped in you know as and when so yeah I'm really pleased with it it's all come together pretty much how I kind of wanted it too so I'm happy with that so yeah thank you for watching I hope it's inspired you to at least get the base going and then it gives you an idea of how you can kind of just start placing everything hot glue is going to be your best friend because now everything you know they're solid pieces and this is definitely not falling apart and as long as I get a nice box to keep it stored in this is going to last me many more years to come so I'm really pleased that I hope you've enjoyed it I hope it's inspired you thank you for watching please give me a thumbs up if you've enjoyed today and subscribe to my channel so you get to see more thanks for watching bye


Hello everybody and welcome to the headless and the content authoring experience roundtable. I'm Kim Pepper, tech director and co-founder of previous Next. Today's roundtable will be kicked off with a presentation by Stuart Clark. Stuart is the senior developer at Reality Loop and has been actively involved in the Drupal community in Australia and internationally for more than 15 years. More recently his focus has moved to decoupled Drupal development and is the project lead of the Juxt.js framework. So following Stuart's initial presentation, we're going to do a roundtable discussion. So it's a slightly different format from what you've had today. We've actually got a number of esteemed panelists who are waiting and ready to join at the end of that talk. But we'd also like you to participate by asking questions in the Q&A tab at any time. Then during that discussion session I can do my best to add you to the stage to ask your questions. So this has to be one at a time. So we'll just see how we go with that. We might end up just me reading those questions out. This roundtable is sponsored by previous Next. And previous Next are a team of Drupal design development and hosting experts located here in Australia. And as you might have heard Dries mention in the keynote where long-time contributors to the Drupal projects in terms of code contribution, community organisation and helping to run events such as Drupal South. We're also a sponsor of the Code Sprint tomorrow which I hope you will attend. I'd also like to take this opportunity to mention currently hiring front-end and back-end developers. So contact us through our website or send an email to jobs at previousnext.com.au if you're interested. So with that, over to you Stuart. Thank you very much, Kim. Good afternoon everyone. I am Stuart Clark and this is Headless and the content authoring experience. I am a Drupal developer as Kim said at Reality Loop and I've been using Drupal for about 15 years. And as of recent, again, as Kim said, I have been working on a fully decoupled Drupal framework called DRUXT. That's generally what you'll find me talking about. So again, as Kim said, the format today is we're going to have an open discussion after this initial lightning talk. I do encourage everyone to talk amongst yourselves in the discussion forum, use the live Q&A and get involved in some way in the conversation as a whole. So this is what I'm going to be covering today. A little bit about the terminology about headless, decoupled Drupal as it stands. The technology including, of course, DRUXT and go through some demo before we go into a discussion. So the terminology, the first thing I want to talk about is the traditional CMS and that's something that everyone should have some understanding of because the traditional CMS is really just Drupal. It's Drupal running in a lampstack and the idea is that your content authoring, your content rendering and your content storage is all done in Drupal. And it's powerful. Like you can't deny that Drupal as a content management system is an amazing thing. But as the technology in the front end realm advances, Drupal needs some form of decoupling so it can use that technology. Progressive decoupling is one of the more common ways of doing that. It's something that I personally don't have a huge amount of experience with. So that as part of the discussion today, I'm going to bring in some guests who have more experience that they can provide some context. But progressive decoupling is very much like your traditional CMS. The idea is still Drupal running inside of a lampstack. It's still the content authoring is done inside of Drupal. The content rendering is done inside of Drupal with the assistance of JavaScript. And the content storage is still inside of Drupal. This image on the slide you can see here is taken from a, I believe from a blog post by Matteo from Lullabot's progressive decoupling made easy. And this is an example of using progressive decoupling on the authoring experience. So the ability to drag and drop JavaScript blocks into the interface. The alternative to progressive decoupling, which I do have more experience with is fully decoupling. And fully decoupling changes the architecture a little bit, because you're no longer rendering your content inside of Drupal. You are doing your content authoring in Drupal. You're doing your content storage in Drupal. But the content rendering is done inside of a Jamstack. Be that Gatsby or Druxed or any of the available frameworks on the market. And this gives you a lot of control over what you want to do with the rendering layer. A lot more control because you can just use your view or react components directly in rather than trying to move them inside of Drupal's rendering system. You have control of the router system. So you can have components that live outside of the router system. And it can take the full advantage of the front-end framework in that case. So, you know, next or next or Druxed. And unfortunately, the downside to this fully decoupled approach is that there's not as much skill transference. You don't have to know Drupal to go fully decoupled. It's kind of the point. So that does mean that your Drupal developers who have a large amount of experience building front-ends within Drupal, that knowledge doesn't necessarily transfer. Although it can. And the other side of fully decoupled is that it doesn't necessarily have to be content authoring in Drupal as well. It can be content authoring in the front-end. And that's headless. So this is one of the reasons that I wanted to talk about terminology first is I see a lot of different opinions on what headless is and what decoupled is. A decoupled site doesn't have to be headless, but a headless site has to be decoupled. Because if you're still doing your content authoring in Drupal, it's not headless. It's simply decoupled. So the idea of decoupled, of headless, sorry, is fully decoupled plus a decoupled authoring experience. Hence the title of the topic today. And this here is just an example of a prototype that I've been building alongside this session. And I will go through shortly. But the idea here is that Drupal and your database still lives in your LAMP stack. Your jam stack is where the author comes to make their changes. So editing on the front-end. However, the important thing to take from this, and it's not in this graph here, is that your authoring front-end does not necessarily have to be your display front-end. So the benefit of decoupled, the benefit of headless, is the ability to have multiple different applications for multiple different purposes. Decouple the presentation layer and you get a front-end. Decouple the authentication layer and you get an authoring experience that can potentially be taken offline and taken with your content authors instead of coupling it to your presentation layer or coupling it to your content management system. So the last one that I wanted to touch on is serverless. And serverless is, this is my concept of serverless around the idea of Drupal and the idea of fully decoupled headless. And this is something that I put together for a talk recently in Drupal Camp Colorado on using Tome as a way to do static things, but not necessarily Tome as a static site generator. So Tome is a Drupal module that lives in the back-end. So if we have a look at this chart here, we can see we're doing content authoring in the Jamstack and we're doing content rendering in the Jamstack. But to make this serverless, Drupal itself along with the database and a module called Tomesync is running inside of a Gitpod instance, which is a cloud IDE. So that means that you can spin up an instance of Drupal with your content coming from Tomesync into your database inside of Drupal. So you can do the development as the author within the Gitpod instance, make all the changes you need to, and then deploy that static content to Netlify. After doing so, you can then turn off this whole Gitpod instance here. And that results in Drupal not running in any way whatsoever, but a fully deployed static site running on Netlify that a user can browse to. I'm not going to give you a demonstration of some of that, but I'm going to risk trying to do some live demos if time permits. I'm going to jump to the technology before I do that and talk a little bit about Drust itself. So Drust is a fully decoupled Drupal framework. It is open source. It's all at drust.org. There's some links in the end that you can have a look at as well. It provides server-side rendering and client-side rendering using the Nuxt.js front-end framework, which is built off of UJS. It also is a static site generator, but it's a Drupal-centric framework. So it has support for things like entities with schema support so that you can manage your displays in your Drupal instance, but have the front-end understand how Drupal wants your content to actually be rendered. So support for decoupled menus, decoupled blocks, decoupled views, and a decoupled content authoring experience as well. I would be remiss if I didn't mention Gatsby. However, I have never actually personally used Gatsby. So again, I have people with me today who can hopefully talk to this a little better than I can. But Gatsby is another highly popular static site builder that uses React instead of View. And it has strong Drupal integration. I mean, most people who have worked in the decoupled space know of Gatsby. So I probably don't need to go on more about that. And lastly, as we're running low on time already, I think, here's some resources that I will leave on screen. But I'm going to jump across to a quick demo. So this is a Git pod that I'm running at the moment. And it contains a running instance of Drupal and a, that was there, and a running instance of Nuxt. So this is the Drupal site here that you can see. And this is running from within this pod. This is a front-end, which I will reload, that is consuming the data from that backend. So you can see here two pieces of content and a whole bunch of stuff inside of it. So if we have a look, the whole idea of headless is that you have to be able to edit your content in the front-end rather than the back-end. So I can just double-click here. And that opens the editing experience and loads in this particular form. This here is built up with paragraphs. So this here is a paragraph field. And we can drag and drop these around as you are doing paragraphs. And we can close that to have a look at what it would look like once we've made the change. We can click this instead of double-clicking. We can change the title here, test one, two, three. And we can also add additional paragraphs. So as long as your site is configured correctly in Drupal, this can consume the data that you've made available to it so that we can just add in some additional things here. And you can either edit them up here or down here, although this is still a proof of concept. So it's not a fully fledged product, but it's an example of one of the approaches that could be used to build headless sites with Dructs as a framework. To follow on from that, if I just hit save, that probably won't work entirely, but I'm going to have a look at the back end here. And I'm going to go into this tab here. And I don't think it did save because it's a prototype. I'm just going to reload and do one more test. And if I get a second demo fail, I will not do it again. So I'm just going to change the title of this and go, hello world, how are you? And I'm going to go down here and hit save. And if that worked, there shouldn't be any display because I haven't built it yet, but that did work. So now we can see here that in the back end, this is actually posted to Drupal. And Drupal via the Tome Sync module is automatically exporting the files that have been updated. So the node has been updated. And if you have a look here, you can see the title has been updated. And now as the site builder or the person running this particular instance of Drupal, I have the choice to actually commit these changes so that next time when I spin up an environment from this particular code base, that content is there and ready to go. So the last thing I just wanted to show before we get to the discussion phase is just a couple other little authoring experience experiments I have done with this technology in the recent. So there's two here. This is the Drugs.js YouTube channel. Please like and subscribe so I can have a better name space. But at the moment, 21 subscribers at channel slash whatever that is. Link will be in the end of the slides. So this here is an example of a site building experience. So this is not content authoring per se, but it's the idea of being able to drag and drop your regions from a sidebar on a front end wherever you want and move them around. And it gives you an exact demonstration of what they actually look like live. And if these are supposed to look different in different places, they will look that way as you move them around. On content, however, this is an experiment called the edit bar, which is very similar same sort of concept book. I'm just going to turn off. I have extra audio coming through. Is that me? Let's go again. Okay, so let's have a look at that.  So one of the biggest issues I hear from content teams is previews, especially with decoupled. And I've seen many different iterations of preview systems built within Drupal to show you what your decoupled site should look like. I haven't personally gone that approach because I don't believe in the future that people will be building their content in the back end of Drupal. They'll be doing it in the front end in some manner or a front end. So this way, instead of having to build a preview system into Drupal, you just see the changes live. So that's pretty much it. I think lightning talk wise, I think we can go back to you. Okay, I don't know if I... Okay, thanks, Stuart. Okay, so now we get to the discussion part of this session. And I guess people will be getting added to the screen shortly, but as they are, I'll introduce some of their panellists. So we have Jack Taranto, who's a senior front end developer at previous Next. Max Pokanowski, who's application architect at Intermedium. We've got Brian Gilbert, who's a polymath and also a founder of Reality Loop. We've got Si Hobbs, who's solutions architect at NewSouthWales.gov.au and finally Lee Rollins, who's a Drupal core commuter, a member of the security team and lead developer at previous Next. Welcome everybody. Yeah, so this is the part where you get to ask questions. The overall intent of this is to kind of try to simulate a bof where we're all in a room in a round circle and we're all having chats and discussions. So it's not meant to be like a presentation that's supposed to be more of a discussion. So yeah, please go ahead and ask your questions. And maybe the panellists want to kick off with any questions that they might have of their own or comments that they have on their own. I guess I'll try and start something. So I'd be interested to hear what the others have to say about the various approaches they have. I'm going to assume that most of us use probably a paragraph-based approach to content layout. And like for us, I think we find that it's a really good balance between having a lot of control over flexibility but still constraining the design intent so that content editors can't break out of that and mess up the front-end of the site. And now with Drugs, we get even more value for that because it's component-based. We can reuse those components, which you can do in Tweeg, but it's so much better in the front-end. So yeah, discuss. Can I ask directly to Lee then? Lee, from your side on what Brian said, like how do you approach things with Gatsby in the case of content authoring and that side? Yeah. So yeah, with Gatsby, paragraphs is what we use for that. You're kind of limited to a... with templates for how you're going to lay things out so you know ahead of time that this particular paragraph is going to go here or they're going to be all used in sequence. And when you make your GraphQL queries back to Drupal with Gatsby, you're only doing that in your components to render them in place. So whilst traditionally you'd be used to using paragraphs or layout builder and having full control over the order of the components with something like Gatsby because the React template defines where things go. You know, you're going to make scope to queries and fetching the data that you need to go there. But yeah, so before you had drag and dropping things around that's something that you're going to do with Gatsby because the order of content is going to be dictated by what you've got in your React component. Yeah. Yeah, that's an interesting point and I was going to ask that which is the approach that I've taken in Dructs is to try and use as much of the information from Drupal as possible and use it to direct what happens on the front end but not necessarily restricted to either like as you say, React components. With Dructs you've got wrapper components for each level. So an entity display types, you'd have a template, a view component for entity node article default and entity node article teaser, etc. But it still allows for the back end to have a say if the front end wants to listen to what the back end has to say. Which opens up the ability for site building still to exist without necessarily cutting it out at the front end. Okay, I've got a question from the audience. So Tini asks, anyone have any live production headless Drupal sites? And I assume that by that it means like using the full... Yeah. Brian raises his hand. No, no, I was going to say just again to clarify decouple does not mean headless. Yeah. That's a very important part. So are we asking headless? Yeah, that was the question. It said headless and I assume that's what the question was. Because I'm assuming there's plenty of decoupled Drupal sites out there. The one example which isn't necessarily great because it didn't, after it was deployed it didn't have a huge amount of buying actually bad things about it. So it's like, you know, it's a good... But the work safe Victoria site that was basically JSON API with a view front end. So the full Drupal site but it had the editing back end. That's one example that's live. It's still live. It's been live for a few years. Very fast in terms of the searching hits solar directly. So the search aspects are really, really fast. But some of the maturity around maintaining platforms like that especially when a lot of it was hosted on Acquia and the tools that Acquia provided was before it's time for sure. It was trying to deliver on a brief and perhaps should have pushed back on the brief but it worked. I am curious to hear as well though like headless headless like if there is anyone doing content editing in the front end with Drupal as a production or close to production sort of thing. Yes. Yes. Speak. Yeah. It's not a public site. It's a business application for the company I work for. But we're very close to fully releasing the data editing framework. So Drupal is handling all of the data entity model using the entity model in Drupal handles all the permissions. We've got GraphQL doing the API and we utilized a data editing JavaScript framework called DevExtreme that allows us to work with that data in tables and lists and hierarchical breeze and all kinds of fun things. And so we can point that through GraphQL at our Drupal database and our staff can edit the data directly on the front end and it's working really well. Way better than our previous approach. What do you, this is I guess a question for the panel, but what do you see as the outstanding challenges or limitations to this approach? I know Stuart's not going to say, he's going to say none, but I'm interested in what the panel has to say. I think even if Stuart thinks it's none, it's really time or finances to do the work, really. Yeah. I agree with that.  I've been working on and off really for my entire career. So I don't think there's anything that can't be done. It's just do it. That's it. And the bigger the project it is, the harder it is to get to that stage. I mean, at the moment, drugs is primarily my vision. So I've got the ability to move fast, but I'm trying to ensure that it consumes everyone's visions and does what everyone needs it to do. And as we get to that, the questions start to be about like what sort of defaults that do you need to provide? Like Squarespace and Wix and so on keep coming up. And I've been building this, I mean, myself and Brian have, has probably nearly every Drupal developer out here been working on that sort of like SaaS product for ages. Like let's make something that's easy to build sites. And I've been doing that through building a framework, but more resources, more development time, more documentation, because as Dries said, it's not about the code. The technology is great. Like I can swear by the technology, it's fantastic, but people need to be able to use these things and the project needs to be able to be managed and it needs to be presented to people so that they understand that these things are out there. So exposure, resources, that sort of thing. I'm interested to hear what Lee has to say on the Drupal backend side and what needs to be supported to allow, I guess, more of that, which content editing experience from a fully decoupled frontend? Yeah, I think one of the things that you often overlook when you throw at the baby with the bathwall that is all the things that you get for Drupal that are just a module away and a good example of that would be Webform. For example, I'm yet to see a, you know, decoupled solution that lets content editors define forms in any shape that they like. Jess, the students with his hand. You know, so these kind of things that we've sort of had for a long time take for granted to have to recreate later, but there's another one. So yeah. I guess from a... Sorry to jump in. I guess from a frontend developer's perspective, what would... I have a question for Jack. What would you see as being something that you would need in order to be able to, you know, build on top of as a frontend developer? Like, what are the foundations that you would need there to make that a good experience for frontend developers? For the... Are you talking about for the admin content editor? Yeah, I mean, ideally the whole Drupal bathroom experience would be headless, but it would be, I guess, built by the community.  That would be the dream, I think. I guess what kind of scares me when we've got headless sites is, yeah, there's no... Like, there's no standard process to how people are, you know, editing and working with sites.  But like, I couldn't imagine something where you're like editing layouts and paragraphs and things like that. And then, you know, looking at every Drupal site out there, having to reinvent the wheel by creating their own interfaces to do all that kind of stuff. Yes. If we're working towards a framework that ended up in core, you know, that was part of, you know, part of Drupal that we're all using, I think that'd be awesome. Can I just interject on that one? I really strongly oppose the idea of putting a framework into core. It really limits what you're going to be able to do in the future. I don't disagree on the reinventing the wheel every time. I think that's an important part. I think a framework should allow one to be used as a pure framework so you can reinvent the wheel. But two, at the same time have same defaults. And that has been one of the parts that I've strived for. But putting the framework in core will limit how things can progress in the future. There's no reason why you can't use view and react alongside one another. There's no reason why you couldn't have a view and a react front end, back end, you know, front end for back end, for different specific tasks. Having a default one, the Drupal community builds, I think that's a great idea. Having the framework in core, I don't think personally. Yeah, I think we're just, we're in a situation where the, you know, the editor experience in Drupal is getting rapidly out of date. As far as the JavaScript in there goes, and there's a vast amounts of it, you know, and it's all built on jQuery predominantly, you know, which is a framework for the old days. But yeah, I mean, where do we go in the future with that interface? How do we modernize it? And then how do we standardize that? There's got to be a framework, doesn't it? One of the things that I come back to repeatedly in discussions is that the, again, personally, my opinions count for me, not my company and not my framework, just for me. But I would like to see standardization on the actual pipeline of data within Drupal because at the moment, a decoupled site does not have access to the same amount of information that a coupled site does. PHP has priority access to certain things. Blocks is one of the biggest examples of that. The decoupled blocks integration I've got with Drugs, it knows the block regions because Drupal tells it that information. It knows what's in the block regions. It knows when they're supposed to show up. So as far as my front end can do things, it can make it happen. And it knows the configuration as well. So taking into account like the branding block, the branding block, if you decouple it, it will tell you, I want the logo. I want the site name. I want the site slogan. But it doesn't tell you what those things are. So if you want the logo, you know, you know, the block is configured to show the logo. But if you want the logo, you'll have to hard code that yourself. Ditto for the site. Does the shooting use JSON API on? Yes, sorry. When I talk about decoupled, I'm talking about JSON API and I'm talking about using the data that Drupal makes available out of the box without adding any specific extra modules. And that is one of my core visions. And with the other topic that you mentioned before about web form and submitting stuff, and you also touched on that, Jack, if you do use the JSON API, when you do do a CRUD request, a post to push whatever, I mean a post, yeah, post to patch whatever. If there's validation issues inside, if you don't have the right permission to be able to make this item published, Drupal already knows that. So as long as you format the JSON API request that you push back to the system, it knows how to handle it and it returns the results if you've got validation issues. The JSON API in Drupal already tells your front-end that it's there for you to consume that data as it is. There just needs to be more and it needs to be standardized. So GraphQL and JSON API and Drupal or PHP all have access to the same level of data. Interesting. I remember, I think it was, Gabriel Solis had a blog post, it was probably six months or more ago where he was talking about, it's not enough just to have the content, a content API coming out of Drupal because there's all of the, there's all the kind of the, I forget what he called it, he put it like the machinery I guess, things like layouts and the structure of the page which is kind of, it's not really content, it's really the configuration of Drupal. So I guess how do people feel about that? Should we be trying to split that off into its own piece and treat that separately from what content is? At the moment, it is already there in the JSON API. So when I talk about schema and stuff like that, that's data that comes from the JSON API. So entity view display, entity form display, all of that information is exposable in the JSON API already. Editor is a resource that contains all the information about WYSIWYG, which buttons you choose to have available for which display modes. A lot of this stuff is there. It is, as you say, it's tangled up within the content because anything in Drupal that is considered a content entity is exposable via the JSON API already and most configuration is set up as content entities. Okay, I've got a question. It's probably the access layer, right? So by default, most of those configuration entities are behind what we consider elevated permissions. So, for example, the managed view display would be behind the permission that has restrict access on it and you probably don't want to be exposing that to your front-end, but in order to put it ahead of the site, you have to. And so, yeah, there's no real distinction in Drupal's permission system between being able to view that information and being able to edit it. So I'm interested to know how you're getting around that. And that is the one case where there is currently a custom module or contrary module, I should say, which is the Drux module itself. All it does is a very few minor workarounds. And I want all of these workarounds to be documented and turned into issues at some stage. And I want to kill the Drux module in the back-end because it doesn't need to be there. It shouldn't need to be there. But the way it does it is it adds an additional permission, which you can assign to any role. So if you have a specific back-end building role that is used by a OAuth user at your build time, then it would be able to consume that information. It's read-only information as well, because I agree that information has, you know, not really being considered as how it should be used outside of Drupal. So it's read-only. It's available to that permission. Yeah. Okay. I want to make sure we get to a couple of questions that we've got posted here. So we've got a question from Joshua Lee. It says, last time we were looking into Gatsby, there was a concern of content editing on the fly. Gatsby requires the deployment to Netlify every time the content is updated. Is it still an issue, or has this been resolved into the market? In the market. I'm going to talk to that one if you like. So, first of all, you don't have to deploy Gatsby to Netlify. You end up with static pages, and you can deploy it wherever you like. You can host it at it. There's three we're hosting preview sites out of CircleCI artifacts. You can do what? It's just HTML. There are use cases for Gatsby where you're going to hit hard problems. And one of the hard problems is if you've got a lot of content.  You know, you do find people in the issue queues for Gatsby, or sorry, in the GitHub queues for Gatsby saying, you know, it takes eight hours to run a build, and it's just not feasible. But there are, you know, solutions. So, Gatsby 3 is added a fast build feature. So, basically, it does a diff between the incoming props and the last time it was built against the cache, it doesn't rebuild pages that haven't changed. So, that helps. There's also a fast builds module that Drupal has. So, every time you make a content change in Drupal, it keeps track of things that were edited. And then when you run a build, it makes a call back to Drupal and says, tell me what's changed. And then it doesn't bother, you know, if you want to change one piece of content, it doesn't bother rebuilding the whole site again. So, there are things happening there. But yeah, look, you do have to look at the top content that your site's serving and how frequently it updates as to make the decision whether it's right fit for you. And at the end of the day, Gatsby is just, you know, it rehydrates into React app. So, you do have dynamic content that's updating regularly. You can just use that as you would in the client-side rendering and make, you know, APR requests from your components from the browser. Yeah. I'm also interested in how I think Next.js is doing or can do static site generation, but also server-side rendering. It's got this optimized static rendering where it can basically... I'm just wondering if people have got opinions on that. Next or next? Maybe next. I mean, they both have different approaches. So, I am primarily Nuxt. And I have used Next a slight little bit. But Nuxt, the way Nuxt works is it has different types of build modes as well as different types of targets. So, you can build a Nuxt site in server-side rendering. So, it will have to run on a node server. And it will render all of the page on the node server, before serving it up to the user. So, if there's any asynchronous data that's already going to be there, you can do non-server-side mode, which is still running node, which will just serve up enough HTML to inject the client-side application into the user's browser, which will then do what it needs to do to load in all the data progressively the same way that it would do in the server-side behind the scenes. Then you have the two different static modes. You can have static mode with server-side and static mode without server-side. So, static mode without server-side simply generates a couple pages, like a 200.html file as your wildcard fallback. So, any pages that don't resolve a static HTML file in the deployment will hit that 200 file, and that 200 file will then load in all that additional data client-side. So, in client-side only static, that's basically what gives you that one file. In server-side static, it will generate a HTML file for every discoverable piece of content that you have within your site. I could show you a video of that if you wanted, but it probably doesn't really matter, but that's the way that the Umami demo works. It will hit the home page in static. It will find all the links that are on there, and then it will go through every single one of them and create a HTML file. Now, when you actually browse to that site, the HTML file will have just a very small amount of rendered data, which serves up the full page really, really quickly, but then it rehydrates it as a view app and Nuxt app, so it re-engages the view extor with all the data, so as you start navigating around, it just progressively loads in the things that you want. Okay, well, I think we've got time for one last question. So, Michael Cooper asks, I'm interested in security and re-usability of the advantages of creating all content on one really secure main dribble backend and then being able to use that content on multiple front ends. For example, a research unit site and a portal for prospective students to show the same event without having to syndicate or duplicate. Which of these applies and has minimum DevOps burden? All decoupled, I think. As long as you've got an API to consume that data, you've got a registry and then you can build anything with anything to consume that data. And Drupal comes with JSON API out of the box, so it is already that out of the box. There are DevOps overhead with all of these approaches and it depends on whether you want to pay someone for that, so if you want to go and say Gatsby has Gatsby Inc, which is a managed service and that has a cost associated with it, you can build the same things as Gatsby Inc with your COI pipelines, but then you've got to have your own DevOps over here. So it just depends on whether you want to manage yourself or whether you want to use a managed service for that. And I guess one of my questions is, in terms of the Drupal project, do you see the fact that there isn't going to be, like, well, if it's open to develop an admin, decoupled admin thing, front end without trying to target a specific technology that will end up fragmenting the community and we won't get that kind of critical mask, because I believe at the moment there's still a shortage of people working on JavaScript and front end in core, so we've got a pretty small pool of people who are contributing at the moment. What are people's thoughts on that? I think the value there would be in working together to come up with the concepts for what the decoupled front end could how it could work and that done collectively because invariably it's going if it's going to get implemented centrally, it's going to be something and then there'll be other people who want to use a different technology, but at least if a lot of that work's gone into the usability of how the components work, then people can port those to their frameworks if they want to, would be one approach. Okay, all right, I think we are almost out of time. Thank you Stuart and thank you panelists for joining us and thanks for coming along to the session. I hope you enjoy your rest of the afternoon and come to the sprint tomorrow. Thanks.