Wagtail CMS: Past, present and future by Phil Dexter

Speaker 1: Hello everybody. That's right. Hopefully you can all uh as the famous saying goes now see my screen. I am Phil Dexter and as Carvin said I work for Torchbox. I'm a bit of an imposter here in that I don't write Python all day, every day. a bit more of a generalist. I've got a background in delivery management and product management. Um I also have a bit of design in UE And I do have a degree in computer science. So I'm sort of good at nothing and a bit okay at everything. But today we're going to be talking about Wagtel CMS and the kind of state of where we are at the moment. And where we're going to be going. This should be quite a good talk, hopefully for people who don't know Wagtail as a bit of an intro, a bit of an overview. And also for people who do know Wagtail

Speaker 1: , you'll probably learn something new as we cover off some more of the product development bits a bit later on as well. But for now, let's kick off and ask the main question. What is Wagtail? Hmm, good question. So I've written this on the slide and we can have a bit of a discussion, or I can discuss myself, I suppose, whether this is right or not. I've written the most popular CMS built on Django. So let's unpack that a little bit. CMS content management system. So hopefully. That's creative people that surround you know websites used to need to know HTML and CSS and all these things to update some basic copy. And sometimes somewhere in the world you still do, but for most places CMSs exist, which is really great and you're able to uh update it as a non-technical person. Um so for content managed sites, Wagtail is really, really popular as a

Speaker 1: content managed system. And it's built on Django , which obviously is a web framework. It's a very popular web framework for Python. And I'll go into that a little bit more shortly. Um, but I put this slide up the other day in front of my colleague and said, Do you think that's about right? And they said, Well, what do you mean the most popular? And I sort of thought, well, I don't know. I just sort of think it probably probably is. But how do you measure that? There's lots of ways of measuring this kind of thing Um I guess GitHub stars, we've got like 11 ish K, 10K, something like that. Um But then I thought, well actually there's quite a lot of kind of large and interesting sites that use Wagtail. So rather than kind of debate semantics, I'm going to go on to who uses Wagtail. So Google uses Wagtail for blog. google and creators. google. So big organizations use Wagtail for their marketing sites.

Speaker 1: Twilio also use it for twido. com. NASA JPL use Wagtail. So they use it in a headless fashion and they want it to kind of launch on Wagtail and adopting it kind of across JPL and the wider NASA using it to an extent as well. So it's used uh adversely as well by some big names. The NHS in the UK, so my nationalhealth service. uk, our kind of main website there is built on Wagtail and has been for sort of four or five years. So high traffic sites use it. Caltech use it and they have uh hundreds of sites within a single Wagtail instance making use of kind of multi-site for Wagtail. The Motley 4 use it, they've got tens of thousands of pages in there. As I mentioned, Twilio use it, but they also use it for the famous Twilio

Speaker 1: developer documentation. So they've got lots of people updating all the time kind of informational pages there, almost like an intranet or a wiki. And Mozilla. org use it. So the Mozilla organization, they have kind of a hundred different locales, so different localized language versions of their site, all powered by uh by Wagtail. So quite a lot of cool, you know, people use Wagtail, which I really like. But we started, and I'll go back to the past of it, from very humble beginnings. At this point, I was going to ask, and I didn't really think this through, but I was going to ask, does anyone know when this picture was from? So maybe I'll just ask Calvin or Calvin's Otter. ai. uh whether you guys uh know when this picture was from, which year it was from.

Speaker 2: I don't know if I can tell you which year. That's a while ago.

Speaker 1: It is a while ago. So this is like yeah, exactly. The Oscars. It's a very famous selfie that at the time people talked about a bit. Anyway, this was 2014. um it doesn't feel like that long ago but um apparently it was um and this uh is a group of people who uh worked for torchbox back then and who kind of invented wagtail So Torchbox, for those who don't know, which we kind of a number of you, I suppose, we're an agency in the UK, and that's where I work. And we invented Wagtail and then open source Wagtail very quickly from 2014. So uh Wagtail's an open source CMS that started life in 2014. And since 2014

