Django Fiber: a Django CMS kept alive in maintenance mode

Maintenance mode, not feature mode

Two facts define Django Fiber today. It is a Django CMS with a page tree in the admin, its own admin URLs, a REST API and bundled static assets. The second fact matters more for anyone evaluating it: the project states plainly that it is in maintenance mode. The README says it will be updated to run with the latest releases of Django and of the packages it depends on, and that no effort will be made to add new features. A well-written pull request that adds a feature can still be reviewed.

The history explains that posture. Ride The Pony, Leukeleu and Jouw Omgeving started the project in 2011 because they wanted a simple Django CMS, and later discovered Wagtail and found it better than their own creation. Control was handed to a new group of maintainers at the start of 2017, and the handover discussion sits in issue #244. The repository is not archived, and the last push was on 2026-10-12, so the code still moves. It moves only to keep pace with the frameworks underneath it.

Five dependencies and the versions actually resolved

Installation is the easy part, but the dependency list is where the real constraints live. The README names five packages installed automatically: Pillow for image work, django-mptt for the page hierarchy, django_compressor for asset bundling, djangorestframework for the API layer and easy-thumbnails for scaled images.

The dependency list in requirements.txt does not match that README list. Pillow is absent from it, while the other four carry higher floors than the README advertises: django-mptt>=0.13, django_compressor>=4.1, djangorestframework>=3.14 and easy-thumbnails>=2.7.2. setup.py reads install_requires straight from requirements.txt, so those floors are what pip resolves in practice. The README is describing a set of minimums from an older era, and a team pinning an environment against the README numbers alone will end up with a different tree than the one described.

Wiring fiber into a Django project

The package installs through pip, and the README frames the surrounding steps as the setup for a Django 1.9 to 2.0 project.

    $ pip install django-fiber

Next, settings.py needs four separate pieces. The first is the app registration, which pulls in the tree, compression and thumbnail packages alongside fiber itself:

   INSTALLED_APPS = (
        'mptt',
        'compressor',
        'easy_thumbnails',
        'fiber',
        ...
   )

The second is middleware, added to the Django 1.10 style list or to MIDDLEWARE_CLASSES on older versions:

    import django.conf.global_settings as DEFAULT_SETTINGS

    MIDDLEWARE_CLASSES = DEFAULT_SETTINGS.MIDDLEWARE_CLASSES + (
        'fiber.middleware.ObfuscateEmailAddressMiddleware',
        'fiber.middleware.AdminPageMiddleware',
        ...
    )

The third is the request context processor, without which templates cannot reach the current page:

    TEMPLATES = [
        {
            'OPTIONS': {
                'context_processors': [
                    'django.template.context_processors.request',
                    ...
                ]
            }
            ...
        },
    ]

The fourth is the compressor configuration, which points static collection at the project static folder and registers the compressor finder:

    BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))

    STATIC_ROOT = os.path.join(BASE_DIR, 'static')
    STATIC_URL = '/static/'
    STATICFILES_FINDERS = DEFAULT_SETTINGS.STATICFILES_FINDERS + [
        'compressor.finders.CompressorFinder',
    ]

urls.py then mounts the API, the Fiber admin and the page view in one pass:

    from django.urls import include, path, re_path
    from fiber.views import page

    urlpatterns = [
        ...
        path('api/v2/', include('fiber.rest_api.urls')),
        path('admin/fiber/', include('fiber.admin_urls')),
        ...
        re_path('', page),
    ]

Two commands finish the job. The first creates the database tables for the page tree and the content models:

    $ python manage.py migrate

The second links the bundled Fiber static files into the project static folder, and the README says it is needed when you are not on a development machine:

    $ python manage.py collectstatic --link

Further configuration detail lives in a separate documentation project on readthedocs.

A catch-all URL over an mptt tree

Two entries in that urls.py carry most of the behaviour. The first is re_path('', page), a catch-all that sends every unmatched request to the fiber.views.page view. Content lookup happens inside the CMS rather than through a declared route per page, so a site built this way does not need a urls.py entry for every new page an editor creates.

The second is path('admin/fiber/', include('fiber.admin_urls')), which mounts the Fiber admin under its own prefix rather than inside the Django admin. Editors land on a CMS-specific surface, and the Django admin keeps its own shape.

The page hierarchy itself comes from django-mptt, which is why 'mptt' has to sit in INSTALLED_APPS alongside fiber. The middleware list adds two entries from the fiber.middleware package, one named ObfuscateEmailAddressMiddleware and one named AdminPageMiddleware, so the package is expected to act on the request cycle rather than only serve pages. The README does not spell out what AdminPageMiddleware does beyond its name. The REST API sits behind path('api/v2/', include('fiber.rest_api.urls')), and djangorestframework in the dependency list is what backs it.

Where the project's own documentation runs out

Several gaps matter more than the feature freeze. The README install instructions assume Django 1.9 to 2.0, while setup.py lists classifiers for Django 3.2, 4.0 and 4.1 and sets python_requires to 3.6 or newer. The written guide lags the packaging metadata, so trust setup.py over the README when picking a Django version.

The repository has no GitHub releases, so there is no release page to anchor a version decision. CHANGELOG.rst is the only changelog pointer the project gives, and it is a link, not an excerpt.

Licensing is the other friction. setup.py declares license='Apache License, Version 2.0' and the classifiers call it OSI Approved Apache Software License, but the project is filed under a custom licence that GitHub cannot classify, and the repository holds LICENSE.rst rather than a plain Apache 2.0 file. The README does not document a rollback path, an upgrade command, or a way to move content between installs, which means an adopting team is writing its own upgrade plan. The homepage also still points at ridethepony.org, the studio that started the project.

Why the original maintainers moved to Wagtail

The clearest available comparison is the one the project makes about itself. The original authors discovered Wagtail, found it better than their own creation, and handed Django Fiber to new maintainers in early 2017.

The two approaches differ in where the editing experience comes from. Django Fiber ships its own admin under admin/fiber/, its own API under api/v2/, its own hierarchy built on django-mptt, and its own templates and static files that must be collected into the host project static folder. A separate project can keep page editing, its admin and its own models inside its own codebase, leaving the host project to supply templates and URLs. The cost of that separation is an extra dependency and a second opinion on structure; the benefit is a structure the maintainers judged better for the long term.

The trade-off is direct. Django Fiber gives a host project a working CMS with one package and one catch-all URL, at the cost of a frozen feature set and a dependency chain that someone else maintains in place. In the maintainers' own judgement, Wagtail was the better answer to the same problem.

Editorial conclusion

Django Fiber fits teams with an existing Django codebase that want editable pages behind a single catch-all URL without pulling in a separate content platform, and who are comfortable freezing features and owning their own upgrades. It is the wrong choice for a team that needs new CMS capabilities, a public release history, or a clearly classified licence, and the maintainers themselves point to Wagtail for that reason. Before adopting, check LICENSE.rst against your own compliance rules, run python manage.py migrate against a copy of your database, and read CHANGELOG.rst for the Django version you plan to deploy, because the README install instructions still target Django 1.9-2.0 while setup.py lists Django 3.2, 4.0 and 4.1.

Frequently asked questions

Official sources

1. django-fiber/django-fiber on GitHub
2. Issues
3. Project website
4. README