What’s New in Wagtail CMS | Release 3.0 | Accessibility, Streamfield Splitter & Image Duplication

Speaker 1: Hello everyone and welcome to What's New and Wagtail. As Tom said, it's brilliant to see lots of people returning to this webinar and also great to see some new names joining us today as well, which is excellent. Excellent. For those of you that haven't been to What's New Magtail before, I'm Lisa and I'm head of marketing at Torchbox and you are in for a treat today because we've got some great demos and talks lined up for you. So we have Tom, Thibault, Matthew, Jacob and Tidianne are all giving you updates and demos of features That are included in the latest Wagtail 3. 0 release. We also have Sage joining us today for the webinar all the way from Jakarta. So it's already gone 11 o'clock for him, so we're really pleased that he can be here

Speaker 1: and he's going to give you a demo on supercharged snippets. And we're also joined by Kuhn from Four Digits and he is going to be giving us an update on our participation in the Google Summer of Code program and also Wagtail Space which is happening in the Netherlands in June. So we are as always a webinar so you can see us but we can can't see you so but we'd love it to be interactive so if you've got a question if you can use the Q<unk>A facility it really helps us to keep on top of those but if you just want to make comments or chat or um give feedback then use the chat facility as well because we'd love to hear from you. from you. I am recording the webinar so that I can send it to you afterwards as well. And I think that's about it for housekeeping stuff.

Speaker 1: So I am going to pass over to Tom Dyson.

Speaker 2: Thanks, Lisa, and hello everybody. As Lisa said, the first part of this webinar, the main part, is going to be talking about some of the new features in Wagtail 3. 0, which many of you will know was released just a few days ago. But before I hand over to my colleagues to talk about some of those details, I want to point out about two of the things which are going to be, I think, obvious to all of you, not just developers. And the first one is the big number change. So we've gone from two to three. And there's a little bit of history. 1. 0 came out in 2015. And then 2018 was the first two release. So it's been over four years since uh we've been on this on the two 2. x release.

Speaker 2: You can work that out quite quickly because the version before the last was 2. 16 and we are very regular with our releases. We always do four releases every year. So 16 divided by four gives you four years. But this number change also represents something which is our switch to semantic versioning. This is a concept that some of you may be familiar with In summary, we're still going to be putting out a release every three months, but when those releases add a feature that either makes a significant visual change to the editor interface or which breaks backward compatibility, we're going to increment the big number, so like the two to the three to indicate this. This doesn't mean that we're going to be making more breaking changes. It just means that we'll do a better job of signaling them

Speaker 2: So in the past, maybe three or four of the releases in the 2. x would have counted as uh big number releases using our new system. Since the next version will include some, so we're on three now, but the next version, one coming up, since that's also going to include some significant improvements to how we model page data. We're going to be in the slightly strange position that we'll we'll jump from two to four in six months. But as Matthew put it when he made the case for this change, embracing that oddness is part of the deal of adopting semantic versioning. It also aligns us better with how Django releases are numbered, so it should feel familiar to most people in the community. I really recommend reading the discussion about this decision.

Speaker 2: Because it's uh, I think it's a great example of how changes like this are considered and debated in the community. And uh I'll share a link in the chat in a minute and I'm sure Lisa will share it in the post show notes too. The second thing that you'll be aware of with this release, both in the demos that you're going to see now and maybe when you upgrade your sites or if you've upgraded them already. are colours and fonts. And I think maybe some of you may feel a pang of sorrow about the reduction of Wagtail's familiar teal. But I'm also confident that you'll you'll soon feel happy with the modern fresh indigo that we're largely replacing teal with. In the same way, you might miss Wagtail's distinctive fonts on first glance.

Speaker 2: But I think the performance and consistency of our new system font approach is a definite improvement in legibility and user experience We're going to hear more about this in Thibaut's overview in a minute, but I just wanted to emphasize that the design overhaul is a work in progress. We didn't want to hold back improvements in this release, but you'll see the complete picture in August when we release 4. 0 Great. So now we have five short sessions on some of the headline changes in 3. 0, some for developers, some for editors. We're going to pause after each section to give you a chance to ask questions or please use the Q<unk>A feature at any time. With that, I'm happy to hand over to Thibaut.

Speaker 3: Thank you, Tom. Thank you very much. Hi everyone, I'm Thibaut. I'll switch over to a screen share right away. And I think it's well starting by as some as Tom just mentioned. This is very much a transitory release for us. So quite a big release in a lot of respects. At the same time, it's also going to be followed by a new release that will be even bigger. So we're very much looking for feedback on how you find the whole of the Bacteria UI in this version and also generally how you see this page editor evolving in the next release as well. So today I'm going to introduce a few of the visual changes in this release, which is again a bit of an intermediary step for us. and also the practical accessibility improvements we delivered to Wagtail in this release and which we intend to deliver in Wagtail's future releases.

