Entering the World of CMS with Wagtail with Michael Riley

Speaker 1: Glad to be here. I want to first off thank the Django US folks for allowing me to present here today. Really looking forward to it. This is my first live talk here, so incredibly nervous but incredibly excited. So let's get started here. First off, a little bit about me. I'm an elite support engineer at PlatformSH. Previously I was a system administrator at greatnews. life. which was a small which is a small um positive news only sites based out of northwest Indiana. At platform, we also do a lot of CMS here, so I'm really excited to get into the meat and potatoes of what we do at Platform as well as

Speaker 1: um Wagtail as well. I've recently got involved with um recently started working with Wagtail as a um framework and I'm excited here. But let's first answer the big question. What's a CMS? A CMS, I define it as a system that's defined to deliver information both to current and future users. It's your online presence that you have full control of, not some social media where you may be limited to over 200 words. Um Wagtail is um the framework that is well known in the Django community uh because it's built upon it.

Speaker 1: uh uses the modeling system in Django as well as the Jinjun templating engine. Um the ease of it this makes it really robust and um the ease of customization within the CMS, um the functionality that the I'm sorry. The ease of functionality that the Wagtail folks have built upon the Django really makes the compelling CMS engine or C um content management system, I'm sorry. Um incredibly nervous here. We're gonna talk uh but before I start here, I want to separate the this talk into three sections. These are the three types of people that will be interacting with your content management system.

Speaker 1: First off, we've got the developers, as always. You've got the content writers, and then the customers or users that you're are that are used in your sites. And um I separated it here because they all have different purposes and are impacted differently in the Wagtail ecosystem. So let's get started. But to really get started, we have to go back. Um well I'm sorry. Um Thank you. There are some principles that I I want to discuss for um developers working in CMS that are pretty standard but must be said. You want a CMS that's easy to work with

Speaker 1: and is not bloated. You want something that is doesn't fight against you when you try to use it. And you want it to be easy to develop for because you don't want to be doing those late programming sessions. No one does. Does anyone here? No one does. So um you also want to make a seamless experience for your uh content writers because whenever they do have a problem with it, they will complain to you about it because it is your problem. You're the one that's maintaining it. So um But to really understand how Wagtail makes a difference, we had to go back to before Wagtail was a thin. In the history of CMSs, there's three big content management systems in the early to mid-2000s. Drupal, WordPress, and Joomla. The commonality between all of them is that they were designed for non-technical users to be able to

Speaker 1: um customize it via the interface and they have a vast third-party ecosystem for non-experienced users to expand the CMS. Um this has led to some experiences where I've seen customers without developers on hand or maybe using a temporary agency. Um why am I bringing this up? Well, this isn't the bash on other platforms to be clear. They have their purpose. Some of them do it really well. Platform SH in fact is a very huge supporter of Drupal. I bring this up because we need to get the context of how other content management systems do it because Wagtail does it very differently here. When developing a Wagtail, you have to do most things programmatically. It's not within the content management system. So you're doing it via code.

Speaker 1: As a result, for developers, it feels like it's not really getting in the way as much where you don't have to do everything through the interface. It has a smaller refined set of extensions available and on the Python package index in the form of the Django apps, but They really do perform well and they're open source by nature, which not all ecosystems are open source by nature with their plugins. This kind of leans more towards a do-it-yourself approach, which um usually means there's going to be some form of in-house development agency or um or just a single person on your team. For your Django apps that you create, the custom functionality, you get to maintain it yourself, which means whenever there is a problem, you can solve it yourself.

Speaker 1: Um I bring this up because some third party uh when you're using third party exemptions, which is so common with the other solutions that are available. Um If you can't immediately fix it, you have to wait for the developer to fix it, which I've had more cases working at platform SH where The customer's kind of out the d out the dry because they have to wait for the extension maintainer to kind of fix the issue. Nothing's worse having to do emergency refactoring because some extension has issue that you just didn't foresee. Whereas the do-it-yourself approach kind of just fixes fixes that you just rather fix it. Um with your own tailor-made solution, um oh

Speaker 1: you're not panicking to review third-party code that you've never seen before That's another um that's coming from the completely other side of things where I've experienced that as a developer, having to fix something that just broke one day and doesn't seemingly have a fix and then I had to fix it myself. Now let's I'm gonna show you an example of a CMS site. Uh this is greatnews. life This is where I previously worked. Disclosure, this is not actually Wagtail. This is WordPress, but it doesn't validate it for what its CMS can look like. As you can see here, the homepage shows multiple feeds of feeds of different content and articles that have different associated tags. So we can see business, sports, community.