Speaker 1: Apologies. Since 2014, we've been steadily growing and kind of having steady product development on Wagtail. So that top graph on the right that you can see there is our GitHub commits. And uh they're kind of pretty steady as you can as you can see, kind of no uh periods of downtime. Um and on the right, and the the lower one there is our Slack active uh users per week. So again, you can see that's kind of steadily growing Obviously Slack didn't start back then but but we were um you know relatively early on the adoption cycle there and it continues to grow. And Wagatel is looked after by Court. as lots of kind of open source uh projects are wagtail is very similar and there's these people plus 15 more who are on the Wagtail core team looking after it day to day week to week month to month

Speaker 1: So, um, you know, now we know a bit about Wagtail. Why would you use Wagtail? What's the point of it? There's a kind of a few different um points here, and I was trying to break this down. One of the big ones is we're just standing on the shoulders of giants, really. Wagtail is built on Django, Django's built on Python, right? And we get all of this goodness that everyone at Python Web Conference hopefully already understands. But to break it down, just a simpleton like me, Python makes it faster to build better software applications. It's a nice programming language. It's easy to learn, easy to use, and easy to kind of build things that you want to build with it And then Django uses Python and makes it faster to build better web applications, right? If you want to build a web application just with Python, you can. You can go and do that and that's fine. But using Django or something like it as a web framework

Speaker 1: It's going to speed everything up for you in terms of doing those things and again standing on the shoulders of giants there And then Wagtail is very specific in terms of, you know, Django is about web applications in broadly, and Wagtail takes Django and adds to it and says, okay, how can we make it faster to build better content-managed websites? So we really are kind of inheriting all the goodness that these other open source projects are taking and then kind of making it more specific for content managed sites. And continuing this theme, let's go more specific now again. Python gives us all these things. It's very easy to learn and use. It's got a very mature community. It's versatile for different things. It's efficient and reliable. I don't know why I've got sufficient and speed here, but it's flexible.

Speaker 1: There's predictable releases and there are good guiding principles as the Zen of Python, which some of you may be familiar with. And it uh you know for Wagtail, we we benefit from these things. We also have adopted some of these things. We like the predictability of the releases of Python. And uh Wagtail has predictable releases so that every quarter, every three months, there's a new version of Wagtail that comes out. And that's been consistent for a few years now. And the guiding principles, we also have guiding principles of of Wagtail to kind of give us our philosophy of what we think and how we work on this stuff. Django uh obviously gets all the benefits of Python and then adds its own. So it makes it very scalable for the web and secure for the web, right? There's lots of kind of um things that we don't need to think about because we're using Django and it kind of deals with that security.

Speaker 1: There's lots of libraries that you can use. There's the Django way of doing things which is uh you know we really like it kind of says this is this is the way you should be using Django this is how you should kind of develop with it and there's a similar sort of situation for Wagtail if you read the docs there's kind of well supported methods and ways of using it And I like the final quote there, which I can't even remember where I got, but it was a website somewhere that was reviewing Django and it just sort of said, developers have done all the boring parts of web development themselves, so you get the fun part. And I like that. It's Yeah, similar sort of situation with Wagtail, we hope that you know it's it's very easy just go and start customizing things and making things your own. So with Wagtail, we get the benefits of Python. It's easier to learn and use. It's a mature community. These kind of things in terms of Python.

Speaker 1: And the same thing for Django, and we add our own. So we've got really powerful features and really good UX for editors. So we've got things like Publishing statuses for pages, page trees, custom workflows, commenting in the in the admin, similar to kind of Google Docs. So really it's becoming a place where You know, lots of people will write their content and their web pages in in a Google Doc or Dropbox paper or something and then paste it straight into your CMS to try and format it. And actually Wagtail is becoming a place where we're seeing more and more people writing their content directly into the editor. There's lots of installable packages, the same way that there's lots of Django packages, there's installable packages for Wagtail. So things like Wagtail localize. uh for localization of your Wagtail site or uh

Speaker 1: Wagtail Grapple to turn your you know get GraphQL APIs out of your Wagtail site. And then it's massively extensible. At the end of the day, it's kind of just more Django, more Python code on top of it. And you can go and change it and alter it as you want. And there are fairly well documented and well supported methods and ways of customising Wagtail so that as we upgrade Wagtail, you know, you should um be able to follow a relatively simple upgrade path rather than you know, doing your own thing entirely and um ending up with with bad upgrades um on your own fork. And then the finally there's quite an interesting point here where we're going to geek out a bit on CMS's Um where we're going to talk about it being opinionated. So Wagtail generally is fairly unopinionated in terms of telling you how a website should be set up other than things like a page tree.

