Updates in Wagtail releases 6.3, 6.4 and what's in 7.0

Speaker 1: Hello everyone and welcome to the latest edition of What's New in Wagtail. For those of you that are new to this event, welcome. I'm Lisa and I handle our marketing at Torchbox and I help pull together these events. for Wagtail, so thank you for joining us. We use these sessions primarily to demo exciting new features in the latest release as well as take a look at what's ahead or in the pipeline and a look at the roadmap But if you're keen to find out more about Wagtail CMS as a whole, check out some case studies or give it a go for absolutely free or book a demo. If you head to wagtail. org after the webinar, you should be able to find everything that you need to know there. Now let me introduce our speakers. So

Speaker 1: today we have Matthew giving an update on progress with the autosave feature. We've got Sage who's going to demo some excellent new stream field improvements. We also have Mizu, we'll share an update on what the Wagtail. org team has been up to. Megan is going to give a community and events update. And last but definitely not least, we have Thibaut, who is also your compare for today. And he is going to cover some accessibility improvements in honour of Global Accessibility Awareness Day, which is this week as well. and give a glimpse at what's ahead on the roadmap. We are recording the session just so that I can send it to you afterwards and you can share it with all your friends As long with any extra links or resources that we reference, I'll pop those in the email as well.

Speaker 1: As this is a webinar, you can see us, but we can't see you. But we'd love for you to get involved with the chat, which I think everybody is going to be. very up for today. If you've got questions, it's best to put them in the Q<unk>A just because it helps us to keep track of those. We are going to have time for questions after each demo and some time for questions at the end as well. So I think that's about it from me. So I'm going to hand over to Thibaut.

Speaker 2: Thank you, Lisa. Hi everyone. Thibaut pronouncer he, him. Uh yes, a quick state of Wagtail to get us going. And uh some of you have already seen it for sure. Why 7. 0 is out. It's a big version number and there's a few things in there that we'll cover in today's session, but I thought I'd mention one first and foremost, which is the fact it's a long-term support release. We've changed our release cadence in order to ship our Django 5. 2 support and have our long-term support. uh be concurrent with Django 's for as long as possible. So that's 18 months during which this new version of Wagtail will get all the bug fixes and security fixes. as well as supporting the LTS of Django

Speaker 2: itself. And yeah, lots more in this release that I'll let my colleagues go through. I thought I'd get us started with a shout out as well for our latest Google Summer of Code participants. For people who might not know, GSOC is a program organized by Google every year over the summer, and they pair us up in open source projects like Wagtail with promising contributors. We've selected four projects and four contributors this year. Rohit Sharma, Chi Meso Akujobi, Joel William and Drovi Patel And uh this is the most GSOC projects we've ever had and I'm very excited that some of the people in here are on this call, both as panelists.

Speaker 2: and also as participants. So Chiamizu and Joel, lovely to have you with us today. Last quick note on Wagtail updates, GenCon Europe, we had a blast. Megan will share some pictures with you later today, but I thought I'd drop a link if you want to see the smiling faces of uh Sage, our contributor Vince and I. They're all in here And uh yeah, lots of exciting things and back to the $7 release. I'll hand over to Matthew.

Speaker 3: Thank you, Thibaut. Let me just share my screen. Hopefully you can all see that there. So it's often the case that the most important changes to a product like Wagtail are not the most dramatic or exciting to show off and this is one of those times. So here we're working with our familiar Wagtail Bakery demo site. I'll start a new blog post and Once that load, you can see that several of these fields are marked as required with the red asterisk And in earlier versions of Wagtail, that would have meant that you had to fill those fields in before Wagtail would accept it as valid and consider doing anything at all with it, even just saving as a draft or previewing.

Speaker 3: But now as long as you have a title, which I'll add now, then that's uh All you need to be able to save an incomplete page as a draft and we can then leave that, come back to it to review editing. And it's only at the point of publishing or submitting to a workflow that these validation rules are enforced. And throughout this editing process you can see the uh the the preview in the sidebar updating continuously. Again, yeah, previously that uh that would uh require you to have all of the page content to be in place first.