Speaker 1: For this presentation, let's just say that this is running on Wagtail. This would all be part of a Django model defined within Wagtail. And as a developer, you would be defining these models how the And um defining how these models uh defining how the data is modeled within the application there. These uh data models will deeply influence how the content writers are going to be structuring stuff within the CMS. You'll also be defining the Jinja templates, but for this talk, I'm not going to be talking about Jinja. Here um you can consult the the Django and Way Excel documentation here. There's only so much time I can fill in for this presentation, and I felt that With most of us probably having the Django experience, it's probably worth just omitting, but I wanted to mention it.

Speaker 1: Um we can also see the rest of the page here, same stuff. Um Now here's an article for it, which would have a different model, but for this, I'm actually going to show what the equivalent model would look like later on. We can see that there is the navbar, the the author, which is the partner in this case, the article title, photo, author, and then the article content. And on the sidebar there's some static stuff where it's a search bar, ads, recent news, all different feeds that like we saw on the homepage. So we're going to move on to content writers, which is where we're going to actually write the model code. I said earlier that we would write model code regarding the feeds that we saw or the article page, and we're going to do that.

Speaker 1: But for content writers, there's a different set of principles I want to talk about. We do not want CMS to get in the way of creating content I had mentioned before that developers will usually be the first ones to hear when there is some sort of issue with the content writing area of the CMS. Or there's some sort of inefficiency here that's making their lives much harder. We want the CMS to be seamless and easy to understand for everyone. Including the content writers. Developers sometimes won't realize how much control they have of it. So I put here that Beware, you're in full control of these content writers workflow. You need to be cognizant of it and you

Speaker 1: need to be fully aware of the repercussions you can have for making a change. So the models that we talked about earlier. I hope that this is visible. Is it visible? Okay. So we can see here that I'm maximizing for myself. Um we can see that it first starts off with the partner. Great News kind of does things a little bit differently in how they write content. So the partner is usually the author on the article, along with a separate credit to the writer of the article, usually sponsored, but um Then we have the article title which uses a character field. Oh, back up for a minute. Partner uses a foreign key.

Speaker 1: For anyone that is familiar with database relationships, a foreign key is referring to a unique object somewhere else within the database. So it makes sense that we're using a foreign key here because we're referring to a completely separate different model here. Partner, as we'll see in the next slide, what that looks like, we defined it a partner model. Then we have the rest of the other content, the photo, which also uses a foreign key because Wagtail happens to use a different model for images, so that's why foreign key is used there. Character field again for the rest of it. And then the article content is a rich text field.

Speaker 1: Rich text is kind of the bread and butter of Wabtail, one of the many different types of common. um fields that you can use within it that allow you to write content in a um appealing way, um both appearance and for the um content writer. And then on the other side right here, publication date, just simple dates that auto-populate. There is a search field as mentioned here that sets indexes so that when you search within the content management system, it will show up within a search. You want certain fields to be searchable when you look them up, so you have to mark them here. The content panels in the code, that is what you specify that you want to show up within the admin CP of Wagtail.

Speaker 1: Um the rest of this stuff is just pretty common stuff or pretty common in terms of development. You might want to consult the Wagtail documentation on the last few lines. Um the this metadata, I'm not really going to touch on it that much. It's nicer in IDE. And here's the partner model. Again. Using character fields, tech um, and foreign keys. We also use a text field here to kind of write the description. Um I'm sure I'm just rambling here, but that's what an actual model will look like for that type of site we just saw. And Here's a list of common fields within Wagtail. A lot of it, the naming scheme is very self-explanatory.

Speaker 1: The two ones that you want to kind of focus on is rich text field and stream field. Streamfield allows you to allow the content editors to write their own um sort of structure their own um It uses a block and then you can put whatever you want inside that block and not just be confined to a certain format. Kind of letting the content editors put their own format in within a block. is how I kind of describe it here. Again, this is very thoroughly covered within the Wagtail documentation. You also have the Django field types, character field, date time , self-explanatory I also mentioned here the stream field blocks that you can use within a

