django-wiki keeps its optional features out of core and its data model stable

A wiki as Django models inside an existing site

django-wiki describes itself as a wiki system with complex functionality for simple integration, and the integration is the point. It is not a standalone wiki application with its own user table and its own login page; it is a set of Django models and views that mount inside a Django project and inherit that project's authentication, sessions and URL space.

The design principles are stated in the README as a manifesto, and they read as constraints rather than slogans. Be pluggable and lightweight: optional features do not go into core. Be open: there is an extension API intended to let the ecosystem grow in a structured way, with MediaWiki cited as the example of what a mature plugin ecosystem looks like, given that Wikipedia's extension count is cited as over 1100. Be simple, in the sense of understanding the schema decisions other wiki projects made before making your own.

The audience follows from that. It is a developer who already runs Django, wants a wiki for internal documentation or a community section, and is willing to learn enough Django to customize templates. It is not aimed at someone who wants to run a wiki by pointing a browser at a site.

Django 4.2 through 6.0 on Python 3.10, packaged as wiki

The distribution name is the first thing that trips people up. On PyPi the package is `wiki`, not `django-wiki`, and the README states that the latest version is maintained through PyPi under that name using SemVer versioning.

The supported matrix is a table rather than a loose claim. The current 0.13.x line supports Django 4.2, 5.0, 5.1 and 6.0, and upgrades from 0.10, 0.11 or 0.12. The 0.12.x line covers Django 4.0 through 5.2. Older lines are listed all the way back, with 0.10.x spanning Django 2.2 through 4.1 and the earliest 0.1.x requiring Django 1.5, 1.6 or 1.7. That long table is itself information about the project: it tracks Django's own release history and shows a project willing to keep supporting old lines rather than declaring them dead.

The packaging metadata says `requires-python = ">=3.10"`, and the classifier list names CPython and PyPy, with Python 3.9 through 3.13 listed. The build backend is hatchling with hatch-build-scripts, and the pinned dependencies are explicit about intent: Django is capped at `>=4.2,<6.1` with a comment that Django version support is added one minor release at a time, bleach is held loosely at `>=6,<7` because it has been stable, and Pillow is unpinned because it is used very little and has never broken.

Those three comments are worth more than the version numbers. They tell you what actually causes breakage during a Django upgrade.

Override templates, not the repository: the fork warning in the README

The README has a section on what to customize and what can break, and it is unusually blunt. The simplest customization is overriding templates and writing your own template tags. The instruction against making a hard copy of the repository to fiddle with internal parts is explicit, because that strategy leads you to lose future updates with improved features, plugins and security fixes.

Theming has its own answer. You can override the whole Bootstrap theming, but the current advice is that you are best off maintaining your own Bootstrap SCSS and hard-copying it, then overriding django-wiki's rules. That is a real cost and the README does not hide it: a hard copy is precisely what it warned against one paragraph earlier, but scoped to a stylesheet rather than to Python code.

On views, the README says all Python views are class-based, and then advises against overriding views and URLs as a starting point, since most customization should be achievable through plugins, templates and SCSS. The plugin API is described as pretty stable in the stability notes, alongside a model API that has been very stable and is subject only to smaller changes.

The stability section also makes two promises worth quoting precisely: there will not be changes expected to cause data loss without a proper upgrade path, and the project describes itself as always a work in progress.

13 translated languages and a Transifex workflow open to non-programmers

Localization is treated as a contribution category that does not require programming. django-wiki is fully translated into 13 languages apart from the default English, with more underway, and the README says adding a language is very easy and that you do not need to be a programmer. The workflow lives on Transifex at the django-wiki project page.

The README breaks down the states a language can be in, which is a candid list: some need only a small push because they are almost fully complete, some were initiated and need a coordinator to carry them on, and some do not exist yet, where you can request them and become the coordinator. The `.tx/` directory at the repository root is the Transifex client configuration.