Speaker 3: And this is one uh point where this might need some extra attention from you as a site developer. For example, if your uh If if your page template had extra logic to translate the date into X days ago or something like that, then you might need to code a bit more defensively to deal with the possibility of that date being blank where previously you could always rely on it being present. But other than that, this change of behavior comes essentially for free with the new version of White Tail. For text-based fields, including rich text, the new behavior happens automatically. And for non-text-based data, such as the date

Speaker 3: field here then you might have to make a small change to the schema. So in this case you would have to add in an explicit null equals true alongside the blank equals false. Which might seem a bit contradictory but that indicates that this is still fundamentally a required field of the page as far as publishing it isn't concerned, just that we need to accommodate at the database level this draft state where it might be empty And we hope if you find that this aligns better with uh how you think of uh draft versions as work in progress. Uh so it's like yeah, so let me just show that uh

Speaker 3: That is now accepting it. Now I've filled those in. So but uh it should be sort of a big advantage not to have to fill in fields with uh fix me to do while you're still working on it. And it also brings us a step closer to the much anticipated autosave feature. After all, if Wagtail is saving your progress in the background You'll want that to happen as soon as possible in the creation of the page, rather than it having to meet some threshold of completeness. And in recent Wagtail versions, the idea of saving as draft isn't limited to pages, so all of this applies to snippets too. uh if they've uh

Speaker 3: been configured with uh draft state and revisions. Uh the uh so a snippet It can have any set of fields you like. There are no standard fixtures like title. So in some cases you might find that the new behavior is a little bit too extreme, allowing you to save items with no data in them at all. We've made sure that if you do have uh things in this category, then There's some reasonably sensible behaviour in the admin in this case, so that it still shows up meaningfully in listings and there's something to click on. But It's uh a simple one-line change to um to dial things back to the old behavior

Speaker 3: so that a field is required even on saving a draft. So in that case that would be required on save equals true and if I save that and wait a moment for that to reload Now if I try to resave that that now even just as a draft That is no uh required field, uh so that's uh that is uh just the minimum needed to save a craft here. So this brings us on to the reasoning for this being 7. 0 a major version bump for Wagtail. Uh since we adopted semantic versioning in Wagtail 3. 0 and 4.

Speaker 3: 0, we've we've taken the position that major version numbers are not primarily a market tool, but a way to communicate the presence of backwards incompatible changes that developers should be aware of. This is a fairly fundamental shift in how validation works, which you'll need to take into account particularly if you're doing things like importing data from outside systems and relying on validating that input. when saving as a draft. But from the feedback we've had so far, uh people feel this this is a ch very much a change in the positive direction that better fits how editors think about how draft state pages and snippets behave

Speaker 3: and yeah we hope that you'll feel the same way. So and on that note I'll hand back to Thibaut.

Speaker 2: Thanks, Matthew. That's super cool. And I definitely know editors out there that have been clamoring for this and be super happy. I see a lot of great questions, so I'll get started. What about headless preview? We have the Wactail headless preview package. Do you know if that already supports this default validation?

Speaker 3: Oh, good question. Um I believe it does. I've not tried that combination myself, but uh it's uh so ev everything Uh so the the the ability to save things with incomplete fields is uh that is done by kind of modifying the behavior of the validation at the Django level. So That should allow it to save as a draft and then you should be able to retrieve that as as JSON for the headless package to work with. In that respect, yes, I believe it should still work. Uh work in the same way. Yes.

Speaker 2: Makes sense. And um We have a question next from Ryan Sullivan asking if it's possible even in this new paradigm for a CMS user to still request the full validation without necessarily publishing or starting a workflow.

Speaker 3: Ah, that's a really interesting one. Um yeah, I don't think we have anything uh that would um do that at the moment. Um I think it would be something that uh would be possible as uh an extension, just adding a new action to the uh to to the uh publishing to to the drop up menu at the bottom of the page to say publish and valid uh sort of save and save as draft and validate. Um yeah, that that might well be a a good enhancement for Wagtailcore in in in the future.

Speaker 2: Cool, cool. And we have time for one more question from Michael Cheatham asking if we've given configuration to the use case of someone going to the edit screen. And not wanting to autosave, not wanting to save, not wanting to publish, uh, what happens if you just open the page? Is there anything saved in the background or is it left as is?