Speaker 1: stream field. So a rich text block, character block. Image chooser block, very self-explanatory. Uh I'm still probably missing stuff here. Um But yeah, um actually see what a stream field kind of looks like. This is from my websites, not directly with the great news stuff, but You can see where the arrow is pointing. That is a stream field rich text block. This also shows the interface of how the Wagtail admin backend looks like. Uh this is just several of one of the many pages on my websites. Um a big selling point of Wagtail is just being able to

Speaker 1: to sort of have a predefined template of how you want something structured. For example, let's say I want to have a marketing blog post versus a technical blog post that might have a different format. You can easily do that within Wagtail by defining models in pages. It's why it's really appeal appealing. We can see a rich text field right here, which is not within a stream field. So this is just one singular block of text. You can't nest them or anything. I can put a header. uh bullet points, even an image. It's uh really trying to think of the word. Um It's really amazing on what it can do.

Speaker 1: Now, as I said before, be very careful what changes you make, because when there is a problem, you're going to be hearing about it as a developer when you're making these different models. If you introduce a model at one point and then change it in a major way like a couple weeks in, uh you're you're gonna hear it from your content editor team. All right, last section here. Users and content management systems. At the first glance here, this may seem very easy and self-explanatory, but actually following through with these principles can be challenged as you continue to scale. Over the last three years, I've seen clients in their worst moments in the trenches or in an outage. This section more or less kind of is here to help to make sure that you are prepared to deal with the evolving user base

Speaker 1: and you're involving the app alongside them. So let's talk about the hard problems. We have quite a few to get through. Pending if time allows. So CDN caching. One of the first rules of launching any CMS, I try to tell any customer, don't launch a site with a CMS. Please don't. Um a CMS is crucial for being able to deal with fluctuation in traffic. CDN caches are basically perfect when it comes to the static content within a CMS. If it caches it, it does not reach the application in any way.

Speaker 1: It just hits that point of presence within the CDM. So you're not constantly bothering the app if there's like a 10,000 users going for this one particular site, only a handful of the traffic is going to make it through. to the actual application. It really saves it there. The origin ideally should only be sending um the the origin should only be accessed whenever the um The user is posting or submitting information or otherwise accessing content that isn't cached. Um within you this is within reason. You can't cache everything. Um That is a very good reminder. You do not want to be trying to cache everything within your CMS if you have over a hundred thousand articles.

Speaker 1: I've seen it. I've seen it. It's really Now, one last point. Make sure your application can purge pages when they're changed. If you update an article and then it hits that cache page that doesn't have the update, well, your users aren't ever going to see that until that cache expires, which could be days. Depends on your cache sentence. Application caching. Now this is within the infrastructure that you have your app hosted in And for requests that hit the origin, it's likely it's going to be hitting the same data over and over again. Um you want to use something like Valkyrie or RocksdB.

Speaker 1: to prevent this from happening to where it's constantly trying to hit the database for that information. Regardless of the complexity Using this will not hurt you in the long run. So long as you don't abuse it. And that's the keyword. Do not abuse it How do not abuse Redis or Valky? Valky is a single-threaded program. It can only do so much before it falls over. The guidelines that we kind of use here at platform is around 2,000 requests per second. If you're pushing more than that, or you're pushing so much data that it's evicting it before it even can be accessed for the first time, you're using cash wrong. This covers it pretty good. Here's a visual representation of what I've seen on a platform SH

Speaker 1: site before. Now this is hitting around at max a hundred thousand requests, well above the 2,000 requests that um I specified as being the ideal range. Anyone think the site was online when this happened? Anyone? Well, it wasn't. This was happening as barely any users could access the site. This also brings me to another story. One day I was talking with one of our senior engineers, Andrew. We had one particular customer that was having a lot of issues, but we thought we had made it over the bridge,

Speaker 1: so to speak. I look in the ticket queue to find an urgent ticket from this customer. And what I like to do with any urgent tickets that come in is look at the metrics for a project. I look in here, you could literally hear a pin fall in. It was that quiet that you look at the memory usage for the Redis container, it just fell flat to the floor to nothing. And I'm like, well, there's your problem. Turns out what happened was that someone on the customer's end flushed the cache in its entirety during a peak event. thinking nothing would happen. Then the question that was asked immediately after ,

Speaker 1: why did this happen? So when you clear cash, it can do one or two things. It might blink and not be happy about it, but it will eventually get the cash and be a little bit slow. The other result is that it could fall completely over. In this case it fell completely over and he was asking why. So this is an excerpt from Andrew at platformsh where Cash clearing under heavy load costs of stampedes. Requests for solar database calls instead of fast cash hits impact you depending on database impact you depending on application design. Some can tolerate cash misses, others cannot. It depends on how you design your Redis usage or val key usage on how you use cache that will determine whether you will be able to

Speaker 1: whether resist a full flush or whether Redis completely going out will kill your site. It's not application dependent or framework, it's not framework dependent. It's application dependent, how you design things. Leads me then over to application performance. Another key issue that we see is applications responding very slowly. Um this is often referred to as kind of the latency within the application. You can see this within a load balancer. You have a certain amount of budget within the latency that you can respond by before it just times out. CDN is typically around 30 to 60 seconds. That's your budget of latency.

Speaker 1: And that's whenever I'm explaining this to customer, I always use the word budget because then they know that there's only a finite amount of it that you can have. You also need to keep in mind that there are only a certain amount of workers. It doesn't matter what type of application you have, whether it's Python and PHP, there's only going to be a certain amount of workers that can serve requests before others have to wait. And if your application is responding super slowly, they're just going to be waiting. What is the answer to that? Well, observability. This cannot be recommended enough for an outage. Um comes in various different forms and functions such as APMs. metrics and site monitoring. You want to have the tools to be able to

Speaker 1: tell your stakeholders when an outage happens that you've got it, that you've got the issue resolved, or you know what it is when you're trying to implement a fix. APM and observability are key to this. Allows you to look into it after maybe things have kind of calmed down. Maybe your developer isn't necessarily available right now, but you have the data to be able to figure out what happened and stop it from happening again. Um these can also be used to identify bugs before they happen if you're on a staging environment and you see why did the request just spike up in response time? Oh it's this One response call. APMs can can tell you up until the system call or the um

Speaker 1: the call with an application. It really is a unique tool. It's undervalued, underused. I really recommend APM solutions. Doesn't matter if it's with um your current vendor or something else. You can find it so easily. Um Some other um some other types of observ observ observability metrics some hosting providers just do not provide metrics for it You should be able to look at your metrics when there's an outage going on, be able to I identify where the issue is. If not, implement it. And then just general monitoring to make sure your site's up. That's also pretty part of the observability suite that you would want to have implemented. If you don't know your site is down, that is a bad sign.

Speaker 1: Getting a call from your stakeholder, why was the site um offline at uh at like 11 p. m. last night during a sale? No one knew This is the most awkward conversation to have with a boss. Ideally, you want to have all this implemented before go live, so that's another thing. All right, now let's talk about wafts and bots. I know AI has been talked about at DjangoCon here. In the hosting space, we've it's kind of been putting us in a precarious situation where sites are getting endlessly absorbed by large data models trying to scrape it. And sometimes it often it's very aggressively , brings sites down. Um the industry is still trying to kind of figure out solutions.

Speaker 1: There's been some solutions that's kind of been Found but again AI is evolving quick and sometimes those solutions that you just used two weeks ago don't work anymore. You have to constantly be work looking for solutions for this. So a WAF is something I really recommend nowadays, especially with the age of AI, because you need to be able to prevent these abusive bots from taking your site down, whether that's through um TLS sign um TLS uh signature blocks, J3 hashes. It's a really good tool, but also kind of a double-edged sword, so to speak. You don't want to block someone using some version of Chrome, and then suddenly your whole entire user base

Speaker 1: can't access the site. So You want to have a strategy for this at some point because it will eventually happen to you. If it hasn't already, um AI is evolving But what WAF was used for before was for suspicious traffic and rate limiting, where DDoS is a is a term that any system administrator or network administrator will instantly shudder at whenever they kind of here in the context of the site that they're responsible for. So um wAps are also pretty key that you don't want to um Not use. I really do recommend it. Um with this, I've kind of reached the end of my presentation. However, uh

Speaker 1: how much time do we have left? Oh fifteen minutes. Um worry, uh feel free to take questions or could it be a little bit more of a discussion? I mean I could also kind of yeah, let's do questions and then maybe we can do um I had initially thought that war stories might be a good thing as well if if anything anyone wants to hear. Um of course not gonna get into too much detail um in terms of the clients, but yeah, um I'll take questions.

Speaker 2: Thank you, man. Good good talk. Uh just a quick question. You advise saying not to use full cash on a uh wactel side like what's your experience in terms of like uh

