What’s New in Wagtail CMS | Release 5.1 | Dark Mode, Performance Improvements & More!

Speaker 1: Hello everybody and welcome to What's New in Wagtail. We've got some excellent talks and demos lined up for you today. And here are your speakers. So if you're new to these webinars, I am Lisa and I head up our marketing at Torchbox and help to coordinate all of these events. And I'm joined by Tom Dyson as well as your host And your speakers today are Matthew, Thibaut, Sage and Megan. And we also today have a special pre-recorded slot. by Richard Macmillan from Springload, who's in New Zealand, and that's why it's pre-recorded because it's probably about four o'clock in the morning there right now, so he didn't fancy being here live But over the next 45 minutes, we will be covering all the latest updates in the 5.

Speaker 1: 1 release, as well as some of the things that are going to be available in 5. 2 as well. So we'll be covering custom validation for stream field, search and performance improvements and dark mode. And then we've got Spring Load site migration case study and an update on our developer relations team and I will tell you about some new events that we've got in the pipeline as well. So as always, we're going to answer your questions as we go. So please pop them in the QA or the chat and we'll answer some live as well during the session. And I am recording the webinar so that I can share it with you all afterwards. And live transcript is enabled if you would like to use it And I think that's probably all from me. I am going to hand over to Matthew, who will show you some new developer features including custom validation for Streamfield

Speaker 1: and Generic Choosers API.

Speaker 2: Okay, yep. So yeah, I'm uh going to show a few uh developer-facing features. Um so this is something that we're always uh Very keen on. The more we can make Wagtail pleasant to build with, as opposed to something that developers feel like they're fighting against, then the more they feel able to provide their editors with something that's not just functional but really adapted to their needs and so everybody wins. So the first thing I'd like to talk about is validation on screen field. So up to Whittail 5. 0, we only officially supported validation rules that applied to a single field block. For example, like this field is required or this field must be a valid URL. And if you had a validation requirement that spans multiple fields, such as the end date having to be after the start date here, then you would be out of luck.

Speaker 2: It was still possible, but you'd have to dig into some undocumented Wagtail internals. And that's because content within a stream field can be nested to any level. any depth. So there's quite a complicated conversation between Django and Wagtail to identify where the validation error message should be attached. So if you raised a validation error somewhere in the middle of that chain, Wagtail would assume that it's part of that negotiation, which meant that you had to jump through quite a few hoops to build up that error in the particular format that Wagtail was working with. But now we've made Wagtail a lot more liberal about what it accepts. So you can write your validation logic in the natural way that you might be familiar with from Django, and Wagtail will do the right thing.

Speaker 2: So as a demonstration of that, here we've got this event block we've just been looking at. Right now there's no custom validation on there. But uh I can add a clean method here and you can see I've actually got um GitHub Copilot uh enabled uh on the on my editor here, so it's uh writing a lot of the code for me. So if I uh accept that suggestion. So I I'm I'm not kidding when I say this is just the absolute standard way of doing validation in Django. So this is so so much so that the robot can write it. So this is just yeah running the standard validation on like the required fields checking if start date is after end date and raising a validation error

Speaker 2: if that's not the case. So just leave this a moment to reload. And now if I try to submit this event then it's going to give a validation error with uh the error message attached in the right place. So that's something that will uh hopefully make uh make your the validation a a lot a lot richer than it was before. Next, I'd like to talk about some improvements to search. So as you may know, Wagtail provides various search backends. so that you can start building your site using the database's built-in search capabilities and then maybe switch to a dedicated search engine service like Elasticsearch as your requirements grow.

Speaker 2: In the past though, we haven't done a great job of keeping the feature sets of those backends aligned. For example, if we found a better way of doing autocompletion, uh, so that would be things like uh in these choosers um being able to type a partial word and have the results completing as as you type. And if we found a better way of doing that, then we weren't rigorous about About porting that across to other search backends. And the search engines themselves can be a bit of a moving target too, particularly Elasticsearch, which in version 6 quietly changed the way that boosting works. So that would be giving like search results a higher ranking if they match the page title rather than the body, for example.