Speaker 3: So yeah, the yeah, so so having an additional choice to effects lease, yes, save and exit, that is something that's uh come come come up a a few times and uh I think in the core team the feelings on that are a bit divided. Um as it's uh it feels to some extent maybe a bit of micromanaging sort of it's details that you don't really want to think about what editors have to think about, but uh Yeah, I know I know there's uh strong feelings both ways uh uh on that one. Um so yeah, I th I think that's it's definitely been considered and hopefully we will have a definitive answer on that one soon.

Speaker 2: Makes sense. Thank you, Matthew. Yeah, super cool stuff will make lots of editors happy. And uh we have more things that are gonna make editors happy. Over to Sage with stream field improvements and preview improvements.

Speaker 4: Thanks, Thibaut. Let me share my screen Alright, hey everyone. I'm going to show you a few improvements we made to the page editor to make your experience even better. The first thing is previews for stream filled blocks. So what you see here is a stream field with a few blocks. But on a project that has dozens of blocks in a stream field, it might not be easy to quickly find the right block type to use. I'm currently editing a page for the whiteo. org website and I don't remember what any of these call to action or CTA blocks mean, so I don't know which one to use. And in Wagdell 6. 4, we added a block preview feature that lets you see what the block

Speaker 4: looks like before you use it. Now I can tell the difference between these CTA blocks, so I can choose the correct one. We initially designed the feature to display a static image for the block. However, to ensure we give the best possible experience for both editors and developers, we held a poll on GitHub discussions. And after hearing your feedback, we decided to make the preview dynamically rendered with Django templates. So this means as a developer, you only need to provide the preview values or like the placeholder values. And you can reuse your existing templates and the preview will automatically be be updated with any front-end changes So

Speaker 4: this also allows the preview to showcase interactive elements like hover effects for example. And of course you can also use a custom template that only displays a static image if you want. So we highly recommend developers to set up this feature to improve the experience of your content editors. The next thing I want to show you is a more intuitive way to re-order your stream filled blocks. Previously you need to use these up and down arrow buttons to reorder your blocks And now you can use this drag handle to drag and drop your blocks into position. And this works whether your block is

Speaker 4: expanded or collapsed. So if you're reordering a really long block, you can collapse it first and then reorder it. So hopefully this will make reordering much easier with stream fields. And oh this this also works with inline panels as well. And we have more improvements planned for the Streamfield editing experience in upcoming releases, as we recently just restarted our UI team. And we've been brainstorming for a way to make a group of blocks display separately as settings for the block. This could be useful for things that are not actually content, but more like styling options, for example, for how the block is displayed on the front

Speaker 4: end. If you have any feedback on anything UI related, please write on our GitHub discussions or join the UI channel on our Slack. And moving on, but still with the page editor improvements, in Wagtail 6. 3, we added the ability to have custom preview sizes. For the live preview panel. This makes it possible to have a wide range of device screen sizes from a very full very small phone to a 4K or maybe even 8K display, or maybe even unusual sizes like a foldable phone screen, for example. This feature is a contribution from multiple people in our community. We have Bart Cielinsky, Alex Kiro, and myself working together to make this happen.

Speaker 4: So thank you to our contributors. And getting out of the editor, but still with the community contribution theme, we also have an improvement to the listings. This time we have a brand new pagination component. The new pagination makes it easy to jump to the first and last pages, as well as the neighboring pages of the current one. You will also see the total number of items at the bottom right. This is a contribution from our community member, a new contributor named Jordan Teichmann. It's a great example of how you can contribute to the project. So thank you, Jordan, for submitting this feature. And that's it from me. Thanks.

Speaker 2: That is gold sage. People in the chat are loving it. I think you have a few fans in there And a few questions as well. Sophie Hagan asks, in the block previews, where does the text come from that's displayed in the previews?

Speaker 4: Um that's defined by the developers and uh currently uh that's one of the reasons why um the developers need to explicitly enable the feature. But yeah, in the future we might provide like a default value for the placeholders, for example, just your text here to allow the feature to be automatically enabled

Speaker 2: Makes lots of sense. And I see we have a question just like the one from Matthew about headless websites. How do you anticipate the block reviews will work for headless?

Speaker 4: Um so at the moment it doesn't work out of the box, but it might be we might be able to use similar tricks to the um Whiteel headless preview package, for example, by using uh nested iframe, but that's more of a workaround than proper support. So that's something that we'd love to improve in terms of just headless improvements in general in a future release. So yeah, stay tuned.

