Visit our site to sign up for the newsletter, explore past episodes, subscribe to the show, and help support our work.
Summary
If you are operating a website that needs to publish and manage content on a regular basis, a CMS (Content Management System) becomes the obvious choice for reducing your workload. There are a plethora of options available, but if you are looking for a solution that leverages the power of Python and exposes its flexibility then you should take a serious look at Wagtail. In this episode Tom Dyson explains how Wagtail came to be created, what sets it apart from other options, and when you should implement it for your projects.
Brief Introduction
- Hello and welcome to Podcast.__init__, the podcast about Python and the people who make it great.
- I would like to thank everyone who has donated to the show. Your contributions help us make the show sustainable. For details on how to support the show you can visit our site at pythonpodcast.com
- Linode is sponsoring us this week. Check them out at linode.com/podcastinit and get a $20 credit to try out their fast and reliable Linux virtual servers for your next project
- We also have a new sponsor this week. Rollbar is a service for tracking and aggregating your application errors so that you can find and fix the bugs in your application before your users notice they exist. Use the link rollbar.com/podcastinit to get 90 days and 300,000 errors for free on their bootstrap plan.
- Visit our site to subscribe to our show, sign up for our newsletter, read the show notes, and get in touch.
- To help other people find the show you can leave a review on iTunes, or Google Play Music, and tell your friends and co-workers
- Join our community! Visit discourse.pythonpodcast.com for your opportunity to find out about upcoming guests, suggest questions, and propose show ideas.
- Your hosts as usual are Tobias Macey and Chris Patti
- Today we are interviewing Tom Dyson about Wagtail, a modern and sophisticated CMS for Django.
Interview with Tom Dyson
- Introductions
- How did you get introduced to Python? – Chris
- Can you start by explaining what a content management system is and why they are useful? – Tobias
- How did the Wagtail project get started and what makes it stand out from other comparable offerings? – Tobias
- What made you choose Django as the basis for the project as opposed to another framework or language such as Pyramid, Flask, or Rails? – Tobias
- What is your target user and are there any situations in which you would encourage someone to use a different CMS? – Tobias
- Can you explain the software design approach that was taken with Wagtail and describe the challenges that have been overcome along the way? – Tobias
- How did you approach the project in a way to make the CMS feel well integrated into the other apps in a given Django project so that it doesn’t feel like an afterthought? – Tobias
- For someone who wants to get started with using Wagtail, what does that experience look like? – Tobias
- What are some of the features that are unique to Wagtail? – Tobias
- Given that Wagtail is such a flexible tool, what are some of the gotchas that people should watch out for as they are working on a new site? – Tobias
- Does Wagtail have any built-in support for multi-tenancy? – Tobias
- Does Wagtail have a plugin system to allow developers to create extensions to the base CMS? – Tobias
- Having built such a sizable plugin with deep integrations to Django, what are some of the shortcomings in the framework that you would like to see improved? – Tobias
Keep In Touch
Picks
- Tobias
- Pumpkin Pie
- Tom
Links
The intro and outro music is from Requiem for a Fish The Freak Fandango Orchestra / CC BY-SA
[00:00:13]
Unknown:
Hello, and welcome to podcast. In it, the podcast about Python and the people who make it great. I'd like to thank everyone who has donated to the show. Your contributions help us make the show sustainable. For details on how to support the show, you can visit our site at pythonpodcast.com. Linode is sponsoring us this week. Check them out at linode.com/podcastinit and get a $20 credit to try out their fast and reliable Linux virtual servers for your next project. We also have a new sponsor this week. Rollbar is a service for tracking and aggregating your application errors so that you can find and fix the bugs in your application before your users notice they exist. Use the link rollbar.com/podcastinit to get 90 days and 300, 000 errors tracked for free on their bootstrap plan. Visit our site to subscribe to our show, sign up for our newsletter, read the show notes, and get in touch. To help other people find the show, you can leave a review on Itunes, Google Play Music, and tell your friends and coworkers about it. You can also join our community. Visitdiscourse.pythonpodcast.com for your opportunity to find out about upcoming guests, suggest questions, and propose show ideas. Your host as usual is Tobias Macy. And today, I'm interviewing Tom Dyson about Wagtail, a modern and sophisticated CMS for Django. So, Tom, could you please introduce yourself?
[00:01:20] Unknown:
Hi. It's, it's good to be part of this. I'm my name is Tom Dyson. I'm the technical director and cofounder of Torchbox, which is a web agency based in based in the UK with a small office in the US.
[00:01:35] Unknown:
How did you get introduced to Python?
[00:01:38] Unknown:
So I started Torchbox in 2000, grown slowly over the years. In in the 1st few years, we used quite a wide range of technologies and programming languages, and, you know, that was that was a period of very fast change in in the web industry. So, we were building sites in ColdFusion, which I doubt many of your listeners are familiar with, also with Pearl and PHP, and then we played with Ruby and Rails, and, we built a couple of big Java back sites. But, somewhere in those first few years, I I learned Python, really, as a sort of more readable alternative to Perl. So it was initially for for scripting and sysadmin type work, systems work. But it, it it it really connected with me. And then, sometime after that, Django appeared, and, that kind of combination of of beautiful language and a very well thought out web framework meant that Django and Python became the the de facto choice for, the technical parts of our organization.
[00:02:40] Unknown:
And for anybody who's not familiar with the concept, can you start by explaining what a content management system is and why they're useful?
[00:02:48] Unknown:
A content management system, which I'll henceforth abbreviate to CMS, is a very standard tool, and, most of the most of the websites that you will interact with online will be backed by a content management system. So this is a a tool which allows editors and administrators to manage the content without writing HTML by hand. And they vary in sophistication from simple single user systems, which generate flat files, to to large so called enterprise packages, which, which have things like custom workflow and, media management for for massive amounts of assets and data.
[00:03:31] Unknown:
And how did the Wagtail project get started, and what makes it stand out from other comparable offerings?
[00:03:37] Unknown:
So we've been building content managed websites for, I guess, nearly 15 years, and we had our own content management system, something called Rational Media, which, we started in about 2003, 2004. And, and it was it ran some big sites, people like, University of Oxford, and and it was well liked by by its users, but, it it was an open source. And, increasingly, we realized that it wasn't sustainable for us to to carry on offering a piece of software that was critical to our clients' business that was only supported by 1 small company in the UK. So, so we looked around for open source alternatives, and, after some considerable research, we picked Drupal, a PHP content management system, and, which has which has really picked up a momentum over the last decade and run some very big, well known sites.
And, and Drupal's Drupal's been good for us as a business. We carry on building Drupal sites, but at the same time, we felt some frustrations with technical aspects of Drupal. And, and I guess, over the last few years, we've been waiting for somebody else to to provide an open source content management system that that behaved in the way we wanted, but it never quite came. And, obviously, there are some great there are some great projects out there. Some there's lots of very impressive software, but but nothing that that worked really in a way that suited us and our clients. So, in late 2013, we started working with the Royal College of Arts, who are a very distinguished arts university in London, in the UK. And, they had also done an analysis of the open source options for content management. And they they had some specific requirements of their own, and which none of which were were met, or at least not all of which were met by any existing products. So they commissioned us to build them a new content management system, and, with the with the agreement that it would be open sourced at the end.
And so it was the project of building that site, rca.ac.uk, that, was the birth of Wagtail. So shortly after the launch of of that site, we we spent a couple of months pulling out the, the bits that were specific to the client, and, starting the open source project, giving it a name, giving it a brand. And then we launched it at a small Django conference that was, hosted in Wales called, the Django weekend, in February 2014. As for what makes it stand out from other comparable offerings, there there are few principles, which I might I might talk about in more detail later. 1 is that this content management system should be optimized for the developer and, and not not for the administrator.
And that's a slightly difficult point to to make sometimes, and it's certainly not an easy point to sell. But, it's something that that's we found really important, and, and I I feel that that decision's been vindicated by by the way that Webex does work for us and and, apparently, for other developers as well. So just just to talk a little bit more about that, Drupal is an example of, some very powerful software that allows editors or administrators of the site to, to, for example, to create new types of content and to group those types of content and to list them without writing any code. So, there's a user interface with, checkboxes and fields, and they behind the scenes, that will create new tables and relationships.
And, the promise of a system like that is that, as the owner of a website, you will need to depend less on the the developer organizations who are providing it and to manage it more yourself. But, so so this is something that's, you know, it's it's a compelling pitch, and it's something that's, that that can be very powerful. But in our experience, those features are used rarely, and they they cause problems for developers because, the technologies that make that flexibility possible get in the way of developers. So, as a template designer, you're always having to think about what other types of, content might be inserted here.
You also get problems with disparities between development and staging and production environments because, because the the configuration of the type of data is is managed in the database itself, not in code. So Wagtail with Wagtail, we made a very clear decision not to not to take that route, and to to handle things like model changes using the tools that developers like best, which is text files in code and Git for version management and migrations in in Django for, for for applying those changes and deployment tools for making sure that your staging and production environments are kept in sync.
[00:08:42] Unknown:
And what made you choose Django as the basis for the project as opposed to another framework or language such as Pyramid, Flask, or Rails?
[00:08:50] Unknown:
I guess, primarily, it was a it was a pragmatic decision based on our familiarity with with Python compared to, PHP or or Ruby. Clearly, there were alternatives like Pyramid and Flask. I had, followed Simon Willison's blog pretty closely in the, early 2000. He, this is sort of in the days before Hacker News. He he had the the best listing of, new technologies, and he wrote in a very interesting way. I didn't realize at the time that he was probably a teenager when he was writing most of that stuff. And, so I was following him and then, and and enjoying Python. And then, when when he cowrote Django and announced it, then that was something I was immediately interested in, and, and I got, so I, you know, I followed it very closely. I think I, I know that I I made the first screen cast for Django, which is a brief brief moment of fame in the Django community.
And, and I think it's, yeah, it's it's a framework that served us very well. It's become a very supportive and friendly community, and it's something we're really proud to be part of.
[00:09:57] Unknown:
So what is your target user, and are there any situations in which you would encourage someone to use a different CMS?
[00:10:04] Unknown:
At the moment, our target users are definitely developers. And, and I I guess that's another way that, that might be helpful to differentiate Wagtail from other systems. And, certainly, that's the way that Wagtail has become known as an open source project over the last 2 and a half years. It's, it's not so much through head of digital organization or management level. It tends to be developers, particularly Python and Django developers who see Wagtail and and like the approach and, and recommend it to use in their organization. Most of the sites we see built on Wagtail, aside from our own, are are fairly large sites.
So the kind of site where you might have 1, 000, tens of maybe even 100 of thousands of of pages, media files, and, maybe tens of editors. And it's certainly not required for that, and there are also lots of beautiful blogs built on Wagtail. But, I think that the sweet spot for Wagtail is is probably, an organization which has skillful developers and designers and, clearly, which understands Django and, which needs some of the more powerful features that that Wagtail provides. As for situations where we encourage someone else someone to use a different CMS, I think, as I said before, there's there there are lots of fantastic alternatives. For myself, if I were making a simple website for friends and, had an evening to do it, then, I'd probably more likely pick WordPress because I know that I can, get it hosted in in 10 minutes on wordpress.com, and pick a theme. And, you know, this is it's a quicker way to make a simple site. Or I might look at, Jekyll or Pelican or 1 of the other static site generators.
Otherwise, I mean, Wagtail's, like I said, it's it's it's used for a pretty wide variety of some some some really very large sites, down to some beautiful blocks. So it's, if you know Django and, you're you're willing to create the the look and feel and to to write the HTML and CSS yourself, then then Wagtail should be a good fit for you.
[00:12:09] Unknown:
So can you explain the software design approach that was taken with Wagtail and describe some of the challenges that have been overcome along the way?
[00:12:17] Unknown:
I guess the the primary principle is the 1 that I've mentioned already that we should we should optimize for developers. And, that's been something that we've we've been clear about internally. I wanna say internally, I mean, that's that's slightly out of date now because although Wagtail was created here at Torchbox, it's now a large open source project with, some fantastic agencies supporting it. Some really notable examples are, Springload in New Zealand, who are running the 1st New Zealand Wagtail meetup tonight and take flight in Tasmania, Australia, Leukine in in the Netherlands. Lots of lots of great agencies and other large organizations around the world. But the certainly, the the initial design approach was around optimizing the developers. And, I guess a challenge that that brings is that, the initial experience of using Wagtail might feel slightly underwhelming compared to, some some of the alternatives because, you set it up, you install it, that all happens pretty quickly now, and you, you create your Wagtail instance, and, you have a very uninspiring plain page with a couple of lines of text. And, in the back end, you have a single home page with with 1 content with 1 field in it. And, you know, and then it's it's left to you to to create a site, to build your your models and, and to your templates on top of that. So I think that's a that's a challenge of taking this kind of the purest approach is that, the, the initial experience can be less less exciting. As for other software design approaches, another another clear principle is that we're not opinionated about the markup that's used in the front end. So you can use whatever CSS JavaScript framework you like. You it may even be that you choose to use Wagtail as a so called headless CMS, and the the client is a JavaScript application or a native mobile application.
And I guess that that also can contribute to this sense that, you it's it's a very blank canvas when you start. But within that framework of giving implementers freedom, we also want to encourage people to make websites in in a way that, is is good for the web, which maybe sounds a bit contradictory because it's maybe sounds like we're being a bit opinionated here. So we're not forcing people to do things, but we're just making sure that Wagtail, I guess, doesn't, doesn't make it easy to to do things badly. So an example of that is, quite a controversial example, in, on on the on the GitHub issue list is, the inability to create links that open in new windows, which is a frequent request, and lots of people have have asked for a setting or a that that would mean that you could open new windows or at least have the option to to toggle that. And I think that's something that you can do yourself by, putting it in your templates, but it's, we don't think that opening links in new windows is, is good for for usability, and, that it can lead to some anti patterns in in interface design. So, I guess, you know, we've we've made decision for for Wagtail at least not to make that easy for for people.
[00:15:14] Unknown:
Yeah. It's easy enough to just control click on a link if you want to open it in a new tab. So having that decision forced upon the user is, sometimes non intuitive and frustrating.
[00:15:24] Unknown:
Right. I agree.
[00:15:25] Unknown:
You mentioned that Wagtail has the ability to be used as a headless CMS so that you can do a single page app style front end and then just use Wagtail as delivering content over an API, which I think is 1 of the distinguishing factors of Wagtail versus a lot of the other CMSs that are available, which are more tightly integrated between back and front end. So I think that is a pretty innovative approach and definitely very forward thinking because that's the way that a lot of modern web applications are going is using the single page front end, single page app style with a heavy JavaScript front end and an API back end. So I think that's 1 way to stay relevant as the current state of the art progresses.
[00:16:07] Unknown:
Right. Thanks for making that point better than I did. That's a it's that is a point important aspect of, of Wagtail, I think. And it's something that became clear to us quite early on in in Wagtail's history, where we were commissioned by, it's a it's a very high profile site in the US that we're we're not allowed to talk about yet. I hope we will be able to do sometime in the next year or so, but it's, certainly a site that that you will have heard of. And they, they commissioned us to to build the first API for Wagtail, precisely for this reason. Because, for the the particular purpose of this site, it it it does it does deliver pages, but, a more important aspect of it is that it's gonna use Wagtail as, or is now using Wagtail as a system for for managing content and and for handling the workflow and moderation around that and, asset management and so on. But, that that that content will be delivered by through APIs to, mobile phones, both on mobile optimized websites, but also native sites, using some pretty tightly segmented rules around location and so on. And so that was, you know, it was great to have that commission and and to to build that into Waitel. And so that was an early indication of of the way that, as you say, I think, it's it's it's an emerging trend in content management systems.
Since then, there's been quite a lot of focus on the API. Tom Christie, who's the, the author of the Django REST framework, which is really the sort of preeminent app for for building REST APIs in Django. He contributed a reworking refactoring of our initial API using Django Rest framework. And, we're currently working on, separate API, which we're is currently labeled the the admin API, and this is gonna enable us to make a cleaner distinction between models and and the and, and the interface in the Wagtail, UI itself.
So we've, we've got lots of ideas around, improving the user interface, and, I think the first step of that is gonna be trying to disentangle the slightly, you know, kind of jQuery spaghetti we have at the moment and make Wagtail itself, cleaner, probably a React based app. And, and that that reminds me of something else I should talk about in terms of, distinguishing features for Wagtail, and that's its its user interface. So, there are, as as you you and your listeners will be aware, there there are plenty of really mature and, interesting content management systems in in Django. Some of the more famous ones are Django CMS, Mezzanine, and Fine CMS.
And I think Django has always been, you know, right from its its history as a tool for building newspaper websites. So it's feels like a good fit for content management systems because the the automatic admin interface makes it very easy and to to create a, you know, pretty attractive and effective tool for managing your models. But, in a way, that that automatic and easy admin space has has been has been an issue. It's been a problem in some ways for Django because it's it's so easy to do that, often people who are implementing tools on top of it will stop there. And then they won't think any harder about the way that the editors or authors or their users want to interact with the content. And that's something that we took pretty seriously with Wagtail. And I guess it's, because originating at Torchbox where we're not just programmers, but also designers and UX people and testers and so on, that, that meant that we could apply all of that experience and to to building a new product. And I think that was 1 of the reasons why why I made a bit of a a little splash when we launched it. It's because, it it looks pretty, and it it feels good, and it it feels it feels different to, to a lot of other Django based open source projects.
And that focus on user experience is something that we've we've maintained in the last couple of years. And, and it's it's an area that we're we're making a particular push on in the 4th in the next 6 months.
[00:20:16] Unknown:
And also since you're comparing Wagtail to some of the other Django CMSs available, I'd also like to call out the fact that you are 1 of only 2 or 3, I believe, of the, I think, dozen or so that are available that actually supports Python 3 natively.
[00:20:30] Unknown:
Right. Yeah. That's, we we, just, you know, within Talksbox more generally, we are very keen to to support Python 3, you know, and and wherever possible, we start new projects on Python 3. That is almost always possible these days, and, and so that you know, it felt like making sure that we had, you know, that we we that Wagtail was supporting Python 3 from the from the beginning was a, you know, a small but important to us contribution to to the progress of Python 3.
[00:20:59] Unknown:
So how did you approach the project in a way to make the CMS feel well integrated into the other apps in a given Django project so that it doesn't feel like an afterthought?
[00:21:09] Unknown:
I think this is something that we've we've got a bit better at over the last 2 years. And, in fact, there was perhaps a bit of a misconception that Waitel did was was more of a stand alone app than it than it really is. But in fact, I mean, really, it's, it just inherits from Django the ability to integrate well with other apps. And, you know, they were 1 of the most common answers that we give to questions about, can can Wagtail do such and such is it's, you know, it's just Django. It's it is just a Django app, and it can sit in your existing app as a as a content management part of something more complicated you're doing, or, or you can choose to make Wagtail the primary app and to to attach other apps to it. And, I think it's this is a really clear strength of Django from the beginning, that it's, it's not only enabled, but promoted that kind of, architectural approach, And so it's it's something that we inherit. Having said that, I think there are definitely ways you can make that easier. And, I guess, the most obvious 1 for us is providing hooks into different aspects of of Wagtail's functionality.
And, I think this is something that we we we ought to keep pushing forward with, and perhaps I would have a little mini road map of hooks to be added. And adding hooks is pretty straightforward thing to do. But examples of the hooks that Wagtail offers you are, you know, to to add other apps into into the menu, or to, to do to to carry out to call functions at time of saving or publishing. So a standard example for that might be that if you were using, say, Varnish, or CloudFlare or something as a as a cache and proxy in front of your site that, when you publish a page, you might want to, to purge the cache, using the API for Varnish or Cloudflare or so on. So, that that kind of hook ecosystem has got richer over the over the last couple of years, but I think there's there's there's still more that we could do there.
[00:23:15] Unknown:
And for somebody who wants to get started with using Wagtail, what does that experience look like? And is there a difference if they already have an existing Django project that they're trying to integrate it with versus starting fresh?
[00:23:28] Unknown:
Well, on the on the starting fresh question, it's, it's a it's a bit of a mixed bag, I think. We it was a kind of it was a key focus of mine in the 1st few months to to make it as simple as possible, and we made some really good improvements in this area. So, as an example, we we use Vagrant quite quite heavily at Torchbox and, as a way of standardizing our builds and to making it easy for for designers to to collaborate with developers on projects without having to try and install the Postgres drivers on their Macs. And we kind of you know, we erroneously assume that most of the rest of the Django community is vacant too. So just to start off with Wagtail's, you know, the installation instructions recommended were vacant heavily, and, we quickly realized that lost lost the rest of the community work in different ways. And, and so in the first in the first few months, we we try to really streamline that process.
So mezzanine was 1 of those conundrum systems I mentioned before. The it's 1 of the CMSs which in you know, the aspects of that which inspired our approach for for Wagtail. And 1 thing I really liked out is their their 3 line installation instructions. PIP install in in our case, PIP install Wagtail, Wagtail start project x, and then you see the inter project x and manage pi run server. Migrate, run server. So it's a kind of 3 line 3 lines to get started on, assuming you have a working Django environment or a working Python environment. So that's the good bit. Like, the bad bit is, I guess, what I what I mentioned before is that, because of our approach of, you know, providing a blank canvas, the, the initial experience is somewhat, underwhelming.
As for, integrating with other apps, that's our our documentation. That that's always been fairly straightforward, but our documentation for that has improved recently. So, I hope that any of your listeners who do want to integrate Webtail with those existing apps find that pretty straightforward.
[00:25:30] Unknown:
So what are some of the features that are unique to Wagtail which somebody wouldn't be able to find in a different CMS framework?
[00:25:38] Unknown:
The first I'm gonna talk about is called Streamfield, and this is, again, it's not it's it's not a feature that's particularly easy to describe. And, if your job was selling commercial content management system, you might hope for something a bit more glamorous to be at the top of your list. But, as as people who've been building content managed sites for 15 years, Stream Fields answered a a problem we'd experienced, and then it's and then we've we've discovered it's it's solved that problem for us and may might not be right fit for everyone, but, we've had a lot of very, very positive feedback about it. So I guess if I could start describing Streamfield by talking about 2 different approaches to to content management.
And, 1 end of the scale, at the kind of structured strict end of the scale, you could imagine building building a new page, say, an events page for your site and, deciding upfront all the different types of content that you're gonna have on that page. So there's gonna be some obvious things like title and the date, and, maybe the location. But then, also, you might want to build a, you know, a richer page that's got speaker bios, or the, you know, the the types of food that can be available at the event. And 1 option is that you just create fields for all those type of content, and you make some of them optional.
And, and that will just cope with all the different types of event that you might have in the future. Another option is the it's more like the sort of standard WordPress approach, where you have a big text area with a WYSIWYG editor in it, and, and you use markup to to make tables and insert images and and make subdivisions and so on. And, the problem with the with the strict approach is that it's, it's it's inflexible, and, it requires the implement of the site to make a lot of decisions, which may not turn out to be correct. The problem with the second approach is that, it means all your data is tied up in HTML, often not very nicely formatted HTML. And, that means that it's much harder to to reuse and to repurpose that content. If, for example, if you wanted to create a a mobile site, or a a native mobile app, or even a, an ebook for your content.
So the Wagtail's stream field feature, which, which landed in 1.0 about a year ago, is a sort of middle ground, which allows you, as the site developer, to create a different type of field. So after you've made your title and your dates, and your location, then you might have a stream field field. And, you define the kinds of things that could go in that stream field, like an image or, an embedded video or, quote or a link to a speaker. And then that gets modeled in in JSON in the database, which, means it's it's still structured data that can be filtered and can be, can be accessed through the API, but is, but feels much more kind of free form to the editor. And it and it allows you to create these richer, more, sort of, narrative style content that, you increasingly see with long scrolling pages with, full screen maps and videos and just got a rich content, but, in a way that gives control to the editor without tying up all your data in in HTML. Sorry. This is a rather roundabout way of trying to describe Street View, which is much easier to understand if you use it. But, the upshot of all that is that, stream field enabled Wagtail sites allow a much higher level of flexibility than we've seen in other content management systems.
[00:29:28] Unknown:
Yeah. No. I appreciate you digging into that because that was actually a question that I had a little later on was asking about stream fields. Because I definitely think it's a very innovative approach to that problem. I was actually looking at using Wagtail possibly for a project I was working on that didn't end up coming to fruition. But stream fields is 1 of the determining factors in looking at that because, as you said, there is this tension between flexibility in the layout and ordering of content in a CMS versus making it easy to update and maintain. And I think stream fields does a good job of basically letting you have a defined set of components that are available within a given area of the page or content structure and then being able to, at edit time, determine what ordering and what composition those different card paradigm, and then a couple card paradigm, and then a couple of links. And you wanted to be able to arrange those differently based on the specific content that you're putting in. I think stream fields does a really good job of doing that and also providing some structure for somebody who is producing the content and isn't necessarily familiar enough with HTML or CSS, being able to say, here are some different pieces that you can put together. And you can sort of cut and paste them in the order that makes the most sense for what you're trying to present.
[00:30:57] Unknown:
Yeah. That's great. I'm I'm glad it's, it feels like a good fit for you. And, also, I think the way that you express it makes a lot of sense. And for some reason, it's something that I always slightly struggle to describe, but I think, you and others have put it better. I think it it harks back slightly to the point I was making before about, about trying to encourage developers to to build sites in in in a good way, in a kind of future proof way. And, although, although Wagtail has, the so called rich text field, which could also be part of a stream field, which has, you know, the standard formatting controls that that you're used to for, you know, bold, italics, and lists, and so on.
We we really try to encourage implementers site implementers not to to use those features as little as possible. And I guess, you know, in the long term, it'd be nice to to eliminate that altogether by by making Stream feel better so that, if you, for example, if you paste 4 paragraphs of text into the into the box rather than it being 1 field complain containing paragraph blocks, it'd be nice if it automatically created 4 different stream field paragraphs that you could reorder or insert other content into. And, and was, you know, was and was maintained to structured data behind the scenes in a way that makes it reusable.
I'll just, I'll move on to a couple of other features after Streamfield. So 1 is around image management, which, was was particularly important to our our first user, the Royal College of Art, and I think it's it's been a strength of WebTel's ever since then. We use search, I guess, as the as the the primary mechanism for accessing images in the in the UI. So, if you have elastic search, then then that gets used. So it's it's really quick to to to locate images. But, more importantly, there are some features around how images are displayed, and 1 is, this idea of focal points, which, addresses something that an issue that we've had in the past. So quite often, you might have a large image. For example, it could be a, say say, a portrait of a person, where the head is at the top right of the the image, And, you might show that full, you know, full width on a on a detail page about that person, but you also want a listing of those pages. For example, if you've got a page listing all of the people in your team, and you just want a thumbnail. And there's a couple of options for for doing that. 1 is that you could just resize the image, but then, the head the part you're interested in could be really small. In other words, you could automatically crop it in the middle, but then you might then you might cut the head off.
And, we've we've added a couple of features to Wagtail to to help with that. 1 is the ability for editors to find focal points. So, you can drag an area around a bit of your image, which is most relevant. So, I guess, you know, that most might most commonly be the face. And that means that when, the thumbnailing library works, it will, it will hone in on the the focal point of face. So you can automatically generate thumbnails, which include the the part that you've defined as being relevant. Also, you can turn on, feature detection, which, means that you could automatically if you've got, you know, 100 of thousands of images like some of some Wagtail users have, and, you don't have time to specify focal points, then, Wagtail can use the underlying image recognition libraries to define the features and the faces in the image. So that's been that's something I think that we we haven't highlighted enough, and, it's it's it's quite a powerful part of Wagtail. It, I guess, wouldn't be relevant to all users, but it has certainly is to us.
And, finally, if you can call it a feature, just just to mention the the UI again, I think this is this is something that does distinguish Wagtail, and it's in it. It's it's kind of a feature because there are other, like I said before, capable systems, but, but something I've heard several times from people is, you know, I I did an analysis of the open source CMSs, and, but Webex was the first 1 that I felt happy to put in front of my client. It's a sign that most people should use it without training, which is, you know, can can be a hidden cost to implementing some of these sites. And I think, largely, it's it's been successful with that in in that goal.
[00:34:59] Unknown:
Yeah. I I definitely agree that the admin is a very good feature and very well put together. Having played around a little bit with the Wagtail project, I definitely appreciated the polish and considerations that were put into designing that admin interface because having used WordPress, for instance, a little bit, that admin interface can become rather confusing, particularly as you add different plugins to it, just trying to figure out where you're supposed to do different tasks. And I think that out of the box, Wagtail does a good job of presenting an easy way of getting into producing that content.
[00:35:36] Unknown:
Hey. I agree. I think, you know, WordPress out of the box is, you know, they've there's some really nice touches on it. But, once you start trying to build anything more complicated, then you quickly rely on plug ins. And as you say, I think, the story changes a bit.
[00:35:50] Unknown:
And, I wasn't aware of the automatic feature recognition and the focal points on the images. That definitely sounds like a very useful feature for anybody who has any sizable number of images that they're dealing with. So I I'm sure that that simplified a lot of people's days when they found out about that. Yeah. I see. Given that Wagtail is such a flexible tool, what are some of the gutches that people should watch out for as they're working on a new site?
[00:36:15] Unknown:
I guess the first thing is that, it doesn't feel like I've I've probably said saying this too too often, but it doesn't help you get started with your new site other than, you know, than providing the data you need and the way to manage it. Actually, I mean, that's that's a bit of an exaggeration because, it it makes use of the excellent template tag system that that Django provides. So, there are a number of tags for things like images and embeds. But, otherwise, it it relies on on you understanding the, you know, the the elegant and powerful templating tools that Django provides. Incidentally, I mean, we're not big Ginger 2 users here at Torchbox, but I know lots of people are, and that it has, has a number of advantages over the, over the the the standard Django templating.
And I think, you know, performance can be quite there can be you can see dramatic performance gains in some situations, and Wagtail does have Ginger 2 support for, for those who need it. But, the things that people should watch out for, I mean, I guess it's they're just the things that, that you can you know, mistakes that you can make with any site. And, primarily, they probably come around to the way that your your content your content architecture has been designed, making sure that the information architecture is correct, that that you haven't made too many assumptions in your models before testing. Wagtail doesn't, I guess, like any tool, doesn't really help you with that stuff.
[00:37:43] Unknown:
So does Wagtail have any built in support for multi tenancy?
[00:37:47] Unknown:
Yes. It does. And, this was this was a kind of a key requirement from the beginning as a as a product that was originally built for university and has been used at many universities since then. This kind of setup where you're running maybe 1 major site and a few and a handful of smaller sites is something that that is enabled. So you you define a site, and then, you can assign point in the tree. So I should just just backtrack a bit and say that, Wagtail has a built in idea of a page hierarchy, which is another point that not all content management systems do this, but it, in our experiences, is the best fit with the way that our users thought about their sites.
And so you assign a point in your page hierarchy to, to the site record that you've created, and then, so all requests for, for that domain or subdomain will be routed to that point. So that's always worked, and it's, there's some there's a few nice examples of that. But it's there are some improvements that could be made there, and actually, and another university, Caltech at the moment are, looking into Wagtail. And they, developer Robert Rose is there. He's currently contributing to some work, which is a progress on GitHub around improving the multi tenancy support and particularly around, visibility.
So, there's already kind of pretty solid permissions for, who can edit and manage content. But at the moment, it's, it's on a kind of basis that you can you can see everything. You can see all the other sites. And, generally or at least for the sites that we build, that that hasn't been a problem. But you can imagine for a for a multi tenancy implementation where you have tens or hundreds of sites running for the same instance, then, it just would be confusing for users, who are only interested in their their own 10 page site to see all the other ones and to be able to select images from other ones and so on. So, he's been working on the kind of, reducing the visibility. We've also recently, in in the last version, 1.4, introduced a concept called collections, which is, an idea for creating buckets of content for documents or images or media items, that are, again, typically assigned to sites. So this is a fairly simple way of segmenting material, so that if you need to, you can you can assign permissions to different groups of, non page content.
[00:40:10] Unknown:
And going back briefly to the concept of plug ins, does Wagtail have a plug in system to allow developers to create extensions to the base CMS?
[00:40:19] Unknown:
Yeah. It does. And, well, I don't know if it's calling it a plug in system is a bit grand. I mean, it's, it inherits Django's ability to make it easy to to add apps, and there's there are a number of hooks. And there's also, you know, a growing growing range of, existing third party tools. And, I think if if if your listeners are thinking about adding a plug into Wagtail, then the best place to start would be to look at some of the existing existing tools. So at the very at the very simple end is 1 that I wrote a few months ago at a sprint we had in in Cape Town, that was, this, and this this new plug in provides integration with Google Analytics. So, you can, there's a there's a page within the admin that shows the recent activity on your site. And, version the next version of that, if I get around to it, would be to have, you know, per page information. So when you're editing a page, you can see how many users have been on that page in the last week. That's a really simple plug in. And, but on the other end, the scale is something like plug in called Wagtail Model Admin, which, was developed by, Andy Babic at another agency here in the UK. And, we're increasingly aware that lots of high profile, high complex Wagtail sites are making use of Wagtail Model Admin, which actually, I mean, it itself may mean that you don't need to write a plug in because it's, it's a sort of generic tool for integrating your other Django apps into Wagtail itself. So if you wanna manage non Wagtail content within Wagtail, model admin makes it really easy. It's it's, I mean, you could think of it as a bit like, the, the automatic admin that Django provides, but, reimplemented in Wagtail itself. So that's I guess, that's an example. I mean, apart from being an interesting feature in its own right and 1 that's gonna be merged into Wagtail itself in full time in 1.5, It's also an example of how, how kind of rich and complex a a plug in you you can build on top of Wagtail.
[00:42:19] Unknown:
So having built such a sizable project with deep integrations to Django, what are some of the shortcomings in the framework that you'd like to see improved?
[00:42:28] Unknown:
So there are a couple of things that we've we've worked around. And, actually, and through the process of working around them, we've we've released some, we've released software that that helps. But 1 of those is around images. So in, you know, I guess, most most Python and Django developers will be familiar with Pill or Pillow, which has a high performance, great quality, and, does most of what you need an image manipulation library to do. But it there are some missing features. So for example, the function here functionality around around, animated GIFs isn't great.
And there's, there's an alternative library wand, which, which handles animated GIFs. Or, you might want to use another library for feature section, something in the way that we described earlier. And, at the moment, I think it's it's a bit confusing for, for write down inventors to know which which library to use in which case and whether they need to install them all. And, actually, you know, in some cases, the act of installing is maybe less straightforward than you might like. So, my colleague, Carl, who's, 1 of the the main developers of Wagtail, he launched a project called Willow on GitHub, which is designed to be, a kind of an abstraction on top of the other image libraries. So, it's a, you know, kind of umbrella 1, which which means that you if you if you have Willow and you have, and the underlying libraries, then it will carry out the image manipulation that you need using the the library that's best suited to the task. That's something that's that's been helpful for us in kind of making sure that, Wagtail's image support is as strong as possible.
Another 1 is, around the ability to to cluster models, Django models, and to relate them to connect them together without saving them to the database. This is you know, sounds like a slightly kind of obscure requirement, but, actually, I think it's the the lack of this feature which has meant that, a lot of other Django based CMSs have relied heavily on the admin, the the built in admin interface. So a kind of a key thing that this limitation in Django makes difficult is a preview. So if you want to, if you if you have your set of form fields and you fill them all in, and you and you want to see what your content looks like. In standard Django, you have to save that to the database, and then you have a, you know, template. Then you have a view which which pulls up from the database and shows it. And and maybe you just save it to database in a new table or you give it a using revert versions or something, and you give it a toggle that show that it's just in preview mode, but that can quickly become unwieldy.
So, my my colleague, Matthew, the lead Wagtail developer, open sourced Django model cluster, which is a library which makes it possible to do this grouping of models before they hit the database. So you can use it for previews or for or perhaps, for for serializing these clusters of models, and sending them, know, to another system, without having to send them the the database. So, you know, it's a slightly obscure feature, I think. Well, slightly obscure limitation of Django, but 1 that, once you have a solution for it, you realize that there are, you know, some some some interesting possibilities become possible. So those are 2 areas which which which we've addressed by providing libraries.
But, you know, those libraries, of course, can be improved themselves. I think, for me, the main the main shortcoming in in Django or really all Python web applications is still around ease of deployment. And, here at Torchbox, we've got a we've got a someone in today for a work experience. He's a really, really smart guy called Jack. He's 15 years old. And, he's, he's been, you know, building websites. He's made websites for his friends, and he understands how to upload a PHP file to a server and and edit it and see it change. But, I realized, you know, sitting down with him this morning and explaining what he'd need to do to for for the equivalent in in a Wagtail site. There's there's a lot of steps for him to understand or, you know, not even necessarily understand, but to know that he has to do before you get to that that point of, you know, seeing seeing your beautiful work online.
And, I guess I'd imagined 5 years ago that by now, this part of building building a Python based website would be easier. And I know there are some great there are some great tools, and, you know, the the Heroku model works really well, and, and there's, you know, there's some good Python hosting outfits. And, actually, interestingly, Django CMS, which is, you know, the really the the probably the best known content management system in Django, which is, backed by Divio. They have a they have a system called Aldrin, which is, really a step towards making make it easier to to host Django and, well, certainly, Django CMS based sites and, probably other Python based sites in the future.
But I think it's it's, you know, it's disappointing that that hasn't got easier, and I don't think it's anyone's fault. And this, but, I think that's probably the key impediment for, something like Wagtail or, you know, another Django CMS becoming a serious a a contender to something like WordPress, in in the sort of mainstream web development.
[00:48:02] Unknown:
So are there any questions that we didn't ask that you think we should have, or any topics that you wanna bring up before I move on to the next section?
[00:48:11] Unknown:
Maybe about plans for, for for Wagtail in the next few months. So, some of Wagtail is currently at 1.4, 1 point 4.3 to be exact, and, we we're aiming to have a fairly kind of regular rhythm of of releases. And the goal is to release about every 6 weeks. And, the idea of of that rhythm is that it's it should be it should be easy enough to to upgrade between versions, that it doesn't put people off. So, hopefully, in most cases, it will be an hour or less of your time to upgrade. In most cases, it should just be changing the line in your requirements to a TXD and running a migration. But, but, also, you know, there should be enough features in each release to make it compelling to do that and to to get people to for people who are using Wagtail to feel excited about each release. So and it feels like with the resources we have at the moment and the the the velocity of the the the community that about every 6 weeks is is about right for us. So the next release is 1.5, and, the the key feature here is, the inclusion of Wagtail Model Admin, which I mentioned before, the ability to to manage, either other Django models or, in a in a in a way within the the Wagtail admin itself.
And and there's a there's a host of other features as well. In the in the next 2 or 3 versions, I think there's gonna be a focus on 2 things. 1 is, the user interface, and with this move towards a React based front end, or, which is gonna be led by, the spring loads through the excellent news New Zealand agency I I mentioned earlier. And, that requires this cleaner separation of, models and and front ends, and we're we're achieving that through the development of the the admin API. Those are the the 2 main features, main directions, for the forthcoming months. But I would encourage anyone who's, who's interested in this to start the project on GitHub and to keep track to join the to join the mailing list, and, and hopefully, to to feel a little moment of delight each time, each time in your ocean lands.
[00:50:29] Unknown:
Alright. So for anybody who wants to keep in touch with you and follow what you're up to, what would be the best way for them to do that?
[00:50:35] Unknown:
So we're tweeting at, Wagtail CMS. The the main project site is, wagtail.io, which is gonna be refreshed in a in a month or 2, I hope. And, but most of the activity happens on on the GitHub project, which is, github.com/torchbox/wagtail.
[00:50:55] Unknown:
So with that, we will move it on into the picks. For my first pick today, I'm going to choose pumpkin pie because it is delicious, and I love it. And it's probably 1 of my favorite pies ever, and, my wife was nice enough to make me 1 recently.
[00:51:11] Unknown:
Well, for my pick, I'm gonna continue on on the gastronomic line, and, I'm I'm I'm I'm pretty serious about coffee. And, I've just got some new beans, which I'm really happy with. They're, Ethiopian. They're from a company called HasBean here in the UK. And I ground them this morning, and, and I on my Hario V 60, and, it was a delicious cup of coffee that I'm feeling feeling really good about.
[00:51:38] Unknown:
Great. What was the name of the grinder you said? It's, the the it's it's Hario v 60. Alright. Well, I appreciate you taking the time out of your day to tell us more about Wagtail and the work you've been doing on it. And I'm sure there are a number of people who will be excited to learn about some of the features that it makes available to them. So thank you very much, and I hope you enjoy the rest of your day. Thanks a lot. It's it's, I've really enjoyed it. Bye
[00:52:08] Unknown:
bye.
Hello, and welcome to podcast. In it, the podcast about Python and the people who make it great. I'd like to thank everyone who has donated to the show. Your contributions help us make the show sustainable. For details on how to support the show, you can visit our site at pythonpodcast.com. Linode is sponsoring us this week. Check them out at linode.com/podcastinit and get a $20 credit to try out their fast and reliable Linux virtual servers for your next project. We also have a new sponsor this week. Rollbar is a service for tracking and aggregating your application errors so that you can find and fix the bugs in your application before your users notice they exist. Use the link rollbar.com/podcastinit to get 90 days and 300, 000 errors tracked for free on their bootstrap plan. Visit our site to subscribe to our show, sign up for our newsletter, read the show notes, and get in touch. To help other people find the show, you can leave a review on Itunes, Google Play Music, and tell your friends and coworkers about it. You can also join our community. Visitdiscourse.pythonpodcast.com for your opportunity to find out about upcoming guests, suggest questions, and propose show ideas. Your host as usual is Tobias Macy. And today, I'm interviewing Tom Dyson about Wagtail, a modern and sophisticated CMS for Django. So, Tom, could you please introduce yourself?
[00:01:20] Unknown:
Hi. It's, it's good to be part of this. I'm my name is Tom Dyson. I'm the technical director and cofounder of Torchbox, which is a web agency based in based in the UK with a small office in the US.
[00:01:35] Unknown:
How did you get introduced to Python?
[00:01:38] Unknown:
So I started Torchbox in 2000, grown slowly over the years. In in the 1st few years, we used quite a wide range of technologies and programming languages, and, you know, that was that was a period of very fast change in in the web industry. So, we were building sites in ColdFusion, which I doubt many of your listeners are familiar with, also with Pearl and PHP, and then we played with Ruby and Rails, and, we built a couple of big Java back sites. But, somewhere in those first few years, I I learned Python, really, as a sort of more readable alternative to Perl. So it was initially for for scripting and sysadmin type work, systems work. But it, it it it really connected with me. And then, sometime after that, Django appeared, and, that kind of combination of of beautiful language and a very well thought out web framework meant that Django and Python became the the de facto choice for, the technical parts of our organization.
[00:02:40] Unknown:
And for anybody who's not familiar with the concept, can you start by explaining what a content management system is and why they're useful?
[00:02:48] Unknown:
A content management system, which I'll henceforth abbreviate to CMS, is a very standard tool, and, most of the most of the websites that you will interact with online will be backed by a content management system. So this is a a tool which allows editors and administrators to manage the content without writing HTML by hand. And they vary in sophistication from simple single user systems, which generate flat files, to to large so called enterprise packages, which, which have things like custom workflow and, media management for for massive amounts of assets and data.
[00:03:31] Unknown:
And how did the Wagtail project get started, and what makes it stand out from other comparable offerings?
[00:03:37] Unknown:
So we've been building content managed websites for, I guess, nearly 15 years, and we had our own content management system, something called Rational Media, which, we started in about 2003, 2004. And, and it was it ran some big sites, people like, University of Oxford, and and it was well liked by by its users, but, it it was an open source. And, increasingly, we realized that it wasn't sustainable for us to to carry on offering a piece of software that was critical to our clients' business that was only supported by 1 small company in the UK. So, so we looked around for open source alternatives, and, after some considerable research, we picked Drupal, a PHP content management system, and, which has which has really picked up a momentum over the last decade and run some very big, well known sites.
And, and Drupal's Drupal's been good for us as a business. We carry on building Drupal sites, but at the same time, we felt some frustrations with technical aspects of Drupal. And, and I guess, over the last few years, we've been waiting for somebody else to to provide an open source content management system that that behaved in the way we wanted, but it never quite came. And, obviously, there are some great there are some great projects out there. Some there's lots of very impressive software, but but nothing that that worked really in a way that suited us and our clients. So, in late 2013, we started working with the Royal College of Arts, who are a very distinguished arts university in London, in the UK. And, they had also done an analysis of the open source options for content management. And they they had some specific requirements of their own, and which none of which were were met, or at least not all of which were met by any existing products. So they commissioned us to build them a new content management system, and, with the with the agreement that it would be open sourced at the end.
And so it was the project of building that site, rca.ac.uk, that, was the birth of Wagtail. So shortly after the launch of of that site, we we spent a couple of months pulling out the, the bits that were specific to the client, and, starting the open source project, giving it a name, giving it a brand. And then we launched it at a small Django conference that was, hosted in Wales called, the Django weekend, in February 2014. As for what makes it stand out from other comparable offerings, there there are few principles, which I might I might talk about in more detail later. 1 is that this content management system should be optimized for the developer and, and not not for the administrator.
And that's a slightly difficult point to to make sometimes, and it's certainly not an easy point to sell. But, it's something that that's we found really important, and, and I I feel that that decision's been vindicated by by the way that Webex does work for us and and, apparently, for other developers as well. So just just to talk a little bit more about that, Drupal is an example of, some very powerful software that allows editors or administrators of the site to, to, for example, to create new types of content and to group those types of content and to list them without writing any code. So, there's a user interface with, checkboxes and fields, and they behind the scenes, that will create new tables and relationships.
And, the promise of a system like that is that, as the owner of a website, you will need to depend less on the the developer organizations who are providing it and to manage it more yourself. But, so so this is something that's, you know, it's it's a compelling pitch, and it's something that's, that that can be very powerful. But in our experience, those features are used rarely, and they they cause problems for developers because, the technologies that make that flexibility possible get in the way of developers. So, as a template designer, you're always having to think about what other types of, content might be inserted here.
You also get problems with disparities between development and staging and production environments because, because the the configuration of the type of data is is managed in the database itself, not in code. So Wagtail with Wagtail, we made a very clear decision not to not to take that route, and to to handle things like model changes using the tools that developers like best, which is text files in code and Git for version management and migrations in in Django for, for for applying those changes and deployment tools for making sure that your staging and production environments are kept in sync.
[00:08:42] Unknown:
And what made you choose Django as the basis for the project as opposed to another framework or language such as Pyramid, Flask, or Rails?
[00:08:50] Unknown:
I guess, primarily, it was a it was a pragmatic decision based on our familiarity with with Python compared to, PHP or or Ruby. Clearly, there were alternatives like Pyramid and Flask. I had, followed Simon Willison's blog pretty closely in the, early 2000. He, this is sort of in the days before Hacker News. He he had the the best listing of, new technologies, and he wrote in a very interesting way. I didn't realize at the time that he was probably a teenager when he was writing most of that stuff. And, so I was following him and then, and and enjoying Python. And then, when when he cowrote Django and announced it, then that was something I was immediately interested in, and, and I got, so I, you know, I followed it very closely. I think I, I know that I I made the first screen cast for Django, which is a brief brief moment of fame in the Django community.
And, and I think it's, yeah, it's it's a framework that served us very well. It's become a very supportive and friendly community, and it's something we're really proud to be part of.
[00:09:57] Unknown:
So what is your target user, and are there any situations in which you would encourage someone to use a different CMS?
[00:10:04] Unknown:
At the moment, our target users are definitely developers. And, and I I guess that's another way that, that might be helpful to differentiate Wagtail from other systems. And, certainly, that's the way that Wagtail has become known as an open source project over the last 2 and a half years. It's, it's not so much through head of digital organization or management level. It tends to be developers, particularly Python and Django developers who see Wagtail and and like the approach and, and recommend it to use in their organization. Most of the sites we see built on Wagtail, aside from our own, are are fairly large sites.
So the kind of site where you might have 1, 000, tens of maybe even 100 of thousands of of pages, media files, and, maybe tens of editors. And it's certainly not required for that, and there are also lots of beautiful blogs built on Wagtail. But, I think that the sweet spot for Wagtail is is probably, an organization which has skillful developers and designers and, clearly, which understands Django and, which needs some of the more powerful features that that Wagtail provides. As for situations where we encourage someone else someone to use a different CMS, I think, as I said before, there's there there are lots of fantastic alternatives. For myself, if I were making a simple website for friends and, had an evening to do it, then, I'd probably more likely pick WordPress because I know that I can, get it hosted in in 10 minutes on wordpress.com, and pick a theme. And, you know, this is it's a quicker way to make a simple site. Or I might look at, Jekyll or Pelican or 1 of the other static site generators.
Otherwise, I mean, Wagtail's, like I said, it's it's it's used for a pretty wide variety of some some some really very large sites, down to some beautiful blocks. So it's, if you know Django and, you're you're willing to create the the look and feel and to to write the HTML and CSS yourself, then then Wagtail should be a good fit for you.
[00:12:09] Unknown:
So can you explain the software design approach that was taken with Wagtail and describe some of the challenges that have been overcome along the way?
[00:12:17] Unknown:
I guess the the primary principle is the 1 that I've mentioned already that we should we should optimize for developers. And, that's been something that we've we've been clear about internally. I wanna say internally, I mean, that's that's slightly out of date now because although Wagtail was created here at Torchbox, it's now a large open source project with, some fantastic agencies supporting it. Some really notable examples are, Springload in New Zealand, who are running the 1st New Zealand Wagtail meetup tonight and take flight in Tasmania, Australia, Leukine in in the Netherlands. Lots of lots of great agencies and other large organizations around the world. But the certainly, the the initial design approach was around optimizing the developers. And, I guess a challenge that that brings is that, the initial experience of using Wagtail might feel slightly underwhelming compared to, some some of the alternatives because, you set it up, you install it, that all happens pretty quickly now, and you, you create your Wagtail instance, and, you have a very uninspiring plain page with a couple of lines of text. And, in the back end, you have a single home page with with 1 content with 1 field in it. And, you know, and then it's it's left to you to to create a site, to build your your models and, and to your templates on top of that. So I think that's a that's a challenge of taking this kind of the purest approach is that, the, the initial experience can be less less exciting. As for other software design approaches, another another clear principle is that we're not opinionated about the markup that's used in the front end. So you can use whatever CSS JavaScript framework you like. You it may even be that you choose to use Wagtail as a so called headless CMS, and the the client is a JavaScript application or a native mobile application.
And I guess that that also can contribute to this sense that, you it's it's a very blank canvas when you start. But within that framework of giving implementers freedom, we also want to encourage people to make websites in in a way that, is is good for the web, which maybe sounds a bit contradictory because it's maybe sounds like we're being a bit opinionated here. So we're not forcing people to do things, but we're just making sure that Wagtail, I guess, doesn't, doesn't make it easy to to do things badly. So an example of that is, quite a controversial example, in, on on the on the GitHub issue list is, the inability to create links that open in new windows, which is a frequent request, and lots of people have have asked for a setting or a that that would mean that you could open new windows or at least have the option to to toggle that. And I think that's something that you can do yourself by, putting it in your templates, but it's, we don't think that opening links in new windows is, is good for for usability, and, that it can lead to some anti patterns in in interface design. So, I guess, you know, we've we've made decision for for Wagtail at least not to make that easy for for people.
[00:15:14] Unknown:
Yeah. It's easy enough to just control click on a link if you want to open it in a new tab. So having that decision forced upon the user is, sometimes non intuitive and frustrating.
[00:15:24] Unknown:
Right. I agree.
[00:15:25] Unknown:
You mentioned that Wagtail has the ability to be used as a headless CMS so that you can do a single page app style front end and then just use Wagtail as delivering content over an API, which I think is 1 of the distinguishing factors of Wagtail versus a lot of the other CMSs that are available, which are more tightly integrated between back and front end. So I think that is a pretty innovative approach and definitely very forward thinking because that's the way that a lot of modern web applications are going is using the single page front end, single page app style with a heavy JavaScript front end and an API back end. So I think that's 1 way to stay relevant as the current state of the art progresses.
[00:16:07] Unknown:
Right. Thanks for making that point better than I did. That's a it's that is a point important aspect of, of Wagtail, I think. And it's something that became clear to us quite early on in in Wagtail's history, where we were commissioned by, it's a it's a very high profile site in the US that we're we're not allowed to talk about yet. I hope we will be able to do sometime in the next year or so, but it's, certainly a site that that you will have heard of. And they, they commissioned us to to build the first API for Wagtail, precisely for this reason. Because, for the the particular purpose of this site, it it it does it does deliver pages, but, a more important aspect of it is that it's gonna use Wagtail as, or is now using Wagtail as a system for for managing content and and for handling the workflow and moderation around that and, asset management and so on. But, that that that content will be delivered by through APIs to, mobile phones, both on mobile optimized websites, but also native sites, using some pretty tightly segmented rules around location and so on. And so that was, you know, it was great to have that commission and and to to build that into Waitel. And so that was an early indication of of the way that, as you say, I think, it's it's it's an emerging trend in content management systems.
Since then, there's been quite a lot of focus on the API. Tom Christie, who's the, the author of the Django REST framework, which is really the sort of preeminent app for for building REST APIs in Django. He contributed a reworking refactoring of our initial API using Django Rest framework. And, we're currently working on, separate API, which we're is currently labeled the the admin API, and this is gonna enable us to make a cleaner distinction between models and and the and, and the interface in the Wagtail, UI itself.
So we've, we've got lots of ideas around, improving the user interface, and, I think the first step of that is gonna be trying to disentangle the slightly, you know, kind of jQuery spaghetti we have at the moment and make Wagtail itself, cleaner, probably a React based app. And, and that that reminds me of something else I should talk about in terms of, distinguishing features for Wagtail, and that's its its user interface. So, there are, as as you you and your listeners will be aware, there there are plenty of really mature and, interesting content management systems in in Django. Some of the more famous ones are Django CMS, Mezzanine, and Fine CMS.
And I think Django has always been, you know, right from its its history as a tool for building newspaper websites. So it's feels like a good fit for content management systems because the the automatic admin interface makes it very easy and to to create a, you know, pretty attractive and effective tool for managing your models. But, in a way, that that automatic and easy admin space has has been has been an issue. It's been a problem in some ways for Django because it's it's so easy to do that, often people who are implementing tools on top of it will stop there. And then they won't think any harder about the way that the editors or authors or their users want to interact with the content. And that's something that we took pretty seriously with Wagtail. And I guess it's, because originating at Torchbox where we're not just programmers, but also designers and UX people and testers and so on, that, that meant that we could apply all of that experience and to to building a new product. And I think that was 1 of the reasons why why I made a bit of a a little splash when we launched it. It's because, it it looks pretty, and it it feels good, and it it feels it feels different to, to a lot of other Django based open source projects.
And that focus on user experience is something that we've we've maintained in the last couple of years. And, and it's it's an area that we're we're making a particular push on in the 4th in the next 6 months.
[00:20:16] Unknown:
And also since you're comparing Wagtail to some of the other Django CMSs available, I'd also like to call out the fact that you are 1 of only 2 or 3, I believe, of the, I think, dozen or so that are available that actually supports Python 3 natively.
[00:20:30] Unknown:
Right. Yeah. That's, we we, just, you know, within Talksbox more generally, we are very keen to to support Python 3, you know, and and wherever possible, we start new projects on Python 3. That is almost always possible these days, and, and so that you know, it felt like making sure that we had, you know, that we we that Wagtail was supporting Python 3 from the from the beginning was a, you know, a small but important to us contribution to to the progress of Python 3.
[00:20:59] Unknown:
So how did you approach the project in a way to make the CMS feel well integrated into the other apps in a given Django project so that it doesn't feel like an afterthought?
[00:21:09] Unknown:
I think this is something that we've we've got a bit better at over the last 2 years. And, in fact, there was perhaps a bit of a misconception that Waitel did was was more of a stand alone app than it than it really is. But in fact, I mean, really, it's, it just inherits from Django the ability to integrate well with other apps. And, you know, they were 1 of the most common answers that we give to questions about, can can Wagtail do such and such is it's, you know, it's just Django. It's it is just a Django app, and it can sit in your existing app as a as a content management part of something more complicated you're doing, or, or you can choose to make Wagtail the primary app and to to attach other apps to it. And, I think it's this is a really clear strength of Django from the beginning, that it's, it's not only enabled, but promoted that kind of, architectural approach, And so it's it's something that we inherit. Having said that, I think there are definitely ways you can make that easier. And, I guess, the most obvious 1 for us is providing hooks into different aspects of of Wagtail's functionality.
And, I think this is something that we we we ought to keep pushing forward with, and perhaps I would have a little mini road map of hooks to be added. And adding hooks is pretty straightforward thing to do. But examples of the hooks that Wagtail offers you are, you know, to to add other apps into into the menu, or to, to do to to carry out to call functions at time of saving or publishing. So a standard example for that might be that if you were using, say, Varnish, or CloudFlare or something as a as a cache and proxy in front of your site that, when you publish a page, you might want to, to purge the cache, using the API for Varnish or Cloudflare or so on. So, that that kind of hook ecosystem has got richer over the over the last couple of years, but I think there's there's there's still more that we could do there.
[00:23:15] Unknown:
And for somebody who wants to get started with using Wagtail, what does that experience look like? And is there a difference if they already have an existing Django project that they're trying to integrate it with versus starting fresh?
[00:23:28] Unknown:
Well, on the on the starting fresh question, it's, it's a it's a bit of a mixed bag, I think. We it was a kind of it was a key focus of mine in the 1st few months to to make it as simple as possible, and we made some really good improvements in this area. So, as an example, we we use Vagrant quite quite heavily at Torchbox and, as a way of standardizing our builds and to making it easy for for designers to to collaborate with developers on projects without having to try and install the Postgres drivers on their Macs. And we kind of you know, we erroneously assume that most of the rest of the Django community is vacant too. So just to start off with Wagtail's, you know, the installation instructions recommended were vacant heavily, and, we quickly realized that lost lost the rest of the community work in different ways. And, and so in the first in the first few months, we we try to really streamline that process.
So mezzanine was 1 of those conundrum systems I mentioned before. The it's 1 of the CMSs which in you know, the aspects of that which inspired our approach for for Wagtail. And 1 thing I really liked out is their their 3 line installation instructions. PIP install in in our case, PIP install Wagtail, Wagtail start project x, and then you see the inter project x and manage pi run server. Migrate, run server. So it's a kind of 3 line 3 lines to get started on, assuming you have a working Django environment or a working Python environment. So that's the good bit. Like, the bad bit is, I guess, what I what I mentioned before is that, because of our approach of, you know, providing a blank canvas, the, the initial experience is somewhat, underwhelming.
As for, integrating with other apps, that's our our documentation. That that's always been fairly straightforward, but our documentation for that has improved recently. So, I hope that any of your listeners who do want to integrate Webtail with those existing apps find that pretty straightforward.
[00:25:30] Unknown:
So what are some of the features that are unique to Wagtail which somebody wouldn't be able to find in a different CMS framework?
[00:25:38] Unknown:
The first I'm gonna talk about is called Streamfield, and this is, again, it's not it's it's not a feature that's particularly easy to describe. And, if your job was selling commercial content management system, you might hope for something a bit more glamorous to be at the top of your list. But, as as people who've been building content managed sites for 15 years, Stream Fields answered a a problem we'd experienced, and then it's and then we've we've discovered it's it's solved that problem for us and may might not be right fit for everyone, but, we've had a lot of very, very positive feedback about it. So I guess if I could start describing Streamfield by talking about 2 different approaches to to content management.
And, 1 end of the scale, at the kind of structured strict end of the scale, you could imagine building building a new page, say, an events page for your site and, deciding upfront all the different types of content that you're gonna have on that page. So there's gonna be some obvious things like title and the date, and, maybe the location. But then, also, you might want to build a, you know, a richer page that's got speaker bios, or the, you know, the the types of food that can be available at the event. And 1 option is that you just create fields for all those type of content, and you make some of them optional.
And, and that will just cope with all the different types of event that you might have in the future. Another option is the it's more like the sort of standard WordPress approach, where you have a big text area with a WYSIWYG editor in it, and, and you use markup to to make tables and insert images and and make subdivisions and so on. And, the problem with the with the strict approach is that it's, it's it's inflexible, and, it requires the implement of the site to make a lot of decisions, which may not turn out to be correct. The problem with the second approach is that, it means all your data is tied up in HTML, often not very nicely formatted HTML. And, that means that it's much harder to to reuse and to repurpose that content. If, for example, if you wanted to create a a mobile site, or a a native mobile app, or even a, an ebook for your content.
So the Wagtail's stream field feature, which, which landed in 1.0 about a year ago, is a sort of middle ground, which allows you, as the site developer, to create a different type of field. So after you've made your title and your dates, and your location, then you might have a stream field field. And, you define the kinds of things that could go in that stream field, like an image or, an embedded video or, quote or a link to a speaker. And then that gets modeled in in JSON in the database, which, means it's it's still structured data that can be filtered and can be, can be accessed through the API, but is, but feels much more kind of free form to the editor. And it and it allows you to create these richer, more, sort of, narrative style content that, you increasingly see with long scrolling pages with, full screen maps and videos and just got a rich content, but, in a way that gives control to the editor without tying up all your data in in HTML. Sorry. This is a rather roundabout way of trying to describe Street View, which is much easier to understand if you use it. But, the upshot of all that is that, stream field enabled Wagtail sites allow a much higher level of flexibility than we've seen in other content management systems.
[00:29:28] Unknown:
Yeah. No. I appreciate you digging into that because that was actually a question that I had a little later on was asking about stream fields. Because I definitely think it's a very innovative approach to that problem. I was actually looking at using Wagtail possibly for a project I was working on that didn't end up coming to fruition. But stream fields is 1 of the determining factors in looking at that because, as you said, there is this tension between flexibility in the layout and ordering of content in a CMS versus making it easy to update and maintain. And I think stream fields does a good job of basically letting you have a defined set of components that are available within a given area of the page or content structure and then being able to, at edit time, determine what ordering and what composition those different card paradigm, and then a couple card paradigm, and then a couple of links. And you wanted to be able to arrange those differently based on the specific content that you're putting in. I think stream fields does a really good job of doing that and also providing some structure for somebody who is producing the content and isn't necessarily familiar enough with HTML or CSS, being able to say, here are some different pieces that you can put together. And you can sort of cut and paste them in the order that makes the most sense for what you're trying to present.
[00:30:57] Unknown:
Yeah. That's great. I'm I'm glad it's, it feels like a good fit for you. And, also, I think the way that you express it makes a lot of sense. And for some reason, it's something that I always slightly struggle to describe, but I think, you and others have put it better. I think it it harks back slightly to the point I was making before about, about trying to encourage developers to to build sites in in in a good way, in a kind of future proof way. And, although, although Wagtail has, the so called rich text field, which could also be part of a stream field, which has, you know, the standard formatting controls that that you're used to for, you know, bold, italics, and lists, and so on.
We we really try to encourage implementers site implementers not to to use those features as little as possible. And I guess, you know, in the long term, it'd be nice to to eliminate that altogether by by making Stream feel better so that, if you, for example, if you paste 4 paragraphs of text into the into the box rather than it being 1 field complain containing paragraph blocks, it'd be nice if it automatically created 4 different stream field paragraphs that you could reorder or insert other content into. And, and was, you know, was and was maintained to structured data behind the scenes in a way that makes it reusable.
I'll just, I'll move on to a couple of other features after Streamfield. So 1 is around image management, which, was was particularly important to our our first user, the Royal College of Art, and I think it's it's been a strength of WebTel's ever since then. We use search, I guess, as the as the the primary mechanism for accessing images in the in the UI. So, if you have elastic search, then then that gets used. So it's it's really quick to to to locate images. But, more importantly, there are some features around how images are displayed, and 1 is, this idea of focal points, which, addresses something that an issue that we've had in the past. So quite often, you might have a large image. For example, it could be a, say say, a portrait of a person, where the head is at the top right of the the image, And, you might show that full, you know, full width on a on a detail page about that person, but you also want a listing of those pages. For example, if you've got a page listing all of the people in your team, and you just want a thumbnail. And there's a couple of options for for doing that. 1 is that you could just resize the image, but then, the head the part you're interested in could be really small. In other words, you could automatically crop it in the middle, but then you might then you might cut the head off.
And, we've we've added a couple of features to Wagtail to to help with that. 1 is the ability for editors to find focal points. So, you can drag an area around a bit of your image, which is most relevant. So, I guess, you know, that most might most commonly be the face. And that means that when, the thumbnailing library works, it will, it will hone in on the the focal point of face. So you can automatically generate thumbnails, which include the the part that you've defined as being relevant. Also, you can turn on, feature detection, which, means that you could automatically if you've got, you know, 100 of thousands of images like some of some Wagtail users have, and, you don't have time to specify focal points, then, Wagtail can use the underlying image recognition libraries to define the features and the faces in the image. So that's been that's something I think that we we haven't highlighted enough, and, it's it's it's quite a powerful part of Wagtail. It, I guess, wouldn't be relevant to all users, but it has certainly is to us.
And, finally, if you can call it a feature, just just to mention the the UI again, I think this is this is something that does distinguish Wagtail, and it's in it. It's it's kind of a feature because there are other, like I said before, capable systems, but, but something I've heard several times from people is, you know, I I did an analysis of the open source CMSs, and, but Webex was the first 1 that I felt happy to put in front of my client. It's a sign that most people should use it without training, which is, you know, can can be a hidden cost to implementing some of these sites. And I think, largely, it's it's been successful with that in in that goal.
[00:34:59] Unknown:
Yeah. I I definitely agree that the admin is a very good feature and very well put together. Having played around a little bit with the Wagtail project, I definitely appreciated the polish and considerations that were put into designing that admin interface because having used WordPress, for instance, a little bit, that admin interface can become rather confusing, particularly as you add different plugins to it, just trying to figure out where you're supposed to do different tasks. And I think that out of the box, Wagtail does a good job of presenting an easy way of getting into producing that content.
[00:35:36] Unknown:
Hey. I agree. I think, you know, WordPress out of the box is, you know, they've there's some really nice touches on it. But, once you start trying to build anything more complicated, then you quickly rely on plug ins. And as you say, I think, the story changes a bit.
[00:35:50] Unknown:
And, I wasn't aware of the automatic feature recognition and the focal points on the images. That definitely sounds like a very useful feature for anybody who has any sizable number of images that they're dealing with. So I I'm sure that that simplified a lot of people's days when they found out about that. Yeah. I see. Given that Wagtail is such a flexible tool, what are some of the gutches that people should watch out for as they're working on a new site?
[00:36:15] Unknown:
I guess the first thing is that, it doesn't feel like I've I've probably said saying this too too often, but it doesn't help you get started with your new site other than, you know, than providing the data you need and the way to manage it. Actually, I mean, that's that's a bit of an exaggeration because, it it makes use of the excellent template tag system that that Django provides. So, there are a number of tags for things like images and embeds. But, otherwise, it it relies on on you understanding the, you know, the the elegant and powerful templating tools that Django provides. Incidentally, I mean, we're not big Ginger 2 users here at Torchbox, but I know lots of people are, and that it has, has a number of advantages over the, over the the the standard Django templating.
And I think, you know, performance can be quite there can be you can see dramatic performance gains in some situations, and Wagtail does have Ginger 2 support for, for those who need it. But, the things that people should watch out for, I mean, I guess it's they're just the things that, that you can you know, mistakes that you can make with any site. And, primarily, they probably come around to the way that your your content your content architecture has been designed, making sure that the information architecture is correct, that that you haven't made too many assumptions in your models before testing. Wagtail doesn't, I guess, like any tool, doesn't really help you with that stuff.
[00:37:43] Unknown:
So does Wagtail have any built in support for multi tenancy?
[00:37:47] Unknown:
Yes. It does. And, this was this was a kind of a key requirement from the beginning as a as a product that was originally built for university and has been used at many universities since then. This kind of setup where you're running maybe 1 major site and a few and a handful of smaller sites is something that that is enabled. So you you define a site, and then, you can assign point in the tree. So I should just just backtrack a bit and say that, Wagtail has a built in idea of a page hierarchy, which is another point that not all content management systems do this, but it, in our experiences, is the best fit with the way that our users thought about their sites.
And so you assign a point in your page hierarchy to, to the site record that you've created, and then, so all requests for, for that domain or subdomain will be routed to that point. So that's always worked, and it's, there's some there's a few nice examples of that. But it's there are some improvements that could be made there, and actually, and another university, Caltech at the moment are, looking into Wagtail. And they, developer Robert Rose is there. He's currently contributing to some work, which is a progress on GitHub around improving the multi tenancy support and particularly around, visibility.
So, there's already kind of pretty solid permissions for, who can edit and manage content. But at the moment, it's, it's on a kind of basis that you can you can see everything. You can see all the other sites. And, generally or at least for the sites that we build, that that hasn't been a problem. But you can imagine for a for a multi tenancy implementation where you have tens or hundreds of sites running for the same instance, then, it just would be confusing for users, who are only interested in their their own 10 page site to see all the other ones and to be able to select images from other ones and so on. So, he's been working on the kind of, reducing the visibility. We've also recently, in in the last version, 1.4, introduced a concept called collections, which is, an idea for creating buckets of content for documents or images or media items, that are, again, typically assigned to sites. So this is a fairly simple way of segmenting material, so that if you need to, you can you can assign permissions to different groups of, non page content.
[00:40:10] Unknown:
And going back briefly to the concept of plug ins, does Wagtail have a plug in system to allow developers to create extensions to the base CMS?
[00:40:19] Unknown:
Yeah. It does. And, well, I don't know if it's calling it a plug in system is a bit grand. I mean, it's, it inherits Django's ability to make it easy to to add apps, and there's there are a number of hooks. And there's also, you know, a growing growing range of, existing third party tools. And, I think if if if your listeners are thinking about adding a plug into Wagtail, then the best place to start would be to look at some of the existing existing tools. So at the very at the very simple end is 1 that I wrote a few months ago at a sprint we had in in Cape Town, that was, this, and this this new plug in provides integration with Google Analytics. So, you can, there's a there's a page within the admin that shows the recent activity on your site. And, version the next version of that, if I get around to it, would be to have, you know, per page information. So when you're editing a page, you can see how many users have been on that page in the last week. That's a really simple plug in. And, but on the other end, the scale is something like plug in called Wagtail Model Admin, which, was developed by, Andy Babic at another agency here in the UK. And, we're increasingly aware that lots of high profile, high complex Wagtail sites are making use of Wagtail Model Admin, which actually, I mean, it itself may mean that you don't need to write a plug in because it's, it's a sort of generic tool for integrating your other Django apps into Wagtail itself. So if you wanna manage non Wagtail content within Wagtail, model admin makes it really easy. It's it's, I mean, you could think of it as a bit like, the, the automatic admin that Django provides, but, reimplemented in Wagtail itself. So that's I guess, that's an example. I mean, apart from being an interesting feature in its own right and 1 that's gonna be merged into Wagtail itself in full time in 1.5, It's also an example of how, how kind of rich and complex a a plug in you you can build on top of Wagtail.
[00:42:19] Unknown:
So having built such a sizable project with deep integrations to Django, what are some of the shortcomings in the framework that you'd like to see improved?
[00:42:28] Unknown:
So there are a couple of things that we've we've worked around. And, actually, and through the process of working around them, we've we've released some, we've released software that that helps. But 1 of those is around images. So in, you know, I guess, most most Python and Django developers will be familiar with Pill or Pillow, which has a high performance, great quality, and, does most of what you need an image manipulation library to do. But it there are some missing features. So for example, the function here functionality around around, animated GIFs isn't great.
And there's, there's an alternative library wand, which, which handles animated GIFs. Or, you might want to use another library for feature section, something in the way that we described earlier. And, at the moment, I think it's it's a bit confusing for, for write down inventors to know which which library to use in which case and whether they need to install them all. And, actually, you know, in some cases, the act of installing is maybe less straightforward than you might like. So, my colleague, Carl, who's, 1 of the the main developers of Wagtail, he launched a project called Willow on GitHub, which is designed to be, a kind of an abstraction on top of the other image libraries. So, it's a, you know, kind of umbrella 1, which which means that you if you if you have Willow and you have, and the underlying libraries, then it will carry out the image manipulation that you need using the the library that's best suited to the task. That's something that's that's been helpful for us in kind of making sure that, Wagtail's image support is as strong as possible.
Another 1 is, around the ability to to cluster models, Django models, and to relate them to connect them together without saving them to the database. This is you know, sounds like a slightly kind of obscure requirement, but, actually, I think it's the the lack of this feature which has meant that, a lot of other Django based CMSs have relied heavily on the admin, the the built in admin interface. So a kind of a key thing that this limitation in Django makes difficult is a preview. So if you want to, if you if you have your set of form fields and you fill them all in, and you and you want to see what your content looks like. In standard Django, you have to save that to the database, and then you have a, you know, template. Then you have a view which which pulls up from the database and shows it. And and maybe you just save it to database in a new table or you give it a using revert versions or something, and you give it a toggle that show that it's just in preview mode, but that can quickly become unwieldy.
So, my my colleague, Matthew, the lead Wagtail developer, open sourced Django model cluster, which is a library which makes it possible to do this grouping of models before they hit the database. So you can use it for previews or for or perhaps, for for serializing these clusters of models, and sending them, know, to another system, without having to send them the the database. So, you know, it's a slightly obscure feature, I think. Well, slightly obscure limitation of Django, but 1 that, once you have a solution for it, you realize that there are, you know, some some some interesting possibilities become possible. So those are 2 areas which which which we've addressed by providing libraries.
But, you know, those libraries, of course, can be improved themselves. I think, for me, the main the main shortcoming in in Django or really all Python web applications is still around ease of deployment. And, here at Torchbox, we've got a we've got a someone in today for a work experience. He's a really, really smart guy called Jack. He's 15 years old. And, he's, he's been, you know, building websites. He's made websites for his friends, and he understands how to upload a PHP file to a server and and edit it and see it change. But, I realized, you know, sitting down with him this morning and explaining what he'd need to do to for for the equivalent in in a Wagtail site. There's there's a lot of steps for him to understand or, you know, not even necessarily understand, but to know that he has to do before you get to that that point of, you know, seeing seeing your beautiful work online.
And, I guess I'd imagined 5 years ago that by now, this part of building building a Python based website would be easier. And I know there are some great there are some great tools, and, you know, the the Heroku model works really well, and, and there's, you know, there's some good Python hosting outfits. And, actually, interestingly, Django CMS, which is, you know, the really the the probably the best known content management system in Django, which is, backed by Divio. They have a they have a system called Aldrin, which is, really a step towards making make it easier to to host Django and, well, certainly, Django CMS based sites and, probably other Python based sites in the future.
But I think it's it's, you know, it's disappointing that that hasn't got easier, and I don't think it's anyone's fault. And this, but, I think that's probably the key impediment for, something like Wagtail or, you know, another Django CMS becoming a serious a a contender to something like WordPress, in in the sort of mainstream web development.
[00:48:02] Unknown:
So are there any questions that we didn't ask that you think we should have, or any topics that you wanna bring up before I move on to the next section?
[00:48:11] Unknown:
Maybe about plans for, for for Wagtail in the next few months. So, some of Wagtail is currently at 1.4, 1 point 4.3 to be exact, and, we we're aiming to have a fairly kind of regular rhythm of of releases. And the goal is to release about every 6 weeks. And, the idea of of that rhythm is that it's it should be it should be easy enough to to upgrade between versions, that it doesn't put people off. So, hopefully, in most cases, it will be an hour or less of your time to upgrade. In most cases, it should just be changing the line in your requirements to a TXD and running a migration. But, but, also, you know, there should be enough features in each release to make it compelling to do that and to to get people to for people who are using Wagtail to feel excited about each release. So and it feels like with the resources we have at the moment and the the the velocity of the the the community that about every 6 weeks is is about right for us. So the next release is 1.5, and, the the key feature here is, the inclusion of Wagtail Model Admin, which I mentioned before, the ability to to manage, either other Django models or, in a in a in a way within the the Wagtail admin itself.
And and there's a there's a host of other features as well. In the in the next 2 or 3 versions, I think there's gonna be a focus on 2 things. 1 is, the user interface, and with this move towards a React based front end, or, which is gonna be led by, the spring loads through the excellent news New Zealand agency I I mentioned earlier. And, that requires this cleaner separation of, models and and front ends, and we're we're achieving that through the development of the the admin API. Those are the the 2 main features, main directions, for the forthcoming months. But I would encourage anyone who's, who's interested in this to start the project on GitHub and to keep track to join the to join the mailing list, and, and hopefully, to to feel a little moment of delight each time, each time in your ocean lands.
[00:50:29] Unknown:
Alright. So for anybody who wants to keep in touch with you and follow what you're up to, what would be the best way for them to do that?
[00:50:35] Unknown:
So we're tweeting at, Wagtail CMS. The the main project site is, wagtail.io, which is gonna be refreshed in a in a month or 2, I hope. And, but most of the activity happens on on the GitHub project, which is, github.com/torchbox/wagtail.
[00:50:55] Unknown:
So with that, we will move it on into the picks. For my first pick today, I'm going to choose pumpkin pie because it is delicious, and I love it. And it's probably 1 of my favorite pies ever, and, my wife was nice enough to make me 1 recently.
[00:51:11] Unknown:
Well, for my pick, I'm gonna continue on on the gastronomic line, and, I'm I'm I'm I'm pretty serious about coffee. And, I've just got some new beans, which I'm really happy with. They're, Ethiopian. They're from a company called HasBean here in the UK. And I ground them this morning, and, and I on my Hario V 60, and, it was a delicious cup of coffee that I'm feeling feeling really good about.
[00:51:38] Unknown:
Great. What was the name of the grinder you said? It's, the the it's it's Hario v 60. Alright. Well, I appreciate you taking the time out of your day to tell us more about Wagtail and the work you've been doing on it. And I'm sure there are a number of people who will be excited to learn about some of the features that it makes available to them. So thank you very much, and I hope you enjoy the rest of your day. Thanks a lot. It's it's, I've really enjoyed it. Bye
[00:52:08] Unknown:
bye.
Introduction to Tom Dyson and Torchbox
What is a CMS?
The Birth of Wagtail
Developer-Centric Design
Choosing Django for Wagtail
Target Users and Use Cases
Software Design Approach
Headless CMS and API
User Interface and Experience
Python 3 Support
Integration with Other Apps
Getting Started with Wagtail
Unique Features of Wagtail
Common Pitfalls
Multi-Tenancy Support
Plugin System
Shortcomings in Django
Future Plans for Wagtail
Staying Connected
Picks