Speaker 2: And so for a long time, sites using Elasticsearch have been locked into an outdated version if they relied on that feature. But now that uh situation is over at long last, thanks to uh Shohan Duteroy, who first joined the Wagtail Project. as part of Google Summer of Code 2021, uh providing the bulk actions feature in in the admin interface, and who has really continued contributing some great features ever since then. And he's uh provided a new implementation of boosting that works on Elasticsearch 6 and up. And we're now also up to date with support for Elasticsearch 8. And in Wagtail 5. 2, we can also add

Speaker 2: Open search to that list. This is the community fork of Elasticsearch that's that was started by Amazon as a result of Elastic switching to a non-free license. We're also continuing to make further improvements to the database search backends. There are still a few advanced features like annotating the results with score that are missing from the SQLite backend, but Our search backends are now a lot closer to feature parity than they were previously. And finally, I'd like to cover the subject of choosers, things like these pop-up interfaces. Um it's uh for choosing uh uh items for the from uh from whether it's snippets, images, documents. Um it's often the case that people have requirements that go beyond what Wagtail provides

Speaker 2: a standard. being able to choose items not just from the local database as we are doing here, but from other data sources such as remote APIs. And this is something that uh we've been able to do through the uh add-on Wagtail Generic Chooser package, um which uh but I've never really been ha all that happy with this implementation because the the options for querying a remote API are a lot more limited and less expressive. than querying a database and then that has an impact on the feature set we're able to offer in in this in in this package and because having to design the interface around those limitations is not something that we wanted when we were bringing that feature into White

Speaker 2: Tail itself. So I've approached this from another angle. What if we could take these data sources, like the REST APIs, and present them to Wagtail as if they were our proper expressive query sets? And that way, Wagtails choosers can continue working in the way they always have done and not have to care whether the data they're presenting comes from the database or something more exotic. And so supported by Ugov, we've created a new Python library named Queryish, which uh which does exactly this, taking uh arbitrary data sources and making them accessible as query sets. The reasons for using API data sources are quite diverse and business

Speaker 2: specific, so it's a little hard to give an example that's speaks to everyone, but one thing that I think we can all relate to is Pokemon. This is a site uh Poke API that provides REST APIs for everything you could possibly want to know about Pokemon. And uh if we uh want to connect to that. Um This is where I've sort of defined this uh API model. It's just of definitions of where the uh where this API lives, uh the kind of pagination that it it's uh that that that it it it it uses, just details like that. And with uh with with that set up we can build a a chooser just like any other So I'll add, so if I in fact I've already added this Pokemon Chooser block,

Speaker 2: which we can easily build out of that uh that that model definition. And With that in place, we have a Pokemon Chooser block that is Communicating live with that API does all of the sort of pagination of um just uh just as a standard Django query set would. And We are able to set select items and then that just behaves just just the same way as it would for a local model. So I'm sure that there's there may not be much uh application for uh Pokemon chooser in in your own applications, but I'm sure this is something that uh we 'll find uh

Speaker 2: applications in in various guises. So uh thanks very much and I'll hand back to uh Lisa and Tom.

Speaker 3: Thank you, Matthew. Uh second time I've seen that demo. I really love it. I'm aware that for those of you who aren't uh developers that uh that was maybe quite a deep dive into some code straight on straight straight off and uh although the first three features that Matthew showed there are as he said developer facing I think each of them are things are features that enable developers to create really interesting and powerful features for end users. And yeah, particularly, I mean I can think of many cases already for the for the for the use of query-ish for the uh generic choosers. And also for custom validation. We've got a question actually from Caleb on custom validation. Caleb asks, will

Speaker 3: there be additional Wagtail docs for validating stream docs with an example like this? Uh

Speaker 2: yeah, I had to just hastily check that we had actually documented that, but yeah, that's uh that that is uh in indeed uh sort of in the documentation. Um yeah, being able to just use a clean method and raise a validation error, I'll uh stick that uh in in the chat for uh yeah, for people to refer to. So yeah, that that's well documented.