Speaker 3: For people who might have been here in last wasn't it in Wagtail back in November, I have introduced Wagtail's accessibility statement. on our website where we formally state which standards we aim for, how we actually ensure Wagtail is accessible. So I just want to share this again for context, people who might not have been there. and also as a reminder of which standards we actually target which is we capital one at the a level as well as a tag at the a level as well You might not have heard of ATAG before. It's very relevant to us as a CMS because ATAG is concerned both with the accessibility of the editing interface for users of the CMS. and of the sites you create with the CMS.

Speaker 3: So today we'll hear a bit about both aspects of accessibility with Waxtail. And again, I think it's useful for us to start with an intro of the visual changes. So here I just have Wagtail 2. 16 as a visual reference. Should we need to look back at it? Obviously you have heard about some of the changes from Tom already. I'll jump straight ahead to YTAL 3. 0 now. And um we can see it's definitely this visually very different. Um I want to point your attention towards the sidebar. In some ways it's very similar, in other ways it's much, much neater , has a much more refined visual footprint on the page. particularly in uh this what we call slim mode, where you can choose to have a much smaller footprint with the same navigation features to the side.

Speaker 3: The header areas of the pages have changed as well. And if I move now over to the page editor, that's where really the biggest changes are to be seen currently. So again, just for the benefit of people being able to compare what we've done over time, I'll switch back over to 2. 16 for a brief moment. with the exact same page content displayed in both cases. So I have my bakery demo sites and I'm looking at the home pages editing UI now. And I'll switch back over to WattL Fridol. And I can clearly see that the heading area is much more refined, has a much smaller footprint. The types are different as well, but the main page editing UI still is using the Wiketail 2. 0 styles.

Speaker 3: And that's definitely something we are hoping to get to in the next release. I'll be able to share a bit more about this towards the end of my presentation. So now over at Silt, I want to highlight some of the specific improvements we've made. And what's really cool about those improvements, in my opinion, is that You don't actually have to be someone who uses a screen reader to benefit from them. That's uh often something people might find uh intriguing with accessibility improvements or do they actually apply for me or is it just for people who have those types of needs. In this case, the improvements we've been brought to Whitehead are all about better keyboard support. So I'll give you a few demos of this now. I'll move my keyboard focus inside the page and I can now see this skip to main content link.

Speaker 3: I was there before. I can now move my focus by tabbing through the main menu that was also there in the last release. No particular changes there. It works exactly like you'd expect. Which we are very happy about. Honestly, it's great to be getting to those inconsistencies over time and making sure people can navigate through those things as efficiently as possible. The big change is if I now move over to the main area of the page. I'll have my Breadcrumb components. And you can see compared to Wagner 2. 16, the Breadcrumb component has been condensed. So it at first sight it might seem harder to navigate, but again with the keyboard I can focus on this toggle area and quite naturally expand the whole breadcrumb and then

Speaker 3: tap my way through each of the items. If I now move over to this uh actions button, I can again uh trigger it to display the drop-down underneath. This actually was there in 2016 as well, just with a different visual style, but I thought it would be very relevant to highlight nonetheless, because this new drop-down style is one we intend to deliver throughout the whole of the CMS eventually. Right now it's only applied inside the page editor, but in future releases will be everywhere on all of the tooltips we have everywhere in the CMS. And uh behind the scenes, this component is what we've done quite a bit of research on to make sure that the contents of the tooltips. and of the actual dropdown can be accessed no matter how you use the CMS. So you might notice here before I opened this drop down

Speaker 3: there was an actions tooltip. As a screen reader user, this will become the label of that button. And as a keyboard user, as well as a screen reader user, I can move inside the tooltip and go through the items. And I can close that tooltip with the ask key, just like I would expect. Moving over to the right area of this header, we now have something we've introduced in this release called side panels. So I'll open this very first status type panel and I now have this area to the right of the page that essentially brings the same information as you might have had in the header in the past. as well as the information you might have had on the settings tab. So in Model 3. 0, we are again this intermediary step where we still have, we still retain this settings tab.

Speaker 3: as well as this status site panel. Eventually we're hoping for the settings tab to be much less relevant, essentially only be there if your specific site has a use for it. And otherwise, type of information we used to have on there would be in this status type panel. And again, I'm all about anything in LFXPT. So what I'm really happy with is the keyboard support for this. I can quite naturally tab my way through this, again still see the contents of all of the tooltips and move over to this side panel and again tab my way through that very naturally. And for screen reader users, we've taken great care so that each and every one of those sections has proper semantic structure so you can navigate to each of them right away