Speaker 1: But it is quite opinionated on how content management should work and where the power should lie between let's say there's kind of three-ish roles for now. There's a kind of content editor. There is a designer who's designing the front end and there's a developer who's working out kind of what the back end the database should look like. And We have this kind of uh part of our um design of Wagtail actually is the separation of content and design. And this is very much borne out in the way that Wagtail has been designed, the way you build a Wagtail site. It's trying to keep those two things apart. We want the power. We want to, we want to, you know, the editor is hugely important because they're the people who are actually writing the content and deciding what goes on day to day. But they need to do that within the realms of what your designers and developers have created. We don't want them to be able to kind of go outside those

Speaker 1: bounds. So For a designer, we want them to be able to control the visual design. They come up with a design system. They want it to be consistent across the piece. We don't want the editors to be able to go and break that design system. We just want them to give them the flexibility to be able to kind of express themselves what they need to show, but within the design system. And then developers control the content model. you know, the database model, kind of the the ER diagram, whatever it is you want to call this thing, right? Your developers are in charge of that. And what we don't want again is certain CMSs where you'll be able to, as a kind of admin user, go and click around and create your own content types. And that kind of thing, I'm sure lots of people who who have worked with CMSs before will will know. doesn't end very well, you'll end up with people who are making, from a siloed perspective, just trying to solve their own problem at this point in time, which makes sense to them, but actually if you take a step back.

Speaker 1: Creating your new content type or changing this existing content type isn't a sensible move because of all these other things. So we want the power for the content model to be with developers and the visual design and the design system to be with the designers, the visual designers So then the editors can basically write the content within these limitations. And I'll show you kind of what we mean by that. If we were to take the Python WebConf website, right, and think, okay, if this was built in in Wagatail, what you know, what would this kind of separation of content design mean? Well, let's look at this title here, the most in-depth Python conference for web developers. I mean, this is something that we would probably want to be content managed, right? We wouldn't want this hard-coded. We would want this to be something that people could change and if they created multiple of these different pages. But we wouldn't want it to be that they could change it and

Speaker 1: change the design particularly. It wouldn't want the way to change a font or to potentially make it bold or make it flash and pink or any of this stuff. We would just want it to be plain text. Write in what you want, there's a character limit. And that's for designers and developers to decide, and then editors decide what the words are. And then the same sort of situation for uh yeah, the subtitle there Probably here, this is actually a rich text box because there's a link on the right hand side where it says March 21st to 25th, 2022. That looks like a link to me. So we probably are allowing links, but we're not again allowing anything like bold text or italics any colour choices, any kind of alignment. We don't want that to be something that editors can do because if we let them do it, someone eventually will and it'll look horrible. And that's a problem.

Speaker 1: And then a similar sort of situation down here, right? This would be rich text where we're allowing, you know, H2 sort of headers, links, but not much else. Or maybe we do allow other things and we're okay with them kind of having such you know certain bits of um uh customization within there. But it's it's more about sort of controlling what the editors can do. And so that that feels like, okay, Phil, well that sounds quite boring and structured. Like if I'm an editor, I don't have much flexible much flexibility here. My page is going to look the same And again, that's yeah, that's not true because of uh a certain feature within Wagtail, which uh was developed back in like 2015, and you'll you'll find this feature in lots of CMSs now. Which is uh we call it Streamfield.

Speaker 1: It's basically a dynamic content area. Uh WordPress introduced Gutenberg recently, which is really uh a similar sort of situation. But to kind of talk a bit more about what Streamfield is We've got here, for instance, let's imagine this is our web page. This doesn't look anything like Wagtail. This is just a Google slides, so forgive me, but imagine this is our web page. We've got title and an introduction on our web page. And those things are, you know, not dynamic. You can have one of them, you have to have it, that's the situation, and it's going to be kind of styled in this manner. So you you would fill those things in, and that's what we call structured data. structured part of the page and let's imagine this is a blog a blog page right so i've got my blog title the introduction paragraph but then i decide well what do i want on my blog right i want some pictures i want some text