Speaker 3: Thanks, Matthew. And here's another one. Is Queryush going to be part of Wagtail or will it be kept separate?

Speaker 2: All right. So um So it is uh it's very much its own thing. It it works uh independently of of Wagtail. Um it's um it it's it's certainly something that we we could see uses uses for within Wagtail itself, a good example would be uh the um the the uh sear search results uh coming from search engines because that's uh that really fits the case of something that is sort of queryable and filterable like a database query but isn't one Uh if if that does happen then Query-ish will become a dependency of Wagtail, but uh it it will always remain its own package. We think that I think that's uh a good thing for like the Django

Speaker 2: ecosystem to be able to provide these sort of reusable solutions and not make White tail this sort of uh walled garden of solutions that only apply to White Tail itself. That

Speaker 3: makes sense. And uh there's a nice comment from Harris who says he can definitely imagine Queerish becoming popular in the broader Django community, which I'm sure is true. Okay, we're going to move on for now, but uh if people do think of more questions on the subjects that Matthews Matthews raised there, then please continue to ask them. But for now, I'm going to hand over to Sage, who is going to talk about some user-facing features.

Speaker 4: Thanks Tom. Let me share my screens. Okay, hopefully you can see my screen now. Hi everyone, I'm Sage and I'd like to show you some improvements we've made since the last What's New in Wagtail. So back in Wagtail 4. 1, we added the object usage reporting powered by our new reference index model. Which lets you know where images, documents, and snippets are used, including references found in string field and rich text fields And in Wagto 5. 0, we added um more information about this uh usage. And it will also be shown when you try to unpublish

Speaker 4: or delete a snippet or a page, or also the case with images and documents. So I'm going to demonstrate by trying to unpublish this snippet. And you will see that it now says that this person is referenced one time And if I click on that, it will take me to the usage information for this snippet, which is nothing new for 5. 0, but or uh the delete view we now also show that information but if you go to the usage information from here It will also tell you what will happen exactly if you confirm the deletion. And in this case, it will

Speaker 4: delete the relationship between the recipe page and this person object. And hopefully this information will help your editors make a more informed decision when they do these potentially destructive actions and the consequences. And as I said before, this is also shown on images and documents, but I'm not going to show that. Instead, I will show you that this usage information is also available for pages. as of Wartel 5. 0. And if you look at the status side panel, it will tell you how many times this page has been referenced. In this case, the about

Speaker 4: page is used in the home page. In the hero CTA link field. And one other thing in regards to the usage information is that if your developer has configured a foreign key using the protect on delete configuration. Whitel will now respect that. And for example, if I try to delete this person snippet It will tell me that one or more references to this person prevent it from being deleted and I'm not given the option to do the deletion. And if I click on the reference, it will tell me exactly where the reference is that is preventing the deletion.

Speaker 4: In this case, there is a location page. in the store manager field that prevents the deletion of this snippet. So um and other on -delete configurations will also be reflected in this usage information such as set default or cascades. or other uh configurations. And yeah, uh the next thing is if you have been following Magtail's development for a while, you may have noticed that We have added some more features to snippets such as revisions, previews, publishing, and workflows. And in Wagto 5. 0, we added features that were previously only available in Model Admin. And

Speaker 4: so and also in 5. 1 we also brought some more of those features. So such uh features such as adding um a custom menu item for snippets. and the ability to export listing to a spreadsheet and also the inspect view, which previously were only available for model admin And the reason why we added this is that up until now we have two primary ways of managing Django models that are not pages in Wagtail. And that is either to use model admin or snippets. And for maintainability reasons, we'd like to make snippets the ultimate way for managing Django models that are not pages in Whitetail And

Speaker 4: with these features in place, we have now deprecated model admin from WagTel as of 5. 1. And we have uh documented a guide on migrating from model admin to snippets. In most cases all you need to do is to import uh to to change the imports and the references from model admin to snippets. But for more complex customizations, you might need to uh do a bit more. And we have also document doc uh we have also added the documentation for those uh customizations. But in the case where uh There are use cases that are not supported by snippets and we haven't mentioned please raise that on GitHub.

