Puput gives a Wagtail site a WordPress style blog without rebuilding the admin

Puput is a Wagtail page type, not a separate CMS

The architectural choice is what makes Puput different from a Django blog package that ships its own admin. Puput uses Wagtail CMS as its content management system, which means the editing experience for blog entries is Wagtail's, including the page tree, the preview mechanism and the moderation workflow that comes with it. The README describes Puput as a Django app to manage a blog, inspired by Wordpress and Zinnia, and the people it serves are teams that have already chosen Wagtail for the rest of their site. For them, a blog is another content type rather than a separate application with a separate login, and that shared admin is the reason to use Puput instead of a standalone blog engine. The cost of that choice is that the whole feature set of a blog has to be rebuilt out of Wagtail primitives, which is what the feature list is a catalogue of.

Entries are organised by author, tag, category, archive and search

The navigation model is where a blog application either works or feels like a thin veneer over a page tree, and Puput is explicit about it. Entries can be listed by author, by tags, by categories, by archive, and by search term, and there are also last entries and popular entries listings. That is a taxonomy surface rather than a single chronological list, and it is the part most likely to matter for a publication with several authors. Two related features sit alongside it. Related entries give each post a set of neighbours, and configurable sidebar widgets let a site add blocks of its own to the blog layout. On the reading side the project ships a simple, responsive HTML template by default, and the default template colour is configurable. The theme is deliberately plain, since the point of the project is the content structure rather than a design, and a site that wants a different look replaces the template.

SEO friendly urls, RSS feeds, comments and social sharing

The publishing plumbing is present and mostly uncontroversial. Entries get SEO friendly urls, RSS feeds are generated, Disqus comments are supported, and entries can be shared on Facebook, Twitter and LinkedIn. Markdown fields are supported through the wagtail-markdown package, so an editor can write a post body in markdown rather than rich text. The entry model is extensible, which is the other line in the feature list that deserves a note, since it means a site can add its own fields to the entry model rather than working around Puput's fixed structure. A blog application that cannot be extended tends to be abandoned the first time the editorial team needs a field the app does not have, so extensibility is a structural property rather than a convenience here.

The dependency set is pinned harder than a modern Django app would be

Puput is distributed on PyPI and the packaging is visible in setup.py, which is also where the version numbers live: the version and author metadata are read out of the package's __init__.py rather than hardcoded. The install_requires list is where the compatibility story is written, and it is written with exact pins for three of the four dependencies.

    install_requires=[
        'wagtail>=5.2,<7.0',
        'django-el-pagination==4.0.0',
        'django-taggit>=5.0,<6.2',
        'wagtail-markdown==0.11.1'
    ],

The Wagtail range runs from 5.2 up to but not including 7.0, so the app is written against Wagtail 5 and Wagtail 6, and the classifiers list Django 4.2 and Django 5.0 alongside Python 3.8 through 3.11. The exact pins on django-el-pagination, django-taggit and wagtail-markdown are the part that will cause friction in an existing project, because a site that already depends on a newer django-taggit has to either downgrade it or vendor a patched Puput. django-el-pagination is the dependency that supplies the pagination on the entry lists, and wagtail-markdown is what makes the markdown fields work, so neither is optional in practice.

Where the documentation lives and what it covers

The repository is thin on prose by design. The README is a feature list, a link to the documentation, a list of example sites and a list of related repositories, and the setup process is explicitly explained elsewhere, at the puput.readthedocs.io setup page. The top level of the tree shows the shape of a conventional Python package: a puput directory holding the application, a docs directory, a tests directory, a setup.py, a tox.ini, a requirements-test.txt for test dependencies, a MANIFEST.in, a CHANGELOG.md and an AUTHORS file. The presence of tox.ini and a separate test requirements file tells you the project expects multi-version testing to be runnable, which is also the tool you would use to check that your own Wagtail version still works with it. The readthedocs.yaml file at the top level points the documentation build at the same hosted docs, and the PyPI and Read the Docs badges at the top of the README are the version indicators most users will rely on.

Migration from Wordpress, Blogger and Zinnia is handled by sibling projects

Puput is a package with a history, and the README lists the related repositories that make it practical to adopt on an existing site. There is wordpress-to-puput to import Wordpress blog data, blogger-to-puput for Blogger, and zinnia-to-puput for Zinnia, each an APSL project. Two more matter operationally rather than historically. docker-puput is a Docker image for a Puput blog, which is the shortest path to a running instance for evaluation. puput-demo is an example of a blog Django app using Puput, so you can read a complete configuration instead of assembling one from the documentation. And divio-wagtail-puput is a Divio Cloud addon to install the Wagtail Puput weblog, which tells you something about where the project is used. The list of example sites in the README gives a sense of the same point from the other side: Open Study Room, APSL, Nautic Advisor, Trespams, Body Therapy, Astro and IP/DE all run a blog built this way.

Where Puput is the wrong choice

The first case is a greenfield project without Wagtail. Puput assumes the CMS is already running, so a team starting from an empty Django project would have to adopt Wagtail and then Puput, when a purpose-built blog app for plain Django would be the smaller step. The second case is a site that needs a current Wagtail, since the upper bound of 7.0 means a project moving to a newer Wagtail line has to wait for a release or carry a fork. The third case is a project with a content model that does not fit a blog entry, because Puput's extensibility extends the entry model rather than replacing the model system, and a site whose real content is a product catalogue or a job listing is better served by building those types directly in Wagtail. The fourth is editorial workflow at scale, since the feature list says nothing about moderation queues, scheduled publishing or multi-site support, and the documentation gives no answer, so a publication expecting those features would have to verify them against a running instance before committing.

Editorial conclusion

Teams already running Wagtail who want a blog with entries organised by author, tag, category and archive, plus RSS and comment support, are the people Puput is for, and installing it into an existing Wagtail project is far less work than building the same views yourself. It is the wrong choice for a team starting from nothing, since the value of Puput is precisely that it assumes Wagtail is already there, and it is a poor fit for a project that needs a current Wagtail, because the package pins wagtail to a range from 5.2 up to but not including 7.0. Check three things before you adopt it: that your Wagtail version falls inside that range, that the pinned versions of django-el-pagination, django-taggit and wagtail-markdown are acceptable in your dependency set, and that the last push on 2026-04-13 leaves you comfortable with a package that has had no commit in six months. The licence is MIT, the newest release is 2.2.0 from 2025-04-07, and the setup documentation lives at puput.readthedocs.io rather than in the repository.

Frequently asked questions

Official sources

1. APSL/puput on GitHub
2. Issues
3. License: MIT
4. README
5. Releases