Speaker 3: should you need to. And in a similar theme, I think it's interesting for us to consider what we're delivering in the next release, which definitely is a bit of a step-up. So I'm now looking at a design file in Figma, not something we've actually built yet. If I compare it back to the version of the CMS we're looking at in my browser, you can see that the form styles have changed. And you can see this new component to the right, which we call the mini map currently. So this is what I'd like us to focus on a bit more, again, from the perspective of accessibility. What's really cool here is this type of minimap feature allows us to move to any part of the page very quickly with the keyboard. Once I've moved my focus to this area, I'll be able to quickly go to any of the sections of my form.

Speaker 3: I'm sure lots of people here will have worked with very long sites, very long pages now and then. I've heard the example of contract pages on sites managed by Ugov, which you might not have heard of before as a A regular sponsor of hotel features. Or for example, a page where you might have different tabs visible to end users And obviously in the CMS, all of those tags need to be there all in the same form. So this is where this type of feature shines. Regardless of whether you're a keyboard user or not, being able to move to a specific area of the page makes the whole editing experience much smoother. And again, as a screen reader user, I can kind of see that as a semantic table of contents for the whole of my page. And I can move to any one of these.

Speaker 3: And a nice additional feature I want to mention due to this new component is that if I hover over those heading areas here, I can see that each of those field panels will be something I can link to. Which again will be invaluable so you don't have to type your way through the whole of the page every time you want to go to a specific field. And I thought the best way to end this would be to look at the other side of the ATA extended that I mentioned earlier. which is about the CMS and also the sites you build with Wagtail. We've recently done quite a bit of work on benchmarking the accessibility of Wagtail websites. You might have heard of this project called the HTTP Archives Web Almanac, where they do a survey of all of the websites on the web.

Speaker 3: And in particular, one of the things they look at is uh how the sites compare based on which CMS they are built with. And right now I'm looking at their audits results for the accessibility scores, they've been able to calculate on average based on which CMSs the sites are built with. So with this type of data, I can see that White tail has a score of 84 with this lighthouse testing across all of the sites because with Whagtail they could detect And um we're very happy to have those numbers uh to start with because it makes it very uh easy for us to compare ourselves, to benchmark ourselves against the competition as well as year to year, how are we tracking and what are we building that helps uh drive this type of number forward. And

Speaker 3: again, this is just an average figure. There is no reason for us white tail sites not to be able to go straight to the top, have a perfect score. And for us as a CMS, the goal is definitely that we should be able to be the top one on this list, like we are with some of the other metrics. And a practical way we want to make this happen, which we might have talked about in the past, is bringing accessibility testing inside of the CMS as a built-in feature of the CMS. This is a core aspect of conforming with the A-TAG standard. So right now we're looking at integrating a specific plugin called SALI, which you might have seen in the past. It's this type of widgets that you have inside the page preview of the CMS and will be there to show you accessibility issues with your content as part of the page editing and publishing experience.

Speaker 3: So this is very much again just with the mini-map, something we're hoping to bring in WattL Fordodoo. And hopefully I'll get to demo that at the next segment in Wattel. Again, very much looking forward to feedback on any of these and questions.

Speaker 2: Thank you very much, Thibaut. We do have a couple of questions coming in and lots of nice positive feedback on the new look. The questions are not specific to accessibility, but I'll just raise them here broadly. Strother Scott has asked, when it's time to upgrade, will you be able to upgrade 2. x to 4. x or will it be recommended to go to 3 before 4? And I think Matthew is probably well placed to answer that Uh

Speaker 4: yeah, so um yeah we would recommend um upgrading the one version at a time. I think one uh the one the fairly notable uh change where that's uh relevant is uh switching Streamfield to uh to use the Django native uh JSON field um which and because that's a change that needs to happen on your own app in its own migrations, then there's a new parameter sort of use JSON field equals true. And that's kind of being sort of rolled out over the next release or two and I think that that will go smoother if you've got if if you are spending a a step on version three before moving over to four

Speaker 4: As far as the deploying to uh to to live to production, um it should still be possible to to go straight from two to four, but I think it's always good to, when you are upgrading, to do it a step at a time to make sure you've accounted for all of the uh the the the breaking changes like that

Speaker 2: and and though maybe there's something maybe there's a point here about uh UI customizations that that uh people might need to take into account

Speaker 3: Yes, this is this is definitely one of the releases where we've delivered the most on the UI side in particular and uh where we've changed quite a lot of things that were unnecessarily documented, but people were definitely using. So we've done quite a bit of work in this release to audit the right projects we have access to, both uh Toschboxy client projects, as well as the packages we see out there. and make sure they are largely compatible. Obviously this isn't always possible, but in the cases where this isn't possible, we've also been reaching out to people. So yeah, I'm hoping that this will largely be smooth selling for people who don't have customizations. And for those who do, we'll have quite clear guidance regardless of whether this is customization of something that's supported or not. So hopefully we'll make it very smooth.

Speaker 2: Thanks, Devo. There's also a question from Abdul Majid who asks, will Wagtail 3 be able to support most of the older Wagtail packages? Matthew, maybe one for you again.

Speaker 4: Uh yeah, so it's it's uh it's always a bit hard to sort of make any promises. in the case of uh of third party packages. Um but yeah as as Tebow has said we're um we're we've done with uh a bit of a an an audit of the These are major ones we're aware of to uh flag up any issues and I think there's quite a few of them have already been updated for uh for Wagtail 3. But yeah, it does depend on the individual package. So it's yeah, worth looking out for an updated version at the point that you uh upgrade to White Hill 3.

Speaker 2: Thanks, Matthew. And one more from our friend Loick. Hey Loick, would links to fields be available for stream field blocks or only model fields?

Speaker 3: Good to have you here, Lloyd. Good to see your name. That's an excellent question. I believe currently if I share the designs again just for visual reference. We were only planning to do this to model fields. So essentially the different areas you'd have within the page. I believe the only reason for this is just the user experience of this. If we were to make links to all of the blocks, it might become slightly clunky. There are too many blocks on the page. There's no technical considerations why that couldn't be done. So if you do believe it would be very worthwhile to link specific blocks, that would be excellent feedback for us to hear more about that use case.

Speaker 2: Thanks, Tivo. I think we're going to have to move on. If you have more questions about anything we covered so far, please keep them coming and we'll try and fit them in. We'll answer as we talk. But next, I'm going to hand over to Matthew, who's going to talk about field panels.

Speaker 4: Okay, yeah. So panel definitions have been the thing that uh powers the page editing forms right from the start of Wagtail's development. So here I'm showing the uh the um old faithful uh bakery demo site. Uh so you can see the uh the the editing interface for the homepage here. and the the corresponding panel definition where things are all sort of split into these subsections with multi-fuel panel and we've got various different panel types for things like the uh image chooser. And um and this sort came up this system came about as a way to handle functionality that isn't a native part of Django's form

Speaker 4: framework like the uh image choosers and inline panels, that kind of thing. And because of that remit of doing the things Django forms can't do natively, and that's not really a very well-defined one, they've never been formally documented And that's both a good and a bad thing. It's good because it means we've had the freedom to adapt them as new requirements have come up for things like adding custom form validation. But on the other hand, it means that they've become a sort of destination for ad hoc fix-ups, both within Wagtail itself and unofficially in outside code. And as a result, we've uh slightly lost sight of how people

Speaker 4: are using and customizing them and how they interact with the Django Form framework, which makes it difficult uh for us to do the more intelligent things we'd like to do with the editing interface, which would be things like um being able to duplicate uh uh inline panels in the same way that uh we have the ability to duplicate stream field blocks which um Those of you who are around for previous uh presentations may remember is uh something that we introduced the telepath uh framework to deal with. But Introducing that sort of change is a lot trickier when we're sort of dealing with this more free-for-all treatment of

Speaker 4: form fields in general. And the uh the one of the sort of eventual sort of wish list items here is uh auto-saving of this, which means that we would have to being able to be able to take the data from this page and uh uh and to push that to the server in the background. So for this release, we've formalized the uh the rules around what order things get initialized in and what what point you have access to the form class, that kind of thing. And we've uh written that up in this uh API documentation. Um and indeed one one of the one psychologically important uh part of that perhaps

Speaker 4: is that uh we're now consistently referring to these objects as panels. Uh previously the terminology was a mix of panels and edit handlers And that clarity around that naming reflects the fact that we now have this more rigorous idea of what these objects are doing. Now this does mean that if you have a site that's heavily customized in its use of panels, there could be a bit of a learning curve in upgrading to 3. 0. Uh as uh as always we've uh tried to cover this in the in the uh release notes. Um but uh in this case the instructions here are a little bit more open-ended than they would usually be

Speaker 4: because we can't totally anticipate what kind of customizations people have in place already. So It's a bit tricky to say you just need to change this bit of code to that. But uh for the majority of sites that are just using the built-in panel types, this should be a very positive experience because we've introduced a number of nice developer experience improvements along the way. And one of them is that the uh various different uh special purpose field panel types like image chooser panel and screen field panel. They've been uh phased out, so we can now use field panel for all of these. Uh this

Speaker 4: tended to be uh uh A common gotcha, if you forgot to use the uh like page chooser panel and just use field panel instead, you might find that things aren't rendering quite as as expected. But uh now these are all picked up automatically. So if we uh go back to the uh the editing interface here and uh if I refresh this You should now see that it's it's still as it was before, it's automatically picking up the uh appropriate chooser types and the uh and the screen fields. So yeah, it's one one less thing to have to keep in mind as you're uh as you're developing these. And uh another uh

Speaker 4: another nice addition that's uh come in along the way is the ability to uh designate certain fields as only editable by users with specific permissions. So here we're looking at the home page, which has obviously various very prominent pieces of content that you might not necessarily want an ordinary editor to have access to. So if I uh log in in this uh incognito window as just uh editor user and you see that uh Initially, this is all available for this user to edit, but we can add in an option to say

Speaker 4: permission. Let's make sure I spell that right. And uh this would take any uh permission code name that's defined at the Django level, but we can take a bit of a shortcut and say superuser, which isn't uh the uh really a defined name but we're relying on the fact that a a super user can automatically has any permission, so this will always return true. Whereas since that's unrecognized as a permission name, it won't be the case for an ordinary editor user. So with that change in place, we can now refresh that and you can see that's now not available for this user to edit, but as

Speaker 4: a super user I can still access that and change that to something else and then that will uh Let me sort of make those changes just as before. So yeah, it's a a couple of uh features here that uh we'll sort of improve the lives of uh editors and uh make things uh a a bit uh easier for developers too.

Speaker 2: Thank you very much, Matthew. There are a couple of questions on this, but I think because we're we're running it's a little bit tight schedule, I'm gonna ask Matthew to uh to Right a reply to those questions and for now move on to the next item which is uh splitting streams and Jacob's gonna take over Hi

Speaker 5: everyone. So as you're probably all aware, Stringfield is one of Whiteel's most popular features, but that doesn't mean we've stopped improving the user experience. In particular, in past versions of Wacal, one issue has been around kind of editing your stream fields when you've got really large rich text blocks. Let's take this one as an example. So it's multi-paragraphs and at this point in our editing process maybe we decide we want we want to split this up. We want um maybe we want to split it across the stream field entirely. Maybe we just want to add a new block in the middle that isn't supported inside rich text, for example, a block quote. So previously, and particularly in long screen force, that was a bit of a long-winded process before. We'd start by adding the new rich text block. We'd

Speaker 5: go and uh we would go and cut our text and we paste it down here And only then could we add in this new block, let's say the block quote we kind of really wanted to add before to kind of break up the monopoly of all that text. Obviously that's quite a few steps and we'd like to make that easier. And that's one of the features we've introduced in WacTech3. So you may have seen in a Wagtail talk, Waghtel Space Talk last year, the NYAPR, New York Public Radio, gave a really exciting demo of a proof concept they've got for something they call their Streamfield splitter, which let you break up rich text blocks into multiple blocks. We've been inspired by that to re-implement that in Wagtail Core itself on top of a new kind of more generic framework for how Streamfield

Speaker 5: blocks and how their widgets can interact with the Streamfield as a whole So here you can see we've got this new scissors icon. And this represents the new streamfield splitter. Let's say we pick this as our pointer split. So we simply pick it. We hit the streamfield splitter icon And you'll see the block split in two and it also um it also combinates all these other white hell features like comments. Uh So for example, you can see the comment here attached to shelf life. That's maybe nitpicking a little. Gets moved down to the second block. And we can simply, as cutting down a four-step process, we can simply add our new block quote in the middle here. So this is the start of a kind of more generic framework. We're hoping to use it for more editor experience enhancing features in the future.

Speaker 5: Things like allowing um us to move the carrot from the end of one streamflow block to another, which requires a widget to have knowledge both of itself and what other streamful blocks around it can do. We also haven't stopped on improving this feature either. At the moment you split and then you add in that extra block. We'd like to make this a one-step process. So in WagTel 4, uh we're interested in doing it simply by picking uh picking to split and selecting the block as a single step, um cutting this down for large stream fields and much more. So yeah, this will be available on Microsoft 3 and hopefully it will be an improvement to your editors' experience. As always, I'm happy to answer any questions in the chat or otherwise depending on how we're doing the time.

Speaker 2: Thanks, Jacob. I think it's going to be in the chat because we need to keep moving. But I know a lot of people are very happy to see the splitter make it into Wagtail. Next up, we've got Matthew back on module reorganization.

Speaker 4: Okay , uh so Yeah, so one of the uh the biggest but uh less immediately obvious changes in uh 3. 0 is uh the uh reorganization of the code base. And uh as with the panels, this is Addressing a decision that was made way back in the early days of Wagtail's development. Because when we were defining the modules that make up Wagtail, it seemed logical to distinguish between the core code, the page models, field definitions, the things that you would typically work with when you're building up your site data model. Versus the admin-related code. But as time has gone on, we found more and more exceptions, things that straddle that boundary.