For an organization deploying django-wiki internally in a language outside that set, this is the practical gap. There is no documentation in the README for running your own translation, so a non-English deployment depends on Transifex or on a fork.

The rest of the community surface is traditional rather than modern: GitHub discussions, an IRC channel on libera.chat, a Google group, and accounts on Mastodon and Twitter. The README asks people not to email developers for personal support.

A live demo of main, with admin/admin credentials

There is a demo running the latest main branch at demo.django-wiki.org, and it is set up so you can see the notification system without registering: an existing account is available with the user `admin` and the password `admin`, though signing up is also possible.

That convenience is worth reading as a trade-off. Evaluating a wiki engine is mostly an interface question, and no screenshot answers it the way a real instance does, so publishing one is sensible. But a demo on main runs the unreleased main branch, so anything you judge there is a preview rather than what a PyPi install gives you.

The distinction matters when you are deciding between this and another engine. Check the current release line in the support table, then judge the demo for interface questions and the release notes for behaviour questions. The README points upgrade instructions at the release notes in the documentation, and the repository keeps `CHANGELOG.md` alongside a `docs/` directory that holds the developer guide.

GPL-3.0, an 0.x version line, and a release about two months old

The licence is GPL-3.0, declared in `pyproject.toml` and matched by the `COPYING` file at the repository root. For software that ships as a Python package inside someone else's Django application, that is the first question to answer, and it is not a technical one. Read `COPYING` and decide for yourself how it applies to your distribution.

Versioning follows SemVer while still sitting below 1.0, which means minor bumps can carry breaking changes by convention even though the README promises an upgrade path for anything affecting data. The recent tags show a real rhythm: 0.12 on 2025-05-01, 0.12.2 on 2025-10-13, and 0.13 on 2026-07-31.

The last push was on 2026-09-08 and the repository is not archived, so the project is being worked on, but the gap between the 0.13 release on 2026-07-31 and that push means the release line and the development line are not the same thing. If you deploy, pin the version rather than tracking main.

The repository layout is conventional: `src/` for the package, `tests/` for the suite, `testproject/` for a runnable sample project, `docs/` for documentation, `.circleci/` for CI, and a `.pre-commit-config.yaml` for formatting. Coverage is tracked through Codecov. The author is Benjamin Bach, with Oscar Cortez as a maintainer.

When a different engine is the better choice

Three cases stand out.

If you do not run Django, django-wiki is the wrong shape. It needs a Django project, a URL configuration entry and the project's settings; there is no standalone server to start. Someone who wants a wiki in an afternoon is better served by a flat-file engine that runs from a directory.

If you need MediaWiki-grade plugin compatibility, the analogy in the README points the other way. The MediaWiki figure cited is over 1100 extensions, which is presented as a target rather than a current state. A wiki whose content depends on hundreds of established plugins is not going to find them here.

If you need a modern default theme with no SCSS work, expect to do it yourself. The documented route is to maintain your own Bootstrap SCSS, hard-copy it and override django-wiki's rules. That is an ongoing maintenance commitment tied to Bootstrap versions, and it is the part of adoption most likely to be underestimated.

The realistic alternative is writing the content model yourself inside your existing Django project, which you should consider if the wiki is one section of a larger application and the plugin ecosystem is not what you are buying. django-wiki makes sense when the wiki is a substantial part of the product, because that is when the plugin API and the upgrade path start paying for themselves.

Editorial conclusion

django-wiki fits a Django project that already exists, where a wiki should share the site's users, sessions and styling rather than sit beside it as a separate application, and where GPL-3.0 is compatible with what you distribute. It does not fit a team that wants zero integration effort or a stable theme layer, because customizing means overriding templates and maintaining your own Bootstrap SCSS by hand. Before choosing it, read the release notes for the upgrade path from your current line, confirm your Django version is covered by the support table, and check that the plugins you depend on are on the extension API rather than on internal code you would have to fork.

Frequently asked questions

Official sources

1. django-wiki/django-wiki on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases