Prepare for a more automated content future with Wagtail 8.0

One of the mantras of content creation is “know your audience.” Getting to know what humans need and want from your content is hard enough. Now that rapid AI adoption means that more bots are visiting websites than humans though, you have to start thinking about what machines are going to want from your Wagtail projects as well.

As we highlighted in our product strategy, we want Wagtail users to be in a position to take advantage of useful advances in AI and AI agents if they choose to. That's why this release contains several features to make it easier for Wagtail to be integrated into automated workflows. Whether these features are used by humans or agents, they'll give you even more flexibility to adapt your content to whatever new normal emerges. Let's take a look at all the things you can do with Wagtail 8.0.

One of the biggest changes in this release is the introduction of a preview of a new v3 of the Wagtail REST API. This is an important component of the technology changes we're making to Wagtail to support the delivery of our new product strategy, and contribute to achieving our long term vision of making Wagtail “a compelling choice for organisations that genuinely care about security, a responsible approach to AI, and the impact of the technology they use on people and planet.”

Past versions of the API were read-only, which meant content within Wagtail could be fetched and copied but you couldn't use the API to publish or modify content within Wagtail. The new REST API gives you write functions as well so you can publish directly to Wagtail through the API.

Having write capabilities opens up a lot of possibilities for you to publish and manage content wifh AI assistants or agents if you want to grant them access to your Wagtail content. The API comes with a lot of rich features for managing and organizing content as well, such as the option to publish content in draft form first or using the API to access content revisions.

The newest version of the API also includes more content types. In addition to pages, images, documents, and redirects, you can use the API to work with Snippets, StreamField blocks, locales, and translation content as well. You can customize and control the content types you want to make accessible through the API as well as which fields are writable.

There are new output formats available in this version of the API too. You can stick with Wagtail's standard data output or you can convert your data to HTML or markdown. There is also a schema endpoint for auto-generating OpenAPI 3.1 schemas in JSON for your content (which is a format that can help popular AI chatbots discover and digest your content). These features give you more options for making your content available to other systems and workflows. More importantly, you'll be able to provide your content to bot visitors in machine readable formats that can help them (and the humans that are commanding them) make good use of your content.

One thing we definitely want to stress is that we're designating this version of the v3 API a preview. We're expecting to adapt this version based on feedback and any gaps our users highlight, so this might mean backwards-incompatible changes in future releases. Definitely open an issue or start a discussion in the Wagtail repository if there is anything you think we should add, and we'd love to hear about your experiments too!

The foundational model in any Wagtail project is the Page model. Think of it like the standard block you would use in an old-fashioned printing press. It has all the things you would use on every single page like page numbers, borders, dates, etc. Yet even back when ink and presses were more common in publishing, not every publisher would use the same standard block because they all had different styles and paper sizes that they worked with.

Similarly, everyone who builds a project in Wagtail has different needs for their pages. There are some standard fields that are used no matter what (like the slug and page title), but a lot of people need custom fields added to their page models for social media or location data or categorizing content. So a lot of developers create a custom model that overrides the standard Page model.

We turned that common practice into an officially supported feature. When you start a new project, now you can define your own custom BasePage at the very beginning. This gives you a simpler way to customize your very own standard page so you aren't having to tack on a bunch of extra stuff every time you update page code in Wagtail.

In a world with a lot more agents and bots buzzing around, permissions are going to matter a whole lot more. One of Wagtail's strengths is how easily you can customize access to particular pages, snippets, content types, and other features.

We decided to make it a bit easier by adding a global permission policy registry in Wagtail 8.0. Using the registry, you can retrieve permissions settings from anywhere in the code. Think of it like a central security guard who can check your badge from anywhere in the building instead of making you go to a particular floor to wait in line. This feature will make it simpler for you to build permission checks into background tasks and other automations to make sure that the only people (or bots) that are accessing your content are the ones who are supposed to.

AVIF and WEBP are greener image formats that offer a high degree of quality with smaller file sizes than PNG and JPEG. However, there wasn't a lot of browser support for these formats when we first added them to Wagtail, so Wagtail automatically converted AVIF and WEBP images into PNG images by default for a long time.

The good news is now there is great browser support for these image formats! We've removed the default conversion in Wagtail 8.0 and we thoroughly encourage you to do our planet a favour by using these image formats as much as you can.

This release includes a handful of improvements that will help make using Wagtail a better experience for people who use screenreaders. We've provided more accessible labels for blank values (like the initial blank value of a dropdown menu before you make a selection), and also did a small update on how buttons without URLs are handled so that it's less confusing.

This is a major version release, so there are definitely going to be breaking changes as you prepare to upgrade. Most issues will probably arise around the switch to supporting a custom base page model. Third-party packages, in particular, will likely need some additional configuration to work with the new model structure. We've provided a guide for package maintainers to help them adapt their packages to the new structure.

For other things that will break, check out all of the deprecated features in the full release notes.

We are eager to hear whether we have provided everything that you might need in our new version of the REST API. If there is something missing or something not working quite right, please start a discussion or submit a feature request in our project repository. We'd love to hear more about your use cases for the API and how we can support them.