Speaker 4: And that would be things like streamfield blocks, which are part of the data model, but they also implement the editing interface. And also the more peripheral parts of Wagtail like images and documents. Those are apps that handle both the data model and the admin interface for that object. And we see that as a standard pattern for building white tail extensions. something like Wagtail Media would spring to mind as something that follows that pattern. And that those sorts of uh add-on developments are things we're keen to see a lot more of. And that has meant that the central part of Wagtail, managing the actual pages, has turned into a bit of an outlier for people

Speaker 4: digging into the Wagtail code base. And uh that's something that we're keen to improve on. Um obviously we're very keen to see more and more people um getting on board, developing on the Wagtail itself. especially uh with uh initiatives like Google Summer of Code. And um with so with that in mind, um Carl, um one of our uh lead our core developers uh has written up this um rfc document proposing how we can reorganize the uh core modules to clarify things and uh not all of the uh um the proposals outlined here have made it into uh 3. 0

Speaker 4: but um the the uh but the version bump has given us the opportunity to deal with some some of these longstanding issues and the uh Significant one to note uh in the case of the three point oh release is that the uh Wagtail. core module is now um just uh just Wagtail. So what this means for your project code is that where you previously had imports like from wagtail. core. models that will just become from wagtail. models. So again, just uh a bit less typing and yeah, a bit less uh less to think about there And um now that you might think that that might be sort of a fair bit of uh of of typing

Speaker 4: of changes to go through a code base, but um We've provided this command, Wagtail Update Module Paths, which you can run at the root of your project code base. and that will take care of uh updating all of these imports uh automatically. And yeah, the feedback we've had from uh from uh people trying out the uh release candidates is that this process has gone very smoothly. It's uh taken care of everything. So it's uh it it's it's been a very yeah very smooth process. So yeah, hopefully that that will sort of make things better both for the developers working on Wagtail itself and

Speaker 4: simplify things a bit for the developers of sites too.

Speaker 2: Thanks, Matthew. Certainly uh in my experience, so yeah, I was a bit nervous about updating the three little personal sites that I run on Wagel outside all the Torchbox ones, but I found that using that command made it very easy for me. So uh Thank you for doing all that work and making it easy. Okay, uh last up in our section on what's new in Wagtail 3, I'm very happy to introduce Tidiane.

Speaker 6: Hello.

Speaker 2: So

Speaker 6: I'm Tijian, developer at Touchbox. I will just share my screen. So, yes, I'm going to do a quick demo of the image deductor feature we have added in Wagtail 3 And the future has been sponsored by Motley Fool. But first I may uh why do we want that future? So yeah, we imagine that maybe if you can have like multiple images. Oh Yes, you can have multiple images. And then it will be hard to keep track of which images have been added or which haven't been added yet. And that's why so sometimes when you want to upload a new image, you don't know if it's already there, or sometimes, for example, the image is not has not very good text, so it may be bad labeled and searching won't help to find it.

Speaker 6: And all this reason may lead someone to upload an image that is uh already a duplicate. So yes, the goal is whenever that happens, we want to show a confirmation step to the user so that they confirm that they uh do want to upload the the duplicate. And yes, why we don't want why would we want to avoid uh having multiple duplicates is maybe we will use more disk space and potentially we'll use more money and yeah. And overall we think that yeah not having duplicate might you know enhance the editor experience. So yeah, so the way it works, for example, here if I add uh this is the original image, I can say if I can say so. So here we can see that the uploads was successful. the title then tags and all

Speaker 6: so yes I will keep it and now what I'm going to do is that I will upload this is uh yeah an exact duplicate of the image I've just uploaded So, what will happen is that yeah, I will have a message like this, like your approach was successful. However, it seems to be a duplicate of an existing one. And here is our duplicate, and here is the existing one. So you will have prompted to either keep the new image if you think that yeah for whatever reason you want to keep the duplicate or you can also delete the new image. So if I keep if I wanted to keep the new image, I will yeah go in this step where I can edit the title at new tags and set the collection and go so this this feature is also available in like uh in rich text uh not not even rich text in pages in general like in the image

Speaker 6: uh chooser model So for example, here we could if we wanted to maybe change this image. And then yeah, we'll need to uh yeah, we upload the yeah, another one, duplicate two, for example And then here too, we will have a message saying as that this is a duplicate and we might want to change it. Oh yeah, just skip the new one. So yeah, here we can use the new image. which is this one, duplicate two, or use existing image, which is the first I've uploaded. So yeah, in this case I can I if I want to use use the existing one and delete the new one. So this feature also work in rich text when you add an image in rich text, for example. So yes, I think uh that's uh yeah yeah that's it.

Speaker 6: If you have any questions, I will be happy to answer them. And thanks again to the Motley Fool for sponsoring. this thanks