Speaker 4: And in the meantime, we have published a separate white tail model admin package. that you can still use and we will be maintaining this package for compatibility with newer white tail versions, but we won't be adding new features And finally, other than new features, we have also made some cleanups and optimizations in our permission system in Wireflow 5. 1. I won't go into details, but I have written a blog post on our lifetime. org website detailing how we did it and the exact improvements that we made And bottom line, in Wagtail 5. 1, we optimized the permission system, which led to the number of database queries going down by up to 65%

Speaker 4: in our quick benchmarks. And using Django debug toolbar , we could see that loading the White Tail dashboard, it will show you that The number of queries have gone down from 63 to 23. So that is 40 queries eliminated. And you can also see that the time it takes to do the query is also much faster. And don't just take my word for it because I've also published the benchmark setup that you can run on your own to uh reproduce the results. as a branch on my bakery demo for. And yeah, hopefully these optimizations will improve your user experience and the sustainability of Wagtail

Speaker 4: and by extension also your websites. And that's it for me. Thank you.

Speaker 3: Thank you, Sage. I must say in in my own experience and uh this improvement that Sage is talking about here is really pretty dramatic. I've just upgraded a couple of my very small personal Wagtail sites to 5. 1 and you can really feel the difference. So For large sites with complex permissions, uh this is a very worthwhile upgrade and uh encourage you, everyone who's in a position to do it, to take advantage of the amazing work that uh sage has led on here. Are there any questions? Here is something about model admin, Sage or Matthew. When is model admin going to be removed from WebPL?

Speaker 4: Okay, so model admin will likely be removed from the Wagtail package in Wagtail 6. 0, but future version numbers are still provisional because uh we don't know how much of a breaking changes we'll be making yet. But however, um it's safe to say that we will give at least a two releases window between the deprecation we made in 5. 1 and the actual removal of model admin. So if if needed, we May we might bump the removal to YCOS 7. 0, but that is unlikely at this point, I think.

Speaker 3: Thanks. And quickly time for one more. Are there any specific model admin admin scenarios that won't be supported anymore?

Speaker 4: So one scenario that I can think of is the ability to register page models as uh using model admin because um We don't support that because we have a hopefully better feature in place for that and that is the universal listings that lets you query and list the pages in a three less views that we'll hopefully be able to share with you in the next what's new in Lactale

Speaker 3: Great. Thanks, Age. Okay, with that, I'm gonna hand over to Thibaut.

Speaker 5: Thank you, Tom. Hi everyone, I'm Thibaut. Today I'm going to talk about improvements we've made in two areas of our project, which are accessibility and sustainability. If you've not seen our website yet, we have an excellent page about the specific standards we hold ourselves towards in those two areas, which I've linked to in the chat I just want to say as well, we definitely have room for questions, plenty of questions, the more the merrier, in my opinion. And yeah, I'll give you some demos of the recent improvements. So I'll start by heading straight into the CMS of my YTL5. 1 demo site and specifically the page editor. which is an interface

Speaker 5: with um revised quite a bit over the last few releases and we've made lots of improvement for keyboard and screen reader users in particular And today I want to demo with you the new supports in the Minimap component, which is this menu to the side, support for having the Minimap always present to the side of your information panels. as you navigate Wagtail. For those who might not have used the minimap yet, it's a really cool component that allows you to both keep track of which area of quite long forms you're on as well as jump straight to a specific section of the form with websites having potentially lengthy pages. it is really helpful for keyboard

Speaker 5: and re users in particular to be able to jump straight to a specific section with a menu like this. And having the mini-map being able to be opened at the same time as the panels felt like one of those gradual improvements we could make so that people who use the use the CMS, the page editor , can navigate those forms more easily. And I suppose more generally is uh an improvement towards power users in particular and customizations of the interface so people can make the most of it based on how they want to use Wagtail So yeah, really cool feature and great for users of keyboards and screen readers in particular. And I'll now be demoing another accessibility improvement.