Speaker 2: Thanks, Sage. And um I see we have one more question that will take async in the interest of time. And um over to me uh talking about accessibility. Surprise, surprise. I can't uh be in one of these without having a little section about this topic. Uh This I mentioned at the start of the webinar that this week we had Global Accessibility Awareness Day. So I thought I'd share some stats and exciting updates for accessibility in Wagtail Starting with alt text, which is something we've worked on a lot over the years, and uh Chiemizu , one of our contributors for GSOC last year, will give us a good update about his work on alt text. But I thought I'd start by sharing some statistics about

Speaker 2: alt text quality or patterns we've noticed while reviewing Wagtail websites out there. So this chart here that's uh six specific patterns which we see across a large percentage of existing Wagtail websites That's on the order of 7,000 sites in this dataset. And all those patterns are things that are somewhat automatic. For example, if the alt text looks like a file name. Probably it is a file name and shouldn't speak in the alt text field in HTML. If the alt text is a single word Maybe that's okay, but for it to be such a prevalent pattern is a bit of a surprise. So why do I bring this up? Is because we have this uh alt

Speaker 2: text quality check in the CMS that we've been refining And at the moment it picks up on the order of 20% of the alt text of Fractail images out there. And based on those stats, we're gonna refine it over time. So the news here is just that this check is now enabled by default. So should we be picking up things on uh on your sites, you can uh you can thank us if it's a correct detection and uh if it's not definitely uh reach out and we'll adjust. And uh yeah, this is one of many checks that we have in the CMS. So uh keep your eyes posted over time. We'll definitely refine those checks, add more custom ones as we see problems emerging. so that Wacte

Speaker 2: websites are as accessible as possible both when they launch and also stay accessible over time. And uh talking about launching new sites, I'm very happy to share one of our new reporting formats. I know it's a very nerdy topic, but have to find the audience for it. There's no better time for that than uh global accessibility Wednesday. Um the VPAT format is really relevant to more and more actual users out there. Uh here we're looking at accessibility scores. of government websites built with Wagtail around the world. And on the left hand side of the chart, we have a lot of governments that have invested into Wagtail and where the sites are much better than the industry average scores.

Speaker 2: The UK and France in particular are very close to only shipping uh flawless, not flawless, but at least sites with no detectable issues and that's exactly the type of sites where we want to have this new reporting format which are follows the the VPAT template and it's called an accessibility conformance report. So I just want to share the existence of this report. It won't be relevant to everyone here, but I'm sure some people on this call will have an interest in checking it out. And uh yeah, um I believe we have a bit of time for questions, should there be any?

Speaker 1: We do have some questions, T -Bay. Well, one of them is a bit of a comment from Andy who says that the checks are really useful. And I'd love to be able to add custom checks too. Do you think that's ever a possibility?

Speaker 2: Oh, I I wish. So there's about ten lines of code between us. being able to support those custom checks and and where we are right now. So there's some work needed for sure, but not too much. I hope we can make it a reality. It's definitely useful for us to know uh what need you have for this. So we adjust how we set it up. So yeah, do reach out with um with that feedback. Um

Speaker 1: I actually had a question as well, Thibaut. What's the what are the most common issues that we find on Wagtail websites?

Speaker 2: Okay, uh great question, Lisa. Um they 're very simil similar to the uh industry average. So for people who might not know, there is this great report out there called the Web I Million that looks at the top one million websites on the web. It's always, always the same thing, which is color contrast. That's the most common issue you can detect with automated tools. and keyboard support, that's the most common issue you can detect with manual checks. So when we talk about accessibility in Wachtel, obviously these two are super important. But Wachtel itself as a CMS doesn't have too much influence on it. So talking about Waxel issues specifically, they must come on these alt text issues. And that's why we've been still into this so much. And then the other ones, the other ones on this screen here.

Speaker 2: about um having proper heading hierarchy and proper labels in the relevant places.

Speaker 1: Brilliant. Thank you. We've got a couple more now as well. So Michael Cheatham asks Um is there any work being done to find inaccessible documents that are downloadable from a Wagtail site?