Speaker 1: i want some tables i want some other stuff But what order do I want them in? I don't know. How many of them do I want? I don't know. Well, as I go, I can kind of add these dynamic content blocks in. So I can add a rich text block in, let's say. and write my rich text in. And then I can add belief that, let's stick an image in there, right? Hooray, here's my image. I can stick that in. And then I can add in some more rich text. And you can see you can build up these uh content blocks basically and shift them around and have as many of them as you want, you know, put them up and down. And which content blocks are available is entirely up to the designers and the developers in terms of. Well, what have we got in the visual designs? What can we allow these people to have? Is there a quote there? Is there some other kind of um block here? Is there a left-right kind of carousel thing? It doesn't matter. You can basically customize it as you want, but it's a decision made by the designers and developers.

Speaker 1: And then the content editors are the ones who will work within those. So hopefully that makes some sense as it's um can be a tricky thing to describe. So now we're going to go into a bit of a product development geek out. That's once you've been from the CMS geek out. So hopefully you're joining me on this. So let's look, let's just put a bit of a review of Wagtail and as an open source product, you know, kind of how we've developed and how we're developing now. So From 2014 to 2018, if we imagine that that little box with the Wagtail logo in is Wagtail, and then the people around it are sort of the core team, contributors and volunteers with contributing code to Wagtail So that's kind of how the first four years went.

Speaker 1: Torchbox did a lot of the work, but actually there were lots of other organizations who joined the core team who did their own things. And there were people who uh you know the core team um were doing lots of work on Wagtail themselves. But it was all kind of alongside other work that they were doing rather than generally a full-time thing. And then in 2019, things changed a bit. We started to receive sponsorship requests from uh large organizations that are using Wagtail for features. So things like custom workflows, commenting and the admin were paid for by specific individual kind of clients of Torchbox and we were able to kind of build those things whilst being paid and adding cool things to Wagtail. So for us, we were like, well, this is fantastic. You know, we probably wouldn't have been able to get this stuff done without this.

Speaker 1: And for those organizations, it paid off as well because they were getting Wagtail for free compared to the license fees of some other uh large CMSs And for them, they would otherwise have to go and spend this money just building and customizing these things themselves. They need these features. And for them, they felt, well, let's just go and give these people the money. And they can go and do it and they can make it part of Wagtail core code as well, which means that forever we'll get free maintenance. So quite smart from kind of both sides of it. And thankfully everyone else now who uses Wagtail obviously benefits from that and gets all of the kind of really fruit cool free features. So this was working really well for us and we were sort of you know incredibly happy about this. One of the things though that we realized was these kind of feature requests were coming in for specific features, and there were certain things in Wagtail we felt we wanted to change.

Speaker 1: More wholesale. And this wasn't necessarily going to happen with someone coming in and saying, right, now redesign this. For instance, the page editor for Wagtail is something that we have been thinking about for a few years and feels a little bit dated. So last year we changed some things. And as well as having some feature sponsorship coming in and the core team kind of working on Wagtail, we then as kind of the Wagtail core team. Did some design and discovery work on the page editor, the main kind of place you write your content for your pages in Wagtail, and then took that out to potential kind of sponsors, big organizations that we know that use Wagtail. And said, look, would any of you be willing to fund some of this work, like part fund and part sponsor? And thankfully, uh

Speaker 1: Google kind of at the end of last year We seem to ask them at the right time and they said yes. And so gave us, you know, 150K, which is really lovely. And there's more um kind of users who are also giving us some more money towards that. So we're doing kind of a wholesale upgrade of the page editor right now. Which is amazing and felt like a bit of a pipe dream at one point. But yeah, it's really cool to be able to do that. And this is kind of the design of the new, the new page editor. Which does look better when it's less pixelated and hasn't been kind of stretched quite as I've stretched it here. But um yeah, there's some really great features in here, some really cool kind of autosave and live preview and Lots of really great stuff we're really proud of. So we're looking forward to rolling that out in the next couple of releases of Wagtail.

Speaker 1: So we've talked a bit about product development and how product development has evolved at uh full wagtail. One of the reasons why we kind of know where we're trying to get to is we have a product vision. And this is kind of an interesting thing. I don't know tons and tons of open source projects that have product visions, but most kind of Uh I guess closed source or SaaS products out there will will have some kind of product vision. It's the kind of thing that product geeks like to geek out about And the reason that Alison Wonderland is on here is to try and explain what a product vision is. And again, it's sort of a lame thing that product nerds like to talk about. There's this there's this scene in Alice in Wonderland where Alice is talking to the Cheshire cat, right? And she says, Oh, excuse me, do you know which way I should go? And the Cheshire cat

Speaker 1: says, Well, that depends on where you're trying to get to. And Alice says, Well, I don't really mind where I'm trying to get to. And the Cheshire Cat says, well, it doesn't matter which way you go. And that's very much akin to, I think, um software development or projects or many things, you know, in in the digital world or the world I guess, where if you don't really have an idea of where you want to get to, at that point in time, you can make a decision which feels right. But really you don't kind of have any idea of where you're going to end up there. Um, and if you have a vision, you have a goal, you have kind of an end destination of where you're trying to get to. That's makes sense and it's tangible, then people all over the place who are kind of working on this thing in disparate situations can make decisions all the time that are taking you towards that goal. So we see the product vision as being really important for White Tail And we try and tie our work back to it when we're making decisions on what not to work on, what not to prioritize

Speaker 1: is kind of let's look at the vision and work out what's the most important thing for us here. So, not just to talk about visions hypothetically, I'm going to talk a little bit about Wagtail 's vision. So, product visions can take on all sorts of different formats. A lot of them are kind of videos or documents or whatever. Ours is a like comic book style product vision, which was inspired by kind of Airbnb's original product vision. So I'm going to flick onto that first of all. There are five different pillars to the vision. So there are different areas of Wagtail that we wanted to highlight and say this is what it will be like. And we wrote this in 2020 and it's as Wagtail should be in 2023 basically. When I flick on to the next slide, there'll be some words you probably can't read in the in the comic strip.

Speaker 1: Don't worry about reading them. My words that I say will will be enough, I expect. So the first is is the first 30 minutes of Wagtail. So here we're thinking about that initial experience for people, kind of who is finding Wagtail, how many people are finding out about what Wagtail is. And how many of them are we getting through this kind of first 30 minutes of Wagtail? We see this as a really core and crucial part of the journey for developers, especially. You know, Wagtail, once we get people to use it for 30 minutes who are developers who have kind of got to the point where they want to try it, a lot of them will go, wow, this is magic. I can do so much so quickly and it's so easy and fun to do. that they want to use it a bit more. So really, really like um like this one and um you know something that we not we don't do as well as lots of other content management systems or other products

Speaker 1: is is shout about Wagtail and kind of drive traffic to the Wagtail site and have that easy onboarding experience. It's not bad. We've got really good documentation, but you have to kind of find it. So we want to we want to make that better and better to have really good demo experiences and set up process. So that's the first kind of of our five pillars. Yeah, our second one is about our editors, right? We we editors are really Key and core, even though I was saying before about giving them no power, actually they have all the power day to day within the realms of what's been defined for them And we want the editor experience to be great. I think it's often forgotten in CMSs and in kind of, well, yeah, many bits of um of software, but certainly the CMSs it can be forgotten. And especially in kind of open source CMSs.

Speaker 1: So we want them to feel at home. We want them to understand what they're working on really easily and have Wagtail help them to optimize their content. and report on performance rather than it be kind of a secondary thing. So that's where we like to get to. This is more of a design principle, this third one. So sophistication without compromising simplicity. So this is us kind of saying, look, Wagtail works really, really well. You know, we've talked about lots of big organizations and big sites with tens of thousands of pages and hundreds of content authors. But actually it works and always has worked really, really well for one-person blog sites, right? Just kind of setting something up for free, you know, hosting it wherever and just managing it as a really easy and straightforward thing to do.

Speaker 1: What we don't want is for these large organizations and the requirements that they need and the power, the complexity of these features to kind of ruin it for everyone who wants it just day-to-day for their small thing. We want to be introducing these things, but only reveal them as they're needed. And you're revealing them as you need those powers. So not kind of making it overly obnoxious and in your face, really. Yeah, this is a really interesting one and it's about kind of us how we develop Wagtail, right, as the core team. We're obsessed with making Wagtail easy to build, maintain, and customize, and speed of development is crucial for our community. So we know that if Wagtail is really easy to build with and to customize and to do your own thing with. then it will be a success, right? And people who use it will like it and recommend it to other people.