Speaker 5: which is Wagtail's new dark theme, which you might have seen already. We released it right after the last what's to me in Wagtail. and made improvements for it in the last 5. 1 release. The dark dark theme, dark modes is something that some people might only think as a matter of personal preference. Which is true, but there's actually lots of people who do find it much more much more readable to read texts on as white text on a dark background like this. And uh people with uh dyslexia in particular, some of them report having a much easier time reading the text in this way. So as well as being a matter of aesthetics and personal preference. it also is a matter of accessibility that people relying on this type of theming uh are able to access it.

Speaker 5: And uh I wanna I want to stress as well that um This is actually something that builds upon the works of quite a lot of our contributors over the last few years who have tirelessly refactored the CMS. so we could support this type of theming. I note Josh in particular here in the chat today, who has helped us a lot with color theming in Wagtail, which was a foundation towards uh this dark mode supports as well as other area other improvements in this space. And um yeah so uh my my colleague Sage quickly mentioned sustainability in relations to the performance optimizations is made with permissions. I think it's actually interesting to note that in in some degree

Speaker 5: dark mode can also be a sustainability improvement. We're now looking at the water dollar website, which now also has a dark field, which uh you can toggle on and off as much as you want with the toggle at the bottom of the site in the footer. And though people might not equate this with sustainability. Part of the reason why people like Apple originally implemented this in in iOS, this dark mode is because specific devices have a much lower energy consumption. OLED screens in particular take up much less energy to display darker content. So for a site like aorg, it has quite a small mobile audience. The site, we estimate it emits on the order of two tons of carbon a year.

Speaker 5: And uh this specific improvement for this specific site, we estimated that only about 50 kilos of carbon emissions reduced. So not nothing, but not the biggest deal either, but definitely something we think makes lots of sense for people to consider on their websites, particularly the ones that have much bigger mobile audiences. And yes, so sustainability, I guess just as well, it's worth saying that uh in this day and age, our project does have quite clear commitments on uh what we intend to do in this space and where we intend to take. the CMS and all the more specific improvements that stem from a Google Summer of Code set of internships which we joined

Speaker 5: this year in the summer So it's an internships program sponsored by Google who pay people that are new to open source to contribute on projects like BlackTale. And this year we had two interns who were Path Agawal and Amon Pandey. And they both spent quite a bit of time with us optimizing how our telewebsites can serve images. And I'm also happy to report that those partnerships were, those sorry, those internships were in collaboration with the Green Web Foundation, who are nonprofits that's quite prominent in the digital sustainability space. and are very well known in particular for the sets of tools they put together to check whether your site's hosting is based on renewable energy. So

Speaker 5: really cool organization. And we also worked with Green Coding Berlin, who provided us with the benchmarking tools we used to check Wagtail's carbon emissions on our computers. So just like Sage has done performance benchmarking by looking at SQL queries. We've done benchmarking of the software's carbon emissions by looking at energy usage as people use the CMS. And uh so the specific output of those internships uh it's actually really interesting for me to demonstrate. So now we're looking at our demo sites uh with Wagtail 5. 0, and I'll now switch over to Wagtail 5. 1. And you'll tell me whether you can notice any difference whatsoever. The difference is the image looks slightly different and behind the scenes the difference actually is enormous.

Speaker 5: So I'll switch over to um image size reports that we got. So this specific report we're looking at will tell $5 and this homepage in $5 gets a B score for 250 kilobytes of image weight and clearly quite a big potential for reductions. And now switch to the same reports, but for the Wagtail 501 version of the page. And um yeah, there is no potential for reduction left anymore, which is all all thanks to the work from Amon who implemented AVIF. support in Wagtail in a way that makes lots of sense for our CMS specifically and uh works really well in terms of browser support, for example. So thank you. Thank you very much, Amon, for making this happen

Speaker 5: for us. It's something we looked at for quite a while and are really happy to see it happening and see that it actually leads to really stark real-world improvements for sites built with Wagtail. And yeah, if you want to hear more about this, our release notes for 5. 01 have excellent documentation for devs about how to roll out AVIV support. And so the second internship from PARF, we're hoping to release the changes for this in the upcoming MarkTel 5. 2. So they're not available just yet, but I'll demo them nonetheless. Now we're looking at a 5. 1 block post page where we're loading this header image called BedOnes that takes up 84 kilobytes. And I'll now switch over to a provisional white tail 5. 2 demo where we can check the size of that same image, which is now 9 kilobytes.