Speaker 1: so you said don't use cash or

Speaker 2: not to use full cash on a wagtail

Speaker 1: Um I'm not sure if I misspoke, but um

Speaker 2: Okay.

Speaker 1: I I you do want to use cash on Wagtail. There's very few instances where you do um not want to use it. The instances I kind of said were um If you're instantly invalidating cache as you're adding stuff in and it's just not really using the cache at all, it's just an extra layer at that point. That's the only time where I really recommended not using cache. Well not even that. You can add additional layers of cache. You don't have to have one instance of Valky. You can have two. We've used it for one for storing sessions and then the other one is the application data. That can also work. I've heard of using different types of many different instance types of Redis for certain data and you can

Speaker 1: do that. Um in terms of implementing that for Wagtail, I don't know what the implementation details are. I know there is a setting within the Django within the settings file that you can put for it to use Redis as a cache?

Speaker 2: Yeah, yeah. We used like a through our full weg vector cache and that's why I was wanted to understand what your experience is like not but if it's just misspoken then that's okay.

Speaker 1: Yeah um apologies.

Speaker 2: No it's

Speaker 1: um

Speaker 3: Thank you. Um, performance. Can you say more about the scale of sites that um you've served and just like which metrics you tend to look at the most that might be trickier with Wacte than you had to spend time. So for example, I don't know if you worried about Live traffic on the public sites or maybe concurrent editors in the CMS? Just keen to hear more about that.

Speaker 1: So for Wagtail, uh unfortunately we really don't have that many Wagtail clients. Most of our As I said before, our bread and butter is Drupal. And a lot of what I said in the last section of the talk for customers That can really be applied to any CMS solution. Anything will use any sort of cache, caching or um What other areas that I use? Sorry. Observability, application performance, all the all those stuff can be used within any sort of um CMS. Um in terms of the scaling, I mean Let me think here. Um Could you clarify like what you might kind of

Speaker 1: be asking further? I'm sorry, I'm just trying to just like which numbers. which

Speaker 3: retreat some of your five time to real cat.

Speaker 1: Oh, okay. In the ideal world, um the app

Speaker 3: could you repeat the question please? Oh that he said

Speaker 1: Oh um you wanna repeat it? Yeah

Speaker 3: which metrics you look at when you were thinking about it. Which metrics you looked at for Wagtail sites that you were like, oh we need to meet that number for this customer.

Speaker 1: If we have access to the application performance metrics, it's a really ideal world to be able to tell what the throughput is and the um R latency responses. That that's really what's key here. The latency and the throughputs. If you can get an amount of requests, um Loaded testing can only do so much. Um we support doesn't tend to work with load testing. They'll usually let us know, hey, we're doing load testing. That's more of a s our solutions team. But for Uh I know a lot of folks there and load testing can only do so much to kind of simulate what you might see. When you actually have live traffic coming in, it might look completely different. Your application might be performing different because It might be hitting more pages that aren't cached

Speaker 1: or might have a longer response time. You can only kind of guess and gauge what it's going to look like when you go live. So usually it is the um the latency and the throughput metrics that I try to look at for when um for that type of scenario In an outage, usually I'll look at the latency, just look for a spike and say, oh, there's where the outage happened. Let's see what happened. Let's see what else was on fire and just go from there. Uh the you have any additional questions?

Speaker 3: I mean if I can, yeah. Can you give us your top two things you'd love to see changed in Wactail?

Speaker 1: It's hard to say because uh as I mentioned, I only recently kind of got involved with the Wagtail. getting a site up within the last year. It was kind of intermittent. I I've loved everything that so far. Um I I'm honestly satisfied to be honest. I I don't think I could recommend anything. Um Yeah, I I I I just think it's wonderful.

Speaker 4: He said we'll talk later and there will be time afterwards. Uh we still have 10 minutes or so though, if there are questions. And let me know if I'm not seeing anybody. We'll work our way over here.

Speaker 5: Hey Michael. Um so I think a lot of people who uh come over to Wagtail from WordPress and uh Drupal land are honestly a little less familiar with how hosting is structured for Python applications. So this is often the first time that they have to think about like independent caching options and things like that. I'm just curious kind of like how you walk through customers with those types of decisions. if you have any input on that or recommendations.