Speaker 2: tidiane uh there is i've just got time i think just to ask one question that's come through from jesse uh jessie asks if i upload the same image but in a different resolution will it still be detected as as a duplicate

Speaker 6: Oh yes. So yes, currently we are only detecting exact uh duplicates. So if the image has been yes resized or blurred or any any tiny change, one yeah, we won't detect this as a duplicate. And the reason why is that currently how we detect duplicate is that we take the yeah, we hash the content of the image and we save it like in the file hash attribute. And then what we do is that we'll compare two images if they have the same file hash, then they are duplicates. But the thing is currently we are using cryptographic hash functions, which means that if two images have just a little difference, the hash value will be very different. So yes, the idea that yeah, we have we are working on a package to that, yeah, we are working on it and we hope to release it soon, which will use perceptual hashing to find near duplicates.

Speaker 6: So the The idea of perceptual hashing is that when two images are, you know, they have small differences, the hash value will have small differences too. And then it will be easier to find if this is an exact duplicate or new duplicate. So t the short answer is no, but we are working on a third-party package to add that future.

Speaker 2: Fantastic. Thanks again, Tidian.

Speaker 6: Thank you.

Speaker 2: All right. So uh that wraps up our section on what's uh what's available in WagTool 3. 0, which has just just come out and hopefully you will start playing with, or maybe you're you're playing with already. And just for the remainder of this webinar, we want to talk a little bit about what's coming. And to start with, I'm very pleased to introduce to you Sage. Sage is, uh I think this is the first time that Sage has uh presented in What's New and Wagtail. Sage, for those of you who are in the in the Django community, his name may be familiar. Sage was a Google Summer of Code student in 2019 where he contributed a really significant feature to to the Django ecosystem to JSON fields supported across all supported databases. And we're really happy that um Sage is now working full-time on Wagtail and he's going to talk to us about snippets.

Speaker 7: So, as a CMS, Wiketel gives you so many useful features in the page editing experience. Features like revisions that let you see the complete history of a page And you can go back to a previous revision and also compare the differences between revisions. You also have drafts. So if your page is not ready to be published, you can still create and edit the page as a draft. You can also preview any changes that you've made to the page without having to, you know, actually save the page. There are also workflows that let you moderate pages before they go live. These are all very useful features and they are essential to a CMS.

Speaker 7: But CMS at our content management system It's not just about pages. A page may consist of small bits of information or content that could be managed individually. So, Wagtel also allows you to manage smaller pieces of content, or also known as snippets With snippets, you can create, edit, and delete objects of any Django model through the WhiteL admin interface. And if you have pages or other models that reference the snippet, you can choose to snippet when editing that page or model. These are the features available for snippets. But why stop there? WirTel has many useful features in the admin

Speaker 7: as part of the page editor, but these features they do not necessarily have to be tied to pages. And so we are supercharging snippets. We want to bring features from the page editor into snippets, features like revisions, drafts, previews, and workflows We have broken down the work into stages and I'm going to talk about each one. So the first stage before bringing those new features is that we want to allow you to customize the views for your snippets Up until now, all snippets must use the exact same create list, edit and delete views that are automatically provided by Wagfell. But what if you want to have some, for example, some custom logic when managing your snippets?

Speaker 7: In this stage, you will be able to have custom views in the Wagto admin for each snippet. Then in stage two we will add revisions to snippets. This means that instead of just showing you like the actions performed on the snippet, the history view can now show you the actual revision of the snippet at that point in time So you can revert back to a previous revision and also compare the differences between revisions. Next, we will add draft state to snippets. This allows you to save a draft of snippet and publish it. So if you want to create a snippet but maybe it's not quite ready yet, you can save it as a draft.

Speaker 7: This prevents other editors from using the snippet. in their page or other model until the snippet is actually ready to be published. This also means that you can have scheduled publishing for snippets. But at this point we don't add any sort of moderation yet. And then we will add previews to snippets. Up until now, you always have to include snippets in a page in order to see how they are rendered. In this stage, we will allow you to define a template that WhiteTel can use to preview a snippet on its own. And finally, we will introduce workflows, the snippets. This will allow you to moderate snippets,

Speaker 7: the snippet drafts before they are published, just like workflows for pages. And yeah, that's it for the slides. But before I go, let me show you a sneak peek of what supercharged snippets look like. Let me just go to this tab where I have the bake demo ready. I'm currently viewing the breadth ingredient snippet and I'm going to create a new snippet object. For example, I'm going to name this solve and I'm just going to make a few edits And if I look at the history for this snippet