Speaker 5: That's 10 times less And that comes down to combining the work from Amons, so the AV supports, as well as the work from Path, which was support for responsive images. So you'll have noticed the visual as well is different here. And that's because Wagtail will now support requesting multiple sizes of the image all at the same time. and therefore getting an image size that's optimized for the specific device. So really quite a bit of potential for us to make much linear websites at the end of the day. And yeah, I'd just like to end again by thanking people who might not be here today, but definitely have had a huge part in this. This has been a long time coming, this support for responsive images.

Speaker 5: We've had lots of people feeding back on how we should be making this happen in Wagetail. And um yeah, it's finally there.

Speaker 3: Thank you very much, Thibaut. Um I do recommend the those of you who are technical or not not interest not even necessarily very technical but interested in the process on uh how these decisions get made and how these features are the design of them is decided to to read through the ticket that Tebow just linked to, or at least that he should share on the screen. I think we'll we can link to it later. Um, because I think it's a really interesting example of of the the potential complexities behind what on the from the outside might seem like quite a straightforward feature to implement. Thibaut, I know that uh last time people were interested in straight away in the uh the proportions of their, the likely proportions of their users who would be able to benefit

Speaker 3: from the uh from particular from AVIF support. And I wonder if you could say something about that.

Speaker 5: Yes, so AVIF is a is a great one because if your users support it, there is no reason not to use it. which is amazing um some instant instant benefit from setting it up um so the support actually is excellent these days the only modern browser that doesn't support a vif is microsoft edge uh all of the other major ones do support it. And I guess on mobile devices specifically, this supports in iOS is only from version 16, which is from a year ago. So people do upgrade quite quickly. I think the one thing worth noting perhaps is uh for the users who don't support AVIF , the way we've set it up in Wagtail actually acknowledges that very well and always makes sure there is a fallback version of the image so that's people can see the image no matter their device it just gets a smaller size if they support Avif.

Speaker 5: Thank

Speaker 3: TV I think we're gonna move on from here and I'm going to introduce the uh a piece from Rich at Springload. Springload are uh uh an agency based in New Zealand who have been very long time supporters of and contributors to Wotel, I think probably the the original kind of agency after Torchbox who were who were involved. In Wagtail, and uh we're very grateful to them for all the help and support they've given us, and we're also grateful to them for Thibaut himself, who was uh once a Springload developer before he moved to the UK. And uh Springload have kindly agreed to share

Speaker 3: uh one of their some of their experience migrating one site to another. And um so uh because the the time zones aren't great for a New Zealand presenter. They've prepared this ahead of time and I'm gonna share it now. Just let me know if you have any problems with the audio. There were a couple of glitches last time, but I'm pretty sure I've I'm gonna have cracked it this time. Here we go

Speaker 6: Hi, my name is Richard, and I'm from Springload. We've been working with Python and WhiteTel since around 2014. We like using things like React, Ploomi, AWS, and double-in other technologies. Anyway, on to the talk. So today I'm going to be talking about an approach that we use to migrating a large content-based website in New Zealand. The site in question is the site for Massey University, a large tertiary educational institution , serving a large and diverse audience from around the world. and online courses as well for a large cohort of international students. There's of course a very deep

Speaker 6: content and functional hierarchy within the site. And so Rebuilding it in its entirety was not really something that was feasible. They were looking to replace an aging CMS system around That was around 15 years old. And the Big Bang approach was not really feasible. And this is often the case for sites of this size or class. So before I get onto what our solution to this was, some quick credits to Eugene, our most excellent. DevOps lead at Springroad who took the lead in developing and iterating the approach here. Cool.

Speaker 6: So how did we do it? It's a fairly standard Wagtail deploy on AWS, containerized workloads, load balances, CDN, etc. And we use we by default we use Nginx in front of our Wagtail containers and we find that. really super useful. Nginx pretty much serves as a reverse proxy and for this particular use case it proved to be super useful. So just a bit of detail on how this works at a kind of conceptual level at least. It's interest pretty simply put, user requests a page for it at a particular path. We then intercept the response, see if it is a 400