Speaker 1: For recommendations, I mean the first rule I try to live by is just every application is not going to behave the same. And if you're migrating from one application to another Um i i it's really uncharted territory. No matter how much experience you have, anything can go wrong. Um In terms of kind of explaining this to customers, um, when they don't have any sort of caching enabled, um it usually is that we see outages from the site. Um if I see that they're having a performance issue or there's a ticket. And I see that Redis isn't installed for it. I'll we have a checklist for stuff to kind of check to make sure that are they performing optimally? And I'll try to explain to them like

Speaker 1: it's going to be hitting the database every time you try to they try to do something and you want to kind of give it that level of protection to where it's not going to hit that database because Database connections are a finite resource. You don't want to constantly be using that for something that could otherwise be diverted to something else And it it saves the performance and in most case it doesn't really cost them much to put it in, if any. So if they're getting extra performance, I try to gauge it towards that. It honestly kind of also depends on what agency it may. what agency experience they have. Um I'll try doing a different approach if it seems like they're maybe a little bit less technical because we're we've been seeing This isn't any dig any folks at agencies, less technical folks

Speaker 1: kind of stepping into those roles. So we tried our best to give them the information that they can in a level that they can understand so that they can also push that to whatever stakeholders that have deploy permissions. Developers, because it's not always with the developer either.

Speaker 5: Well, one follow-up to that. Um, do you find that there's a particular scale at which like the caching becomes more important for customers? Like So, you know, going from like a small business site where I sell Trotskis to like suddenly like I'm hitting viral on Instagram overnight. Like You know, at what point in between those two, like would you recommend people start thinking more seriously about their caching options?

Speaker 1: In a perfect world right away, but that's not always gonna happen. Um usually it's They might need a reality check, kind of more or less seeing an outage firsthand and then coming over and asking what solutions can we put into place to prevent this from happening. In a perfect world, that outage would be during a non-peak hour, but it's not always that easy. I hope that uh kind of covers it a little bit.

Speaker 6: Under the hood, which uh uh rich text editor are you using?

Speaker 1: I'm sorry?

Speaker 6: Under the hood of the uh which implementation of the rich editor is Wagtail using?

Speaker 1: I'm s I'm sorry. I I'm not hearing out. Um what rich text editor is Wagtail using? Honestly, like I I I didn't change it from the default. So um again, still extremely limited in terms of um knowledge on that. Um I came from CK editor for for Drupal. So but I was just fine with what I saw, to be honest.

Speaker 5: You want to assist on this, Michael? Because I know the answer. It's called Draft.

Speaker 1: Oh yes, please.

Speaker 5: It's called DraftTale. Draft tail. I believe we have a custom implementation. If you want to bother the person who knows the most about it, he's on that side of the room.

Speaker 1: Oh, w something I didn't mention in terms of modeling, there was a fantastic talk um by Michael on Monday. That I heavily recommend if you want more information on modeling practices for content writers, please go see the recorded um recording for his talk. That was something I hadn't noted and just kind of skimmed over because I'm a nervous frack. Um Before I forget also, I do want to uh thank the Platform Estates developer advocacy and support team. Andrew and Frank from support, Chris May for always being so awesome, uh, Roger Houston and BC. Um If there are any more questions, um sorry, I just wanted to make sure I didn't forget that.

Speaker 7: Uh yeah, great talk. Um you said you mostly did development in Drupal and WordPress. What was your biggest like hurdle that you had to get over to when switching to Wagtail

Speaker 1: So I had a blog site for many years. That was my limited involvement. When I came into platform, I honestly did not have much Drupal experience to it where others kind of did. I was kind of the uh odd cheap, so to speak. Um I had a Python background, most people had PHP backgrounds. Um For Drupal, I had one case where a dependency just got discontinued or stopped working and It wasn't a small piece either. It was actually what links to different socials on the main page. So I um That was annoying and then I I slowly just felt like I could do this a lot better, but I'd have to start learning a lot more about how Drupal

Speaker 1: works. That and I I honestly wanted to use waxtail at that point, so I'm like, well, I might as well just bite the bullet and try. Um and I haven't looked back. Um Quite in fact, I'm looking at one site I'm moving over the Wagtail, as well as another one where it's kind of it's a really big um products that I work on. I want to start using Wactill in the core for it. So yep.

Speaker 4: We might have We might have time for one last question if anybody has one. Or any closing thoughts. Okay, well uh thank you so much, Michael.

Speaker 1: Thank you, everyone. Hope you enjoyed.