Speaker 7: , We now have these new buttons that let you review the previous revisions. For example, if I want to review the very first revision of this snippet, I can click on this button, review this version. And it will show you that I'm viewing a previous revision and I can replace the current revision with this previous revision. And it says that it has been replaced with a previous version. And if I look at the history, it says that I referred it to a previous revision. And I can also compare between revisions. For example, I want to compare this revision with the current version, for example.

Speaker 7: And it says that It can show you each change that has been made to the model. So in this example, it changes the name from Himalayan salt to just salt. And you can also compare with a pre uh a revision with a prevision one previous one. Like this one, for example. And yeah, this is just the beginning of more things to come. So stay tuned.

Speaker 2: Thank you very much, Sage. There's lots of excitement and questions about this, which I think we're going to have to answer as we continue. Interesting question from Simon Cam. Who says, what will this mean for the future of model admin? Which is quite a key question and one that we we felt we didn't have quite time to cover this time, but maybe we can just discuss a little bit in the chat now. I just wanted to say before I move on that some of you may remember we us presenting Wagtail's Vision either I think maybe the last WOPS new right table, the one before that, and where we outlined five uh key areas that we want to focus on. And the work that Sage has been working been doing along with it with our other contributors, and which is shown here is

Speaker 2: addresses two of the the the key sections in that vision, which are the Wagtail is a platform. So uh can thinking about how Wagtail can can uh be used to underpin kind of broader sections of your content ecosystem And also multi-channel experiences. I won't go more into it now, but I'm really happy that we are uh that this work is delivering on some of those plans. Finally , I'm going to hand over to Kuhn, who's going to talk to us about Google Summer of Code and Wagtail Space.

Speaker 8: Yes, hello. I hope I'm audible. My name is Koen and I work at Fordigits and in the Netherlands. And I'm a Reactile core team member. I'm also a Google Summer of Code Mentor and I'm uh organizer of Reactil Space. I'll start with an invitation to WactoSpace and then uh continue on the topic Google Summer of Code. So Wacto Space is a conference. uh from 15th till 17th of june and people from all over the world come to uh the Netherlands to work on wagtail uh and on the 17th uh we will have talks and they will be live broadcasted So you're invited to the event to watch the live video or attend

Speaker 8: in person, projektel. space slash 2022. Is uh the URL. Um and with that out of the way, let's move to uh Google Summer of Code. Google Summer of Code is a global program focused on bringing more people into open source software development People can work with an open source organization on a 10-week project and participants get the stipend from Google and they receive guidance from an open source project mentor. uh like myself. Google Summer of Code is a big event and uh to prove that uh you are last year's numbers There are 1,300 participants, 1800 mentors, 200 organizations, and

Speaker 8: almost all projects were a success. So last year Wecto participated too, and we had great results. We had a new uh search backend created by Alban. And a lot of us use it on a day-to-day basis. Wec the live is created by Tidian. He's on the call with us today. And Belk Actions. By Sewan. And um, well, this is also a feature that uh we wanted really long in Wagtail and uh is very valuable. So uh last uh so these uh contributors uh uh contributions are great and uh these contributors still work with Reactil.

Speaker 8: This year we decided also to enter the Google Summer of Code program and we selected four project IDs. The first one is the toolkit for stream field migrations. Whenever a stream field definition changes, like a block is added or modified, you also want to update the content. And this toolkit will help developers with that to uh help with that transition. Another project is Windows High Contrast. You can boot your Windows machine into high contrast mode and Wagtail will follow along and also will display the Wektil admin interface in high contrast. The editor's guide is a separate website. This is an ID because the current editors

Speaker 8: guide for the Wacto Admin interface is in the technical documentation. So editors and managers need to go to the technical documentation and that's less than ideal. So we are creating a separate website to target them And the last one is apply the new page uh editor styling to Wagtail. We saw the page editor uh changes um and in And these changes are not in the whole of Wagtail, and with this project we are aiming to do that. So we said received 18 proposals and all uh project uh every project idea is uh covered with a couple of good proposals and uh i'd like to thank everybody who submitted the proposal because it's a lot of work

Speaker 8: And yeah, obviously we have only four projects and we can't accept all 20. So uh thank you to all of everybody uh who submitted a proposal uh for your work and time. And yeah, we really enjoyed working with you to get them. So next up the dates, May 20th, that's uh the day after tomorrow Google will announce uh the slots. Um and at June 13th we will uh kick off the projects and start coding. So uh Google Summer of Code is an exciting time for the contributors and mentors. Google Summer of Code will strengthen the Wagtail community and it will bring more talent to developing Wagtail.

Speaker 8: Two of the last years participants are still working almost full time on Reactel now. And it's very satisfying to help a participant realize a really big project. And sum of code, Google Sum of Code also brings a lot of value to Wagtail, uh the project, but also to all the Wagtail end users. So it's gonna be a great summer.