Speaker 6: series response. Otherwise, everyone's happy and they get the new page from the new Wagtail website. The response from the Wagtail instance is a 400 series, then we will go and try and request the same path from the old website or the legacy service and then return that if that exists Hopefully that's fairly straightforward or clear. So this for example is what a legacy page looks like and you'll notice that we have incorporated the new style menu at the top and that can be used by that can be done by hot linking to the new styles or um making some small amendments to the header and footer of um the old service or perhaps using iframes or a similar approach

Speaker 6: By doing so you get a fair amount of consistency for design while still being able to serve the old content reasonably well. So how did we accomplish this in code? I'm very roughly going to talk you through this. So we start by defining our proxy backends in the Nginx. um b-host configuration. We'll notice the top we have the application server listening on port 8000, that's the Wagtail instance And then the proxy service on the on the second line missing on port 8081, which is the legacy service. It's marked as a backup and has a lower priority. We'll then set up the Wagtail server and have it listen for

Speaker 6: a 400 series response. the crucial line being highlighted there, the proxy next upstream, which will then direct Nginx to direct that particular request. to the legacy proxy service which is configured here. And all fairly standard stuff, which will ideally then return the service. I mean return the page So just a quick wrap up, some just cons quick considerations for this sort of approach. It allows for kind of graceful bite-size migration of content so you can slowly eat up particular paths on the site. You may want to use a kind of header and footer approach to get a reasonable amount of consistency

Speaker 6: From the content, you could do things like sharing style sheets across or between the two services or craft one specifically for the legacy service to bring it in line with the new style content. One challenging bit we found was um coherently indexing content or search services across these two sites. For this we used a kind of crawler-based approach, specifically using Swift type Another good out take is well something that we've learned over the years is that N Nginx itself is super useful. It has awesome proxying, caching, and capabilities and can really save your ass in many situations. And even if you don't have Nginx, you could probably achieve something similar.

Speaker 6: Not that we've actually tried this, using other servers like Apache. or looking at something like edge functions like Lambda at edge and cloud front. Anyway, I hope that's been useful for everyone. Thank you very much. Any questions or comments, hit me up and check out our GitHub. Thank you very much.

Speaker 3: Thank you very much to Rach and Springload. I know that many of you are working on sites that didn't originate in Wagtail and hopefully some of the techniques that Rich outlined there will be useful as you think about content migration projects As Lisa said during Richard's talk, then we're really keen to have more guest speakers on in this in this webinar. So if you've got interesting stories about how you're deploying MITel tips and tricks you've learned along the way, please let us know and we'd uh love to showcase them. But for now I'm going to hand over to Megan.

Speaker 7: Hello everybody, I'm Megan and you've seen me around the Wagtail community. Let me, I'm going to give you an update on what the developer relations team has been doing. And so we uh launched the developer relations team back in March. And uh since then we've had a p pretty consistent group of people who have showed up. We definitely had uh some folks pop in and out. But this is our kind of core group. So I'd like to just go ahead and uh thank Tiago, Thibaut, Savar, Damalola, Loveth, and also I'm a part of the team. For meeting regularly and like making all the things that we've worked on happen.

Speaker 7: And we would love to see this group grow and we would love to see more people on this page as well. So what do we do exactly? Well, uh the developer relations team is we're champions for Wagtail. We want to encourage everybody. to use Wagtail and to benefit from all the great things that Wagtail has to offer developers and users and share the solutions to problems that we have found. But it's not just about like, you know, shouting about Wagtail on social media. It's also we want to make sure that Wagtail continues to provide a good experience to the developer community and to users. So we also investigate developer and community needs.

Speaker 7: And we ultimately are dedicated to making the Wagtail developer and user experience even better than it already is. All right, so some of the things that we have worked on and done so far, uh one thing that I wanted to share is we now have a new community resources page. Uh we observed when people were joining the community. that it was a little hard to find everything that we were including as resources for new people. So we put them all together, all on one page. And we can now send out one link and everybody can bookmark it and be able to find all the resources together in one location. Another thing that we've done is many of you probably participated in the Wagtail Deployment Survey recently.