Speaker 1: And if we take that even a further a step further back, if it's easy for the core team to build Wagtail things and to improve Wagtail, then it's going to be easy for people to then customize it themselves, right? If we've got lots of standard patterns and ways of doing things and the code makes sense, then it's going to make sense to other people. So this is about us kind of getting it to a point where for developers it's super easy. There's really well documented um standards and ways of doing things. And there are, we're on a journey on this, yeah, we can always get better. Um, and we're making some significant strides in this right now as well. But yeah, it's it's something that we we're really passionate about And then finally, we call this multi-channel experiences, and really I think it probably should have been called headless. But this is about that headless developer experience, making it really simple for people to be able to manage their content in the CMS.

Speaker 1: uh which may be going to multiple different kind of um heads, multiple different places on the front end, um, having a really easy developer experience to integrate those those front ends and a really um nice editor experience for the authors to be able to manage that content in in kind of one place. So that's um that's what that kind of the final piece there is. There's some stuff we've left out. Which we're not focusing on hugely at the moment, but this is kind of where we'd like to get to. And we think that the vision in this kind of comic book style works relatively well. So what are we doing against that vision? I'm worried my face is going to get in the way of this, depending on if my face is still visible here, but We're doing a few things. So on the first 30 minutes of Wagtail, we are

Speaker 1: reworking Wagtail. org right now. So that discoverability of it you know, the SEO side of things, which is all kind of interesting and and and relatively new to me in terms of how deep you need to to be an expert in to make it work. And the initial developer experience of how do we get it so that someone can very quickly and easily set up their own kind of Wagtail site to be able to use as an editor or to be able to use as a developer to kind of improve and try out you know changing page templates and stuff. We've got some cool stuff with Gitpod there where we can um you can try that out really quickly. But we need to kind of shout about it a bit more really. On the editors, we've been doing a few things. The page editor is a huge one that we right now are in the middle of building. Um so that's probably the biggest, but we're also looking at um

Speaker 1: segmenting, personalizing, and experimentation, so A B testing and those three things all being really Similar in some ways. It's all let's create a variation of this page or of this content and let's show it to these types of people for these reasons and report on performance. And we're we're looking at that and building that out as a platform that you can extend and kind of integrate with your own Services. So that's kind of in the very early stages at the moment. So if anyone's very interested in that, do give me a shout. Wagtail as a platform, we're thinking a lot about the speed of development and making Wagtail simple to customize. So with our changes to the page editor, there's lots of kind of very useful refactoring and reworking that we're doing to some older older bits of um Wagtail's code to make it um simpler to customize in the future and more maintainable.

Speaker 1: We in the next week are launching a headless public roadmap, which is going to be at areweheadlessyet. wagtail. org, which is inspired by Rust. who have these kind of are we uh fast yet and are we um cool yet and all these kinds of kind of um kinds of roadmaps which you really like. Um So yeah, we're having one of those. I would say our our headless journey is not complete. I don't think there's any CMS that does headless developer experience really well um uh a tool, like as well as we'd like to do it, I would say we're we're pretty good. Um and Wagtail as it separates already like content from presentation, we found it very easy to offer headless. through both GraphQL and APIs. But I think there are certain things around page routing and there's certain kind of starter kits and stuff in X. js, which we'd like to get out there and available for people to make it simpler and easier to build their headless Wagtail

Speaker 1: sites. And when we're doing our design, so around our sophistication without compromising simplicity, when we're doing our design, we're designing for big and small sites, you know, large and small pages. um, you know, thinking about lots of editors using a thing at once versus one or two. So yes, that's our design principles. So, quite a tour there of where Wagtail is and where we're going and what we're doing. If you'd like to get more involved in Wagtail and find out some more stuff about it, then these are some cool links. So you can find out more at Wagtail. org. You can try out Wagtail at Wagtail. org slash play. That will launch your your Git pod and you can log in there. You can check out our GitHub You can join the Wagtail

Speaker 1: Slack and you can follow us on Twitter at Wagtail CMS. I'm also going to be obviously be, as all the speakers are, around for the next however many minutes is defined, I think half an hour or 15 minutes or something to chat to you all if you have any questions. And equally you can reach me on uh Twitter at Philly Dex , if you don't want to chat now. But yeah, thank you very much for attending today. Really appreciate your time. And I hope you had a nice day. Cheers.