Speaker 2: Good question. So when we say documents in Wagtail, that's probably the built-in documents feature which allows file uploads and uh that's most commonly files that are either PDF or docx or spreadsheets. So just by nature of those files, it's quite tricky actually to run automated tests on them and the training even to do manual tests is quite lengthy. So to my knowledge, there is no integration between any of those kinds of proprietary, often expensive testing tools and wactail, though that is that is definitely possible. When people ask for guidance on this generally, I always recommend to not have documents as PDF only, as the only format. So it would be okay to have inaccessible documents as long as you had

Speaker 2: alternative formats without those issues.

Speaker 1: Brilliant. Thank you very much. I think we'll move on. So back over to you now, Thibaut, to tell us where you please.

Speaker 2: You can tell I get excited talking about accessibility and I could be spending the whole event just on this. Yes, so roadmap. Thank you, Lisa. I thought I'd spend some time showcasing what we're up to next. People here might not know that we have a public roadmap for BackTel, which we're very proud of, and uh we try to be very transparent about uh how we manage it, make sure that it stays up to date. And if I scroll through the page right now, you'll see the 7. 0 that we've just shipped. as well as what we have planned for the August release of Wagtail. So I mentioned Google Summer of Code already. We have some headless improvements that are going to be very relevant based on people's questions here. I saw someone in the chat mentioning they were very keen on cloud security policy.

Speaker 2: Lots of interesting stuff on there, but I thought I'd showcase something that actually isn't yet. which is potential SEO improvements. We call SEO power tools, that feature. And it's a suite of improvements we've been working on for quite a while now, almost a year behind the scenes on prototyping. specifically about better SEO capabilities with a focus on um specifically QA so uh assuming that you already have content you might be happy with in the CMS You've already invested time into managing it within Wagtail and now you want to refine it and make it better. And uh I think here I probably should just let the demos talk rather than do the talking myself. So hello over to YouTube and showcase some of the work

Speaker 2: from my colleague Ben So top right here we have a notion of keeping tabs of the pages metrics over time What's really interesting about this is that it's not just like Google Search Console or similar where it gives you feedback on your page as it is live. The goal here is very much to give you feedback based on the page as you're drafting it at this point in time. So you might even be able to compare the metrics of your current drafts and the live page side by side. And yeah, it's SEO as kind of the overla overall theme, but there are things on there that are also about accessibility, like uh like the reading time feature here. reading age.

Speaker 2: That's a very common thing we're asked to have in Wagtail. And um earlier today when we were discussing uh possible custom checks, uh the SEO checks, that's a very very good place for us to start if we could branch out towards uh supporting this so here in the bottom right those four issues found they're all SEO focused And for each of them what's really interesting is as well as uh providing the oh there is a problem there, we also have the option to generate a potential fix for the problem. So Some of these they might be fixable with very simple automation. Some of these we might try and have some AI integration that I can leverage to propose a new meta

Speaker 2: description, for example. And uh yeah, I'll skip along further into the demo and showcase some of the other cool prototypes that uh that Ben has put together. So there specifically we have more QA features that I really like a very simple one, those meta description fields that we already have in Wagtail. just being able to set a maximum length for those fields that's not necessarily enforced, but at least advisory that will be better for the performance of the page if it stays within a single given character count. And uh yeah, similarly having a live preview of the page metadata because it's very common for this to come out from very different fields in the CMS. It's actually possible for us to

Speaker 2: completely sidestep all of that and always display exactly the meta tags that are just as a search engine would see them. Um yeah, lots of very exciting QA tools in there as far as the current drafts, but also as far as uh sites with thousands. hundreds of thousands, maybe even millions of pages. So potential for some reporting out there. And just like many of our roadmap items, this is something we're hoping to generate a feature sponsorship for. So people might not realize how many of Wactail's features these days are sponsored. And it definitely helps us. bring those improvements faster when we partner with an organization that has a need for this. So if you're interested, if you want some of those SEO improvements,

Speaker 2: do reach out and we'll figure out how to make them available in upcoming release.

Speaker 1: Brilliant, thank you, Thiba. It's really exciting these changes. And Megan has dropped the YouTube demo into the chat as well, and I'll send that in the follow-up email as well. Ahmed asked if there is a plan to support content metrics and accessibility checks for headless setups