Speaker 7: You probably heard me shouting about it on social media. And so we were curious to see kind of what the like where people were deploying to and what sort of problems they might be having. We found out, you know, there's a pretty decent tie between AWS and DigitalOcean for most popular hosts and a lot of other interesting results. And that was the developer relations team's work. Also, thanks to some work from Tebow , we will be launching a Wagtail store soon on Freeware. Uh so you can buy your own Wagtail swag and get your own stickers and mugs and all the other things that you need in your life to show how much you love Wagtail.

Speaker 7: Now, we're going to definitely continue to do cool things like this. So how how can you join in? Because we'd love to see more of y'all help us out with this. You can go ahead if you're a part of the Wagtail Slack community, join our channel. It's hashtag developer relations and Slack. You can also come share your ideas with us in our bi-weekly check-in meetings. They're on Fridays at 1500 UTC. Our next one is tomorrow, and you're more than welcome to join. And our next kind of big effort for this team will be around finding people to contribute Wagtail starter templates and make the most out of our new Wagtail Start command that allows you to load a template. as well. So please come join us.

Speaker 7: We'd love to see you all there. Back to you, Tom.

Speaker 3: Thank you, Megan. And uh thank you in the chat for the ideas about what we might call our swag in the future. I think swagtail has it for me. I'm going to hand over finally to Lisa who can tell us about some upcoming events.

Speaker 1: Yeah, just a few events that we've got coming up to tell you about Wagtail events. So first of all, we are going to be at DjangoCon, which is happening in North Carolina, Carolina, from the 16th to the 20th of October. Apparently all the talks are going to be available online afterwards if you can't make it to the event. So we have got Tibo doing a talk on Django's accessibility track record, looking at what Django does now and what can be improved. Sage will be there and he's going to share how you can benefit from powerful content management features for your existing Django models with Wagtail And Wagtail Core Team Developer Scott Cranfill from NASA is doing a talk on best practices for making a Wagtail site as accessible as possible.

Speaker 1: And the Legend Orn Wages is going to be there, sharing tips, tools and settings for VS Code, the lightweight free and extensible code editor to optimise your Python activities. And we have a joint booth there this year as well with Code Red. So Code Red and TorchBox are going to be there and we are purely dedicating it to promoting Magtail And doing live demos and raising awareness of RCMS. So come and say hello if you're there. It would be great to see you And then after DjangoCon, Megan is hosting a virtual workshop where um with Sage as well now. So they are going to be showing how to combine Next. js with Wagtail. To get the best of both worlds, so you can have the delight of Python in the back end for business logic and the advanced dynamic UI is powered by React

Speaker 1: And then we have a couple more events in the pipeline, which we're just working out now. But so building on what Tiba was saying earlier, we are going to host a digital sustainability event to look at Wagtail sustainability credentials and also just look at other ways to reduce digital carbon emissions And then in January, we're going to host an accessibility event where we can promote all of the fantastic work on Wikitel and also best practice tips and advice for all digital platforms. So loads coming up and finally Wagtail Space is back. So next year, June 2024 Wagtail Space is going to be back in person. So it's going to be happening at

Speaker 1: Wharton at the University of Pennsylvania in Philly and hosted again by four digits in the lovely Arnhem in the Netherlands So they will be on two different weekends. The final dates are to be confirmed, but it will be in sunny June. And all of the details will be finalised in January, but we'd still love you to register your interest right now to see if you'd like to be involved and start thinking about your talks. I'll share the link to register in in the chat and the follow-up email.

Speaker 3: Thank you, Lisa, and thanks to everyone who's who's worked to make this happen. Really excited that Wagtail Space is happening. two countries next year and then I really hope to see some of you there in uh in one or both places But apart from that, I think that's it from us today. So thank you to all my co -presenters and thank you all for coming, listening. See you. Online in about three months and maybe in real life in June next year