Speaker 2: Yes, I should have uh kept my screen sharing. So I believe that is it officially on the roadmap? We still have our upcoming release roadmap uh in progress and uh the features not settled yet. But if we look in uh the future bucket of our roadmap Headless preview here, the idea that this would ship inside Waxtail itself plus headless user bar currently TBC but likely to come in the next release. Combined these two things will mean having accessibility checks in headless setup without too much extra work compared to a traditional water websites. And once that's shipped, adding those custom checks as far as SEO

Speaker 2: or the organization style guide or maybe a check as far as page weights, that'll be the same amount of work regardless of how the site is built.

Speaker 1: Brilliant. Thank you very much. I think that's all of them, Thibaut.

Speaker 2: All right, uh thanks very much. And um yeah, I think there's still time for questions in the chat, but uh we'll hand over to Megan and Chimizuo talking about Wattel Delog and uh yeah the recent alt text work from Chimizuo on them.

Speaker 5: All right, let me get these slides up here. Do do do All right, everybody, I'm here today to share with you uh what's new on Wagtail. org And so the first thing I want to do real quick is uh we've recently been much more organized uh around maintaining and uh keeping Wagtail. org up to date. So I just wanted to go ahead and throw these names and photos up here. To thank everybody who has been contributing to the website and helping us uh keep it uh

Speaker 5: up to date and in the best way possible, including some, you know, some people who've made some very tiny contributions that have gone a long way. So thank you, thank you, everybody who's been a part of the web team. So what have we been doing on the web team? Well, for one thing, we have been making it a goal to keep Wagtail as up to date as possible with our new releases. So we currently have Wagtail 6. 4 on Wagtail. org. We should have 7. 0 up this week Also, thank you to the creator of Wagtail Newsletter who's on this call, Alex Morega. We are bringing Wagtail Newsletter to Wagtail. org. And we've also done a few other sorted things to keep the content clean and uh make sure we do a thorough user audit and keep bugs to a smaller

Speaker 5: uh part of our work and things like that. We've also been investigating some better ways to do test data in Wagtail. It would make it easier for more people to join the web team. We're still working on that, but I will hopefully have some progress on that to share with you in the future. But the thing I'm most excited about is that we have recently added the newest version of Image Block. And the reason I'm excited about it is this was a Google Summer of Code project. And we have gotten to see this project go completely like from creating the feature to bringing it live to Wagtail. org. And so I'm going to turn it over to the person who created the feature, Chumezo Akuchobi,

Speaker 5: who will tell us the story about how it went.

Speaker 6: Hello everyone, I'm Chi Mezu, but you can call me Mezu for short. So looking at the screen, we have an image and two pieces of alt text. And clearly we can see that the second piece of old text is really horrible in comparison with the first. And to reference what Thibault said earlier The second piece of alt text here happens to be the second most popular alt text issue. And we couldn't have this on Wackill's site. So we decided to come up with a solution. Next slide, please. Right, so to come up with the solution, we had to first understand why this was a problem in the first place. And um we got to realize that it was as a result of editors not understanding the default behavior

Speaker 6: of image uploads. So to fix this, we decided to give them a new option, an alternative that would not only fix the problem, but have a zero or rather near zero implementation efforts. That was the creation of the image block. So that brings the question, what exactly is the image block? So next slide please. Right, so on the left we have what was the existing convention at the time, which was the image user block. And by the right, we have the new image block. So you can see that there is a difference in giving users the ability to either put all text or make it as or mark it as decorative. This feature in itself paved way for something else, something called contextual alt

Speaker 6: text. Now, an image can have alt text that could be good, but depending on the context in which the image is used some alt some pieces of alt text can be better and I'll explain that in the comment slide. Please next slide. Right, so going from the before which was the image user block to the after which was the image block. It wasn't a straightforward journey and it wasn't as easy as we think. It took a couple of iterations to get it correctly, some of which was dependent on user feedback and As a result of our trying to upgrade the workfield. org unsuccessfully at first. So along the lines, we encountered some UI bugs, which ended up getting fixed. But the biggest bottleneck to moving from image user block

Speaker 6: to the image block was an enforcement issue. So on pages that had lots of image content using the image user block On switching to the image block, there would be an issue where the page would throw errors at every image that didn't have an alt-text field and that wasn't math as decorative. And this stopped us, stopped us at workil. org from upgrading and we took the feedback and decided to work on it, which we eventually did. Now that brings me to the final implementation of the image block. Next right. Alright, so by the left we have um a picture of what it would look like if you use

Speaker 6: the image block with the title, which in this case would be screenshot comments. Oh, and by the way, this was real alt text from an actual Wagtail site. So it would default to what the title was, fixing the enforcement issue, but also prompting users with a very nice UI that they could use to. basically override this. Now the beauty of this image block feature is because in this case you could use the same image On a particular page multiple times with different alt text. And this in no way affects the existing image title or anything else about each instance of an image So this was what I got to work on and thankfully I not only got to initiate the building and development of the feature, but I upgraded the Wack

Speaker 6: Tail site to use the latest version of it. And that's something I'm very proud of. So on this note, I would like to hand it over back to Mega.

Speaker 5: And we're very proud of you too. So I must say I definitely enjoy like that that alt text was getting a little embarrassing and I really enjoy having the tools now to go back and fix it and make it better for any screen readers who come to our site. Alright, y'all. So I have a short community update for you here. First of all, I just want to share a couple pictures from DjangoCon Europe. uh where we had a bunch of folks go and uh to Ireland uh and give talks and celebrate Django's 20th birthday complete with cake One of our contributors, Vince Salvino, gave a great talk on all the things he's learned from deploying thousands of Django and Wagtail websites. If you haven't seen his talk on YouTube, I definitely recommend it.

Speaker 5: All right, what do we have coming up in terms of events? Well, I'm going to be at PyCon this week, and if you would like some Wagtail stickers, come find me. If you're going to be at PyCon US, I also will be at the Django booth in the exhibit hall and helping out our friends in the Django community getting the word out about Wagtail and Django. We also are probably going to have a presence at DjangoCon US in Chicago coming up in September. So if you're planning to be there, we would love, love, love to see your face. But more important than those events is our own event. Wagtail Space is returning in October.

Speaker 5: We are doing a virtual event this year so that we can bring the whole community, no matter where they are in the world, together. Currently we're planning on broadcasting from October 8th to 10th. And stay tuned to social media, to the newsletter. We will have a call for proposals out relatively soon. And we'll also have more details on the schedule and the format. But how will we determine the format? Well, we actually need a little bit of help with that. So right now I'm putting out a community survey to get an idea kind of what would work best for the community. uh because we definitely would like to pick some times that make sure that everybody has a chance to participate in Wagtail space.

Speaker 5: We also have a few other questions uh about the community in general that we're looking for your input on. So yes, please uh give us your opinions. Uh we, you know, everybody in tech has opinions, so I'm sure you'd love to share them. And they will definitely help us uh go a long way towards improving the Wagtail community. All right, and that's your community update. Back to you, Tebow.

Speaker 2: Exciting times. I have my Wagtails face stickers ready, and I believe they might make an appearance at PyCon US as well Uh don't see any questions from the chat, but I do have one for you, Megan. Uh how many proposals do you want? What kinds of proposals, what kinds of talks do you want to have at Wacilit Space?

Speaker 5: Oh goodness. I mean I'll take as many proposals as y'all are willing to throw at me. But we're looking for a mixture of this year of both developer and tech focused talks and also we would love to hear more from content editors and people who spend the time writing and publishing in Wagtail. We'd love to see some case studies from different groups who have used Wagtail for different types of projects. You know, if you're the type of person who has decided for whatever reason you're going to bootstrap Wagtail into some sort of mutant database thing, you know, I'm sure we'd love to see a talk on that too.

Speaker 1: I think we'd actually love to see all loads of talks. Well, like if there's a speaker that you find you've seen at a different event, like it doesn't just have to be about Wagtail either. If there's just someone that you've seen that you think would be brilliant that we should try and approach and beg to come and join us at Wagtail space, then let us know that as well I think if there's no more questions, then we can wrap up. We will send all of the links in the follow-up email and a link to the recording as well, like I said. So thank you everyone for joining us and being so engaged in the chat and questions today. And thank you very much to all of our speakers as well. And we hope to see you at another What's New Wagtail soon. Bye everyone

Speaker 2: Great to see you all