Matthias Kestenholz: Posts about Django

Weeknotes (2026 week 40)

2026-09-30T12:00:00Z

Weeknotes (2026 week 40)

I have been at Django on the Med 🏖️ and already wrote a lengthy post about that.

I did a lot of work on a DEP for adding import map support to Django which is currently also being discussed on the forum. Apart from that I’m not going to repeat anything from the post linked above, so check it out if you want to know more.

Motivated by a discussion I had at the sprint I also improved my release process. I now have a make-release script in my dotfiles which updates the CHANGELOG with the version, bumps the version itself in the repo and commits and tags the release. The rest is handled by trusted publishing. I’m now finally also properly handling patch releases so that you don’t have to check the history to know what’s in a patch release. I already did that for minor and major version bumps, but was a bit too lazy. Now I can be even lazier and still more correct, and it feels great.

Next, I refactored the static site generator script for this blog to be much faster. I now do not have to wait when saving before refreshing the browser. Much nicer.

Releases from the last three weeks

django-js-asset

django-js-asset 5.0a1 implements the API proposed in the DEP. This is an alpha release because the DEP is still being discussed and I don’t want to break people’s code again and again if, during discussion, it appears that the API should be different.

django-json-schema-editor, django-prose-editor and django-content-editor

The three alpha releases django-json-schema-editor 0.15a1, django-prose-editor 0.28a2 and django-content-editor 9.1a1 depend on django-js-asset 5.0a1 mentioned above and implement the necessary changes for the new import map definition style.

django-authlib

django-authlib 0.20 adds support for specifying the tenant when using Microsoft Entra ID.

feincms3-downloads

feincms3-downloads 0.6 includes translation fixes, uses different error codes when pdftocairo or convert are missing, and changed the PATH environment variable handling to be less annoying for local development.

Looking back at Django on the Med 🏖️ 2026

2026-09-28T12:00:00Z

Looking back at Django on the Med 🏖️ 2026

I haven’t been to a programming conference in a really long time. That was mostly due to laziness, wanting to stay at home and decision fatigue because I didn’t know how to travel sustainably and didn’t know where to stay during the conference.

I had been talking online to Carlton for some time and when Django on the Med 🏖️ 2026 was announced I knew I had to go. What’s not to like about a conference in Italy with all the good food and the Mediterranean Sea? I managed to overcome my inner Schweinehund (the German term for the lazy voice in your head that tells you to stay on the couch) and reserved both the (free) ticket for the conference itself and also the train ticket to go from Zurich to Pescara. The train takes 8 or 9 hours depending on the connection with a single change in Milano.

The conference itself consists only of development sprints and socialising – no talks and nothing to prepare in advance for participants, except taking the computer with you and optionally having some ideas about what you want to work on.

The import map Django Enhancement Proposal (DEP) I worked on

The forum discussion about rejuvenating Django’s forms.Media sparked my interest in reviving Thibaud’s DEP draft in early 2025. Some features which were mentioned in the early draft, such as a Stylesheet object for including additional stylesheet attributes in class Media and CSP support, have been added to Django 6.1 in the meantime. My main motivation was and still is to bring import map support to Django. I changed django-prose-editor to use import maps back then and wrote a first draft but then got stuck while trying to write a good DEP.

For those who don’t know import maps: ES modules import each other by URL. When static file storages add hashes to file names for cache busting, those URLs change on every deployment. Import maps solve this using a web standard: Modules import stable identifiers such as my-library, and the import map tells the browser which file to actually load.

If all browsers were to support multiple import maps, the DEP would maybe not be necessary. People could just ship an ImportMap media object and include it in forms.Media(js=[...]) before the ES modules actually using it and things would just work. At the time of writing this post Chromium and Safari support multiple import maps but Firefox still doesn’t. So, if we want to use this feature without having import map merging we will have to wait several years for browser support to be widespread enough. And since third-party Django apps and Django websites which want to use import maps have to agree on a common implementation it makes most sense to me to propose adding this to Django core. The proposal lives in the DEP pull request and the accompanying new feature ticket.

As an aside: Django has been famous for not having a frontend story for the longest time. I think this is mostly a strength, because Django has therefore allowed everyone to use the frontend technologies they want and hasn’t decided on a particular technology, library or framework which, in the meantime, would have become obsolete or not really state of the art. ES modules and import maps aren’t opinionated in the same way that, for example, jQuery, htmx, React or Svelte are; they really are a basic implementation of modules, namespaces and a specification of how those modules should be loaded in the browser. So, I don’t think it would be fair to reject adding better support for these things on the grounds that Django wants to be agnostic to the frontend. I’m not saying here that the DEP has to be accepted or that there cannot be good reasons to reject or modify it further – I’m sure there are. I’m just proposing that we cannot just use the old arguments to argue against it.

The diary

Enough about the DEP. Now I am going to recap the last few days. I’m not adding any pictures to this post, but you can head over to Mastodon and check out the #DjangoOnTheMed tag, for example here on hachyderm.io.

Tuesday

On Tuesday morning I left home to take the train towards Pescara. I was really glad I packed my headphones with noise cancelation. After about 9 hours I arrived in the late afternoon, checked into the hotel, took my swimming trunks and immediately went to the beach.

In the evening we had dinner at the seaside at Lido Aurora Pescara. It was a pleasure to finally meet some of the people I have been either working with or just following for a long time. A special surprise was meeting Simon again. We met at Django Under the Hood in Amsterdam in 2016 and he helped get my first pull request¹ to Django off the ground back then.

During the course of the conference we went back there several times. Good food, and luckily not just options with fish and seafood, but also good vegetarian options. (I’m not strictly vegetarian, but I sometimes prefer vegetarian or even vegan food.)

After a long day I slept surprisingly well. That’s not saying much, but it certainly was a welcome surprise given my issues with my back and hips.

Wednesday

The sprint officially started on Wednesday with a warm-up session. The three questions asked (paraphrased because I don’t remember the exact wording) were “What is great about Django?”, “What are the risks, or what could be better?” and “What are you planning to work on?”

I discussed ways of adding import maps with Joe, the author of django-esm and esimport. I thought we had completely different and conflicting ways of thinking about and using import maps. After talking it over it became clear quite quickly that, while we don’t have to use them the same way, our ways of using them do not have to be in conflict. I think this is one of the big advantages of events like this: The same discussion would have taken weeks or months in an issue tracker, if it ever happened, and in person it was a question of sitting together for an hour, hashing it out, and then you potentially have a basic agreement and an idea for which direction to go.

As already alluded to above I restarted my work on the DEP. It basically needed a complete rewrite since (excitingly!) so much has already landed in Django in the last ~18 months.

We went back to Lido Aurora for lunch. In the afternoon, almost everyone went for a bike ride along an old railway track which has been converted into a bike lane along the sea. I already knew a similar thing from Liguria near Levanto/Bonassola but it was nice encountering the same idea near Pescara. (The new railway track has been built further inland.) We also had some nice Spritz abruzzese. Generally, Spritz isn’t really my thing but those were a bit more bitter and earthy and less sweet and therefore we soon ordered a second round.

In the evening a small group went to Flower Burger for some vegan food. As expected it was really tasty. While vegan options in restaurants can unfortunately sometimes be quite bland, vegan restaurants in my experience are often some of the best: You really have to know your ingredients and can’t just add bacon to everything. (Nothing against bacon, but still.)

Thursday

Again I started the day with a great coffee and an overly sweet breakfast (for my taste). Italian food is generally great but the breakfast isn’t my thing. I like my müesli and whole grain bread. Anyway!

I continued working on the DEP and started tweaking django-js-asset to serve as a proving ground for the ideas. Towards the end of Thursday’s sprint I had a first rough draft ready and Joe provided some great feedback on it. One of the most important points for me was to care about the API and not the implementation at this stage in the process. The DEP draft contained too much detail related to implementation and not enough examples showing off more complex use cases.

I only ate a small lunch since we were promised a bus tour with a lot of great food in the afternoon and evening. It still proved to be too much as we would learn later.

In the afternoon we took a bus to a local vineyard. We were shown around and had a look at the machines and learned a few things about the winemaking process. That was followed by a wine tasting and some bread and antipasti.

Next, we went to Penne and were shown the city and were told a little bit of the local history. Everything’s built from bricks. Brick buildings and earthquakes are not a great fit it seems to me – the last larger earthquake hit the region less than 10 years ago. It’s interesting that people are always rebuilding the houses anyway. From Penne we had a really nice view over the region, from the hill we were standing on all the way to Pescara and to the Adriatic.

We took the bus again to the restaurant and ate until 11 in the evening. At a certain point I couldn’t go on anymore. No matter how great the food, there comes a moment when eating more seems impossible, and in my case that moment came before i secondi. The secondi were arrosticini. I could only eat one so now I’m wondering if I am a persona non grata in Pescara 🤣. Also, I was in pain from too much sitting – sitting isn’t good since I’m still recovering from a herniated disc and the associated follow-up issues in the hip. Still, I had a great day and wouldn’t have wanted to miss any of it.

Back in the hotel I couldn’t sleep immediately so I addressed some of the feedback I got earlier in the day and then went to sleep.

Friday

The night wasn’t very restorative but I was awake anyway in the morning so I got up and started the day again on time. I finished applying the feedback to the DEP and to django-js-asset and continued refining them and filling in holes. I also modified some of the packages I’m developing to use the new way of defining media using import maps just to get a feeling for whether the API is nice or not.

During the coffee break I asked around if the changes to the way import maps are defined would break existing code. Luckily it seems that django-prose-editor is “just used” and people weren’t relying on being able to define import maps themselves yet. Or, if so, I don’t know about it. Maybe django-probe could help with that, but we obviously aren’t there yet.

We finished the sprint with a group picture and closed off the official part. Most of us went out for lunch together. Some people had to leave after that; I drank an espresso in a nice coffee bar, said goodbye to them and went to the beach afterwards.

In the evening we went to the excellent Sesamo Nero restaurant. I was happy that I wasn’t the only one who was surprised to learn that the restaurant wasn’t that close after all and arrived a little bit later than expected.

Saturday

Almost everybody had either left or had to leave on Saturday morning so I didn’t expect to meet with others anymore. I finally went for some long walks, explored other parts of the town and went to see the long bridge/walkway/passeggiata/whatever and some parks. I also took some time to note down both what we did and what I thought of finally going back to a conference.

In the evening I ran into Mark and Becky twice and we decided to have a beer together before saying goodbye again and for the final time for this sprint.

Having an additional day there was a win. I had less time during the sprints to visit the city itself and really did appreciate the extra day I allowed myself.

Sunday

I ate breakfast, went for a short walk around the city and to the beach and then took the train back home. Up to Milano it was uneventful. The train from Milano to Zurich was cancelled, but I didn’t lose more than half an hour in the end.

Finally

I’m wondering about the DEP process now and what happens with the pull request I submitted. I’m linking to the new feature ticket, the DEP pull request and what I consider to be the proving ground again. Because django-js-asset has to stay backwards compatible, an implementation in Django itself could be quite a bit simpler.

I will be in Liguria, Italy again in just one week. Feels a bit stupid to cross the Alps only to cross them again a few days later, but I’m really looking forward to sleeping in my own bed for a few days.

I can very well imagine going to more conferences and sprints again. The value of meeting in person is unquestionable. It might be hard though to improve on the experience we had here with the location, the nice weather and the social events. The selection of events is large and I certainly won’t be going to all of them, but I am looking at going to the next Django on the Med in Malta, and maybe also to PyCon Italia and/or DjangoCon EU. We will see!

I had been contributing bug reports, tests and help much earlier than that but I was somewhat intimidated by Django’s processes. ↩

Weeknotes (2026 week 37)

2026-09-09T12:00:00Z

Weeknotes (2026 week 37)

Tonight the temperature will drop to 10°C. I like it when it’s hot, but now I really enjoy the slightly cooler temperatures in Europe. The last post was written in the middle of the heat wave. Yesterday we still had temperatures of over 30°C, which is a lot for September. But it will be the new normal. Next year probably won’t be cooler.

Releases from the last four weeks

Lots of activity!

django-authlib

django-authlib 0.19 hardens the OAuth2 implementation a bit against replay attacks, provides utilities for removing password logins from the Django administration interface, and removes some of the confusion around role-based permissions. Upgrading is recommended.

django-content-editor

django-content-editor 9.0.2 fixes a bug in the function which allows cloning plugins from other regions. The bug was most visible when using something like django-json-schema-editor’s plugins which are only proxy models. Their type was lost because I was using _base_manager, which didn’t do the downcasting properly. (Sorry for the word salad.)

django-tree-queries

django-tree-queries 0.26.1 now uses annotations instead of .extra() to add the tree_path and tree_depth fields. This is great because the ORM knows these fields properly and we can now use e.g. .filter(tree_depth=1) instead of .extra(where=["..."]).

This change was mainly motivated by the renewed interest in deprecating .extra() at some unknown future point in time.

django-debug-toolbar 8.0 ships a new design! I again didn’t contribute a lot, but I’m very proud that we were able to ship this as a team.

feincms3

feincms3 6.0.2 ships new utilities and, most importantly, fixes crashes when passing %00 to the root middleware. Using null bytes when comparing text field values on PostgreSQL leads to crashes. These are mostly an annoyance without data exposure, but definitely worth fixing.

The reason for the major version bump is that we finally dropped support for Django 3.2. That’s the only breaking change, so upgrading should be easy for everyone.

django-js-asset

django-js-asset 4.1 fixes issues around lazy CSP nonce handling as well as the same issue Django itself had around rendering HTML-safe strings.

django-prose-editor

django-prose-editor 0.27.2 adds a default menu item for the code block extension and updates ProseMirror and Tiptap. It also adapts to the changed CSS of the Django 6.1 administration interface.

django-json-schema-editor

django-json-schema-editor 0.14.1 includes a fix for saving JSON schema fields when the schema doesn’t contain any properties, plus fixes for the Django 6.1 admin CSS.

django-admin-ordering

django-admin-ordering 0.21 now activates orderables properly when the same model was orderable both in the change list and in the change form. I developed the fix for this in early 2025 but never released it. It’s what happens.

feincms3-cookiecontrol

feincms3-cookiecontrol 1.7.2 includes bugfixes for edge cases while bringing down the byte count for the cookie banner and media embedding script from 3961 (in 1.7.1) to 3909 bytes.

feincms3-data

feincms3-data 0.11.1 brings fixes for handling unique fields when the same unique value is removed and then re-added with a different primary key.

django-translated-fields

django-translated-fields 0.14 contains no relevant code changes to the module itself at all. It was just time to release a new version more than two years after the last release to show that the project is still active and update the Trove classifiers.

Weeknotes (2026 week 33)

2026-08-12T12:00:00Z

Weeknotes (2026 week 33)

Holidays and the heat wave

I had four weeks of holidays this summer. The timing couldn’t have been much better with the heat wave – doing much thinking seems to be impossible anyway. I organized a multi-day feast with a few friends and with much help from others. We built up the site and installations over the course of multiple days and spent some days tearing most of it down afterwards. I started back to the office job physically tired but mentally rested. That’s good. I’m really looking forward to seeing the pictures people took.

What’s less good is that we’re living through the projections which climate scientists warned us about decades ago. Or worse, even, since Switzerland is one of the regions where the temperature increased more than the global average. The member of Switzerland’s Federal Council heading the Federal Department of the Environment, Transport, Energy and Communications reportedly said that he didn’t expect such intense heat. Of course, it was reported earlier in the same week that the same member was responsible for removing funding for a more resilient forest from the budget for the next fiscal year. This is unfortunately to be expected: he has long been connected to the fossil energy industry. After all, he was also the president of Swissoil and Auto Schweiz. It’s really frustrating. None of this is news to climate scientists, and it hasn’t been news here either – these posts start in 2005, back when I was studying environmental sciences at ETH with a focus on atmospheric physics.

Scripts for auto-merging dependabot and pre-commit pull requests

I let Claude write some scripts for automatically merging pull requests created by various bots, see here. The script finds pull requests created by a predefined list of bots in a defined list of accounts (organizations or users) and squash-merges them if the CI run is green and there are no conflicts. It’s a dry run by default; --apply is required to actually merge anything. It doesn’t look at reviews and doesn’t care whether a bump is major or minor – I’m relying on the test suites for that.

The ruff 0.16 update was a bit painful because ruff now enables 413 rules by default, up from 59. Recurring themes were warnings about mutable class variables (which are common when using Django), blind except clauses and underspecified dates without time zones, but none of them in scenarios where they actually hurt.

So, instead of just running the merge script, I had to fix up dozens of pyproject.toml files and projects. Oh well, next time will be smooth again.

Releases

Since I’ve been away from the computer for so long, the list of releases from the start of July onwards is quite short.

django-authlib

django-authlib 0.18 now also supports Microsoft Entra ID logins. The admin integration also has support for Microsoft accounts, not just for Google.

django-content-editor

The django-content-editor 9.0.1 just contains a small fix which avoids submitting the form that allows cloning content between regions when cancelling the dialog.

Migrating from FeinCMS to feincms3

2026-07-18T12:00:00Z

Migrating from FeinCMS to feincms3

FeinCMS is still actively maintained, but development, bugfixes and new features mostly land on feincms3 and django-content-editor these days, not on FeinCMS itself. That’s reason enough to eventually move a project over.

Someone asked on the feincms3 issue tracker whether there’s a guide for making that move. There isn’t one yet, so I thought I’d expand on my comment in the issue tracker and post it here too in the hope that it’s useful to others. The post is based on a gradual migration we did in a large, long-lived Django project – a textbook publishing platform with years of content. Unfortunately I can’t show more details since it’s a commercial, closed source project. During the migration, the platform stayed in production the whole time, aside from the inevitable bug here and there.

The most important insight is that FeinCMS 1 content types and feincms3 plugins are close enough that we could keep using the same underlying database tables. An export/import step isn’t required at all.

The overall shape of the migration

FeinCMS keeps managing the plugin tables as usual, for now.
New feincms3 plugin models get added alongside the old ones, with managed = False in their Meta and db_table pointing at the exact table FeinCMS already created. Django doesn’t think these are new or different tables, it just uses the ones that already exist.
The admin gets migrated from ItemEditor to django-content-editor’s ContentEditor. If your project has more than one independent hierarchy (in our case, one per book series instead of a single global page tree) you can migrate them independently instead of having to do it all in one step.
Rendering moves over from FeinCMS’s rendering machinery to feincms3’s, again piece by piece: the HTML generation for the frontend, any full text search indexers, anything else that touches the content.

The examples below use Chapter and ChapterPlugin because that’s the hierarchy in this particular project, one tree per book series rather than one global page tree. Most feincms3 projects center on a single Page model instead, so read Page wherever you see Chapter; the rest still applies.

Getting the migration state right

Here’s a concrete proxy model from that migration, simplified. RichTextContent is our own abstract mixin, holding nothing but the actual text field, shared between the FeinCMS and feincms3 sides of the code base. The same role is played by feincms3.plugins.richtext.RichText if you use feincms3’s bundled plugin instead of your own. ChapterPlugin in turn only wires up the boilerplate that’s specific to being a plugin content type of our Chapter model:

class RichTextContent(models.Model):
    text = RichTextField()

    class Meta:
        abstract = True

class RichText(ChapterPlugin, RichTextContent):
    class Meta:
        db_table = "textbooks_chapter_richtextcontent"
        managed = False  # Proxy for the real model still owned by FeinCMS

The exact table name depends on how FeinCMS auto-generated it for your project (a mix of the app label, the base model and the content type name), so look it up rather than guessing. ./manage.py sqlmigrate or just inspecting the database will tell you.

For the very last step, once a plugin has been converted and managed = False can go away, use Django’s migrations.SeparateDatabaseAndState. It lets you change the migration state without touching the database at all. That’s exactly what you need here since the table already exists and already has the right shape; only Django’s idea of what the schema is needs to catch up.

You don’t even have to write these migrations by hand. Remove managed = False, run ./manage.py makemigrations as usual, and Django writes out the normal operations it would generate for any new model. The only manual step is moving that generated list of operations into the state_operations argument of a single SeparateDatabaseAndState operation, redacted and shortened here:

class Migration(migrations.Migration):
    dependencies = [
        ("textbooks", "0096_remove_richtextcontent_managed"),
    ]

    operations = [
        migrations.SeparateDatabaseAndState(
            state_operations=[
                migrations.CreateModel(
                    name="RichText",
                    fields=[
                        ("id", models.AutoField(primary_key=True, serialize=False)),
                        ("text", models.TextField()),
                        ("chapter", models.ForeignKey(to="textbooks.Chapter", ...)),
                    ],
                    options={"db_table": "textbooks_chapter_richtextcontent"},
                ),
            ],
            # No database_operations -- the table is already exactly like this.
        ),
    ]

As always, test this on a copy of the database first and make sure you have backups. Hand-editing migrations isn’t generally recommended, but it’s safe if you know exactly what you’re doing. Treat it with the same care as any other schema change.

The page tree: mptt vs. tree-queries

FeinCMS 1’s bundled Page model uses django-mptt for the page hierarchy, while feincms3’s page comes with django-tree-queries instead. If you’re using FeinCMS’s own Page model and migrating to feincms3’s, this can be a little bit painful since the database schema is different. There’s a dedicated guide for migrating from django-mptt in the django-tree-queries documentation.

Once the last plugin has switched over, FeinCMS can be dropped from the project entirely, including from the requirements. The models end up exactly where they would have been if you’d started the project with feincms3 in the first place – and you never had to export or import a single row to get there.

Weeknotes (2026 week 27)

2026-07-01T12:00:00Z

Weeknotes (2026 week 27)

The last entry in this series was published 10 weeks ago so it really is time for another review of the releases I did during this time.

Releases

feincms3-forms

The feincms3-forms forms builder has gained a documentation page on the wonderful Read the Docs service. The 0.6.1 release doesn’t contain any code changes, just pyproject.toml updates and the mentioned documentation rework.

django-imagefield

django-imagefield 0.23 is still in alpha. The handling of image fields when using libvips is optimized to use less memory hopefully. We’ll see. I also added some tests to verify that .mpo files are handled properly.

feincms3

The Vimeo embed now always sets the dnt=1 parameter on the <iframe>, which asks Vimeo to not track the user.

django-mptt

I wrote about the somewhat annoying maintenance again. The library is still officially unmaintained, but I did a lot of work either just closing issues or also fixing them. The docs also contain many clarifications. I only released 0.19rc1 for now.

feincms3-sites and feincms3-language-sites

Last time I mentioned that default HTTP/S ports are now stripped so that the host matching can determine the correct site. Now a new case appeared where trailing dots weren’t stripped. The normalization of hosts has been extended. I’m sure we’re still missing some exotic cases where we should do more normalization, but we’ll cross that bridge when we get there.

django-prose-editor and django-js-asset

Various upgrades to the editor and especially the importmaps rework in both packages – the importmap infrastructure should now be CSP-compatible! I wrote more about that in the last post The 2026 way of using importmaps in Django.

django-content-editor

Minor bugfixes and a major version bump because of the rework of the JavaScript code into multiple ES modules. The content editor now uses importmaps as well.

django-fhadmin

Small bugfix so that links aren’t underlined in the app groups list when they shouldn’t be, matching how the Django admin itself behaves.

django-cabinet

The cabinet / prose editor integration for the file (or image) picker is final and released as a stable version.

django-json-schema-editor

This small release only contains more correct German translations of strings.

I didn’t actually create this release, but I contributed various changes to it. The changelog for 7.0 is here.

The 2026 way of using importmaps in Django

2026-06-17T12:00:00Z

The 2026 way of using importmaps in Django

I last wrote about Django, JavaScript modules and importmaps in May 2025, slightly over a year ago.

The main topic of this post is the django-js-asset 4.0 release. The library is used in many places, some of the more well-known packages using it are django-mptt and django-ckeditor. I have since done a lot of work evolving the ways of integrating importmaps but the efforts to standardize upon an approach have stalled a bit. The main reason for this, apart from time and energy, was that I wasn’t really all that happy with the global importmap. When I had only a few modules using the importmap facility, I didn’t care all that much. Now that the recently released django-content-editor 9.0 also uses importmaps for shipping a refactored, much more modular JavaScript implementation while still keeping all the benefits of cache busting using ManifestStaticFilesStorage¹, having a global importmap got annoying. The content editor JavaScript is only used within the Django administration interface, but when using a single global importmap object, the importmap entries were always there on each page that used an importmap at all.

A better solution was needed. I’m a big fan of using forms.Media for collecting CSS and JavaScript from widgets, forms and utilities. It helps me avoid inline JavaScript since at least 2017. I’m not using it for site-wide CSS and JavaScript, I’m still transpiling, PostCSS-ing and bundling the assets using rspack as for example written about here and here.

Why importmaps?

A quick refresher on why this matters at all. Django’s ManifestStaticFilesStorage hashes the contents of each file into its name for cache busting, but out of the box it doesn’t rewrite the import statements inside JavaScript modules. Importmaps bridge the gap: your code imports a stable name:

import { initializeEditors } from "django-prose-editor/editor"

and the importmap tells the browser where that name actually lives:

<script type="importmap">
{"imports": {
  "django-prose-editor/editor": "/static/django_prose_editor/editor.6e8dd4c12e2e.js"
}}
</script>

So the import stays clean and constant while the file behind it can get a new hash on every deploy.

django-js-asset 4.0

The updated django-js-asset 4.0 doesn’t ship the old, global importmap at all. This means the upgrade might require some work. Instead of one importmap shared across the whole site, you now get a specific importmap assembled for the context at hand – either by Django itself when it collects the media of your forms, widgets and the admin, or explicitly by you in a view or context processor. The building block in both cases is the ImportMap object; when it travels through js_asset.Media (a subclass of django.forms.Media) the maps are automatically merged into a single <script type="importmap">, by customizing and extending what Django does already when merging media instances.

The release notes go into more detail.

In practice

If you’re using a package such as django-prose-editor in the Django admin you don’t have to do anything, things should just work.

If you’re using such a package outside the admin, you have to remove "js_asset.context_processors.importmap" from your list of context processors. On one particular website the prose editor is the only package with importmap entries outside the admin, so I have to add the importmap to the template context myself:

from django_prose_editor.widgets import importmap

def view(request, ...):
    return render(request, "template.html", {
        # ...
        "importmap": importmap,
    })

The template then just renders it in the <head>:

... {{ importmap }}</head>

On a different site, I have a slightly more involved scenario where I previously used importmap.update(...) to add my own entries to the importmap. There, I’m using a custom context processor to always add these entries to the importmap too:

from django_prose_editor.widgets import importmap as dpe_importmap
from js_asset import ImportMap, static_lazy

_site_importmap = ImportMap({
    "imports": {
        "my-module": static_lazy("my-module.js"),
    }
})
_importmap = dpe_importmap | _site_importmap

def importmap(request):
    return {"importmap": _importmap}

This importmap is merged once at server startup and then served repeatedly to the client. Because we use the lazy version of the static function we can do this during startup and not worry about files not yet collected by collectstatic – we’ll get the correct paths later.

On the same site as the previous example, I also have an admin inline which requires some JavaScript and also an importmap:

from django.contrib import admin
from django.forms import Script
from js_asset import Media, ImportMap

# Initializing this once. Not necessary but I like it better that way.
_importmap = ImportMap({
    "imports": {
        # ...
    }
})

class ModelInline(admin.StackedInline):
    @property
    def media(self):
        return Media(
            js=[
                _importmap,
                Script("module.js", type="module"),
            ]
        )

As of 4.0, JS and CSS produce Django’s own Script and Stylesheet objects, so you can import and use Script directly from django.forms as shown above (on Django 4.2–5.1, import it from js_asset instead, which backports it). The familiar JS("module.js", {"type": "module"}) wrapper still works unchanged if you prefer it — it just takes a positional dict instead of keyword arguments.

Here, it’s really important to use the js_asset.Media and not django.forms.Media. js_asset.Media knows how to handle importmaps – all importmaps are collected from all media lists, merged and added to the output before all other CSS and especially JavaScript. The reason for that is that browsers only honour a single importmap per page, and it really has to appear before all JavaScript modules referencing any entries in the importmap.

The nice thing about js_asset.Media is that it doesn’t have to appear first in the list of media classes which are merged – it can also appear in the middle or last, and still can do its magic after all Media objects have been merged into a single one.

The rest is handled by Django itself, since it already supports collecting media assets. The missing piece was just the importmap object and the js_asset.Media class which knows how to special case them, and which – through the power of overriding __add__ and __radd__ takes over all the other media instances.

What’s next

I haven’t yet used CSP nonces using {% csp_nonce_attr media %} in production myself, but it should just work, even with importmaps and everything else. Given that I have a passing test suite I have no reason to believe it doesn’t already work, but I’d like to have a confirmation.

I’m hoping to standardize some more. If we could get something like this in Django core that would be really nice. Maybe I’ll be able to work on that at Django on the Med 🏖️. Since no browser supports multiple importmaps as of today having multiple implementations of importmaps in the Django ecosystem will lead to trouble down the road. I think there is a clear case to be made for importmap support in Django and I would obviously love it if the approach implemented today in django-js-asset would be the basis for the official solution.

Without having to do any overrides to enable ESM support. ↩

«Anything new?»

2026-06-03T12:00:00Z

«Anything new?»

A lot of time has passed since I officially announced that I want to step down from maintaining django-mptt. I started contributing around 2009, tagged the 0.3 release in April 2010, and have been the sole active maintainer since somewhere around 2019. The post about django-tree-queries has more background, but that’s not today’s topic.

Stepping away isn’t easy

For me, abandoning a project is a bit like stepping out of a relationship: negative emotions end up being a somewhat necessary driver, because the absence of positive events alone rarely provides enough force on its own. I get a lot of satisfaction from a job well done, and walking away means letting that go.

Even with time set aside for open source in my work day, I still have to choose where that time goes. django-mptt stopped being where it needed to go.

The sense of entitlement

When a project is obviously unmaintained, asking for free labor is walking a tightrope. It takes real care not to rekindle exactly the frustrations that led maintainers away in the first place.

It takes energy not to clap back when someone is being rude or insensitive in the issue tracker. Asking “Anything new?” on a ticket where the next steps were outlined clearly and obviously nothing happened in the meantime is just one variant of this.

Quietly quitting isn’t what I want to do — and as a user of django-mptt myself, I can’t really do that either. Taking the high road is the professional choice. But it costs something.

I keep coming back to Mona Eltahawy on refusing to be civil. She’s speaking about something quite different, and I’m aware I write this as a white man. The situations aren’t the same at all. But she articulated something I haven’t managed to put into words as well myself and I like the idea of speaking up and taking the fight to those who awaken these feelings instead of taking the high road.

Doing it with AI

No post these days is complete without the obligatory AI mention, but there’s some relevancy to it.

I fixed and closed almost all open django-mptt issues in a two-hour Claude session. I’ve previously written about using LLMs for open source maintenance, and the productivity gain is real whatever the detractors say. And the quality isn’t suddenly getting worse. Code wasn’t perfect before either. The test suite allows a certain degree of trust in the result and according to my rules for releasing Open Source software we don’t have to require more than that.

It doesn’t change the underlying dynamic, though. rsync and outrage illustrates the trap neatly: Tridgell got flooded with AI-generated security reports, used AI to handle them, and then got criticized for using AI. The tools that created the workload aren’t allowed to address it. The expectation is that the work has to involve sweat and tears and uncountable unpaid hours.

The common goal should be more and better open source software. What we get as Open Source maintainers is shit from both sides: One side took our free work and trained models on it without asking, the other side complains about the supposedly unethical use of AI while acting in unethical ways themselves.

There’s something Kantian about how open source contribution gets framed. Kant’s argument was that the only truly moral acts are those driven by duty and good will — not by desire, inclination, or any expectation of compensation. By that logic, I’m only acting morally if I keep going despite the burnout and the entitlement. If I stop, I’m not.

It’s bleak. The problems with AI are real. The people controlling the large models are assholes. But I have to work in the world as it is while also trying to change it for the better.

Weeknotes (2026 week 17)

2026-05-20T12:00:00Z

Weeknotes (2026 week 17)

I published the last entry near the beginning of March. I’m really starting to see a theme in my Weeknotes publishing schedule.

Releases since the first weeks of March

I’m trying out a longer-form version of those notes here than in the past. I think it’s worth going into some detail and not just listing releases with half a sentence each.

feincms3-sites and feincms3-language-sites

I released updates to feincms3-sites and feincms3-language-sites fixing the same issue in both projects: When an HTTP client didn’t strip the default ports :80 (for HTTP) or :443 (for HTTPS) from a request, finding the correct site would fail. Browsers generally strip the port already, but some other HTTP clients do not.

django-tree-queries

As I wrote elsewhere I closed many issues in the repositories, mostly documentation issues but also some bugs. {% recursetree %} should now work properly and not cache old data anymore, using the primary key in .tree_fields() now raises an intelligible error, and I also fixed a bug with table quoting when using django-tree-queries with the not yet released Django 6.1+.

feincms3-cookiecontrol

feincms3-cookiecontrol not only offers a cookie consent banner (which actually supports only embedding tracking scripts when users give consent) but also a third-party content embedding functionality which allows allowlisting individual services.

The privacy policies of these services are now linked inline instead of with an ugly extra link. This reduces content inside the embed which helps on small screens.

Version 1.7 used a buggy trusted publishing workflow so I immediately published 1.7.1.

django-cabinet and django-prose-editor

django-cabinet can now be used as a media library directly inside django-prose-editor. I’m (ab)using the CKEditor 4 protocol for embedding, which uses window.opener.CKEDITOR.callFunction to send data back from the file manager popup into the editor. It feels icky but works nicely. This is only available if you’re installing the alpha prereleases, but I’m already testing the functionality in production somewhere, so I feel quite good about it.

django-prose-editor now also ships brand new ClassLoom and StyleLoom extensions. Both extensions allow adding either classes or inline styles to text spans or nodes. In an ideal world we might not use something like this, but to make the editor more useful in the real world, editors need more flexibility. These two extensions provide that. I already mentioned ClassLoom in December, now it’s actually available. I’m not completely sold on how they work yet, but both of them are already solving real issues.

Honorable mentions

django-debug-toolbar 6.3 has been released, I only contributed reviews during this cycle.

Switching all of my Python packages to PyPI trusted publishing

2026-04-08T12:00:00Z

Switching all of my Python packages to PyPI trusted publishing

As I have teased on Mastodon, I’m switching all of my packages to PyPI trusted publishing. I have been using it to release the django-debug-toolbar a few times but never set it up myself. The process seemed tedious.

The malicious releases uploaded to PyPI two weeks ago and the blog post about digital attestations in pylock.toml finally pushed me to make the switch. All of my PyPI tokens have been revoked so there is no quick shortcut.

I’m also looking at other code hosting platforms. I have been using git before GitHub existed and I’ll probably still use git when GitHub has completed its enshittification. For now the cost/benefit ratio of staying on GitHub is still positive for me. Trusted publishing isn’t available everywhere, so for now it is GitHub anyway.

In the end, switching an existing project was easier than expected. I have completed the process for django-prose-editor and feincms3-cookiecontrol.

For my future benefit, here are the step by step instructions I have to follow:

Have a package which is buildable using e.g. uvx build
On PyPI add a trusted publisher in the project’s publishing settings:
- Owner: matthiask, feincms, feinheit, whatever the user or organization’s name is.
- Repository: django-prose-editor
- Workflow name: publish.yml
- Environment: release
In the GitHub repository, create a release environment in Settings / Environments. If I want to manually approve releases I’ll add myself and potentially also other releasers as required reviewers.
Run git tag x.y.z and git push, no more uvx twine or hatch publish.
Approve the release in the actions tab on the repository.
Either enjoy or swear and repeat the steps.

I’m happy with testing the release process in production. The older I get the less I care if people think I’m stupid. That’s also why feincms3-cookiecontrol 1.7.0 doesn’t exist, only 1.7.1 – the process failed and I had to bump the patch version and try again. Copy the publish.yml from a known good place, for example from the django-prose-editor repository. I have added the if: github.repository == 'feincms/django-prose-editor' statement which ensures that the workflow only runs in the main repository, but that’s optional if you don’t care about failing workflows.

LLMs for Open Source maintenance: a cautious case

2026-03-25T12:00:00Z

LLMs for Open Source maintenance: a cautious case

When ChatGPT appeared on the scene I was very annoyed at all the hype surrounding it. Since I’m working in the fast moving and low margin business of communication and campaigning agencies I’m surrounded by people eager to jump on the hype train when a tool promises to lessen the workload and take stuff from everyone’s plate.

These discussions coupled with the fact that the training of these tools required unfathomable amounts of stealing were the reason for a big reluctance on my part when trying them out. I’m using the word stealing here on purpose, since that’s exactly the crime Aaron Swartz was accused of by the attorney’s office of the district of Massachusetts. It’s frustrating that some people can get away with the same crime when it is so much bigger. For example, OpenAI and Anthropic downloaded much more data than Aaron ever did.

A somewhat related thing happened with the too-big-to-fail banks: There, the people at the top were even compensated with golden parachutes at the end. LLM companies seem to be above accountability too.

Despite all this, I have slowly started integrating these tools into my workflows. I don’t remember the exact point in time, but since some time in 2025 my opinions on their utility has started to change. At the beginning, I always removed the attribution and took great care to write and rewrite the code myself, only using the LLMs for inspiration and maybe to generate integration tests. More and more I have to admit that they are useful, especially in time constrained projects with a clear focus and purpose.

Last month I fixed and/or closed all open issues in the django-tree-queries repository with the help of Claude Code. Is that a good thing? It could be argued I should have done the work myself. But I wouldn’t have — I have other things I want to do with my time. I don’t want to (always) work on Open Source software in the evening. I definitely also have leaned heavily on LLMs when working on django-prose-editor.

Is faster better?

We can produce more code, more features and close tickets faster than before. In my experience the speed up isn’t as big as some people may want us to believe, but it’s there. And contrary to what people in my LinkedIn feed say, that’s not an obviously good thing. Is it a race to the bottom where we drown in LLM-generated slop in quantities impossible to maintain? It doesn’t feel like that — but it’s a race that could go both ways. Throwaway code can be thrown away though, and well tested code does what the tests say, which is good enough according to my rules for releasing open source software.

Speaking as someone who has put more into the training set than they’ve taken out so far, I don’t feel all that bad using the tools. Coding agents can already be run locally with reasonable hardware requirements, at least during inference, which is where the ongoing cost sits. Maybe using them is still rationalization. But contribution and profit needing to stay in some rough balance feels like the right frame. Total abstinence isn’t the only ethical choice we have.

Community tensions

What makes me less comfortable is how communities are reacting. There are real concerns within the Django world, and not just the practical one of overworked maintainers wading through hastily generated patches that don’t actually fix anything. The deeper worry is about the communal nature of contribution: that working on Django is supposed to be a learning experience, a way into the community, and that using an LLM as a vehicle rather than a tool hollows out that process. Reviewers end up interacting with what is essentially a facade, unable to tell whether anyone actually understood the problem. That’s a real concern and I don’t want to dismiss it.

But it maps onto a different situation from what I’ve been describing. Using Claude Code to close issues in projects I maintain and understand is not the same as using it to paper over gaps in comprehension on a ticket in someone else’s project. Whether LLM-assisted contributions to Django itself are appropriate is a difficult question; whether it’s appropriate to use them when maintaining your own software less so.

There’s also a harder tension around quality. Django’s conservatism has real value: rigorous review, minimal magic, a coherent philosophy. The ORM and template system don’t need to reinvent themselves, they work well, are still evolving while staying rock-solid for all my use cases. And reading the release notes always brings me joy. But it could be more exciting more often. Quality isn’t a strictly positive thing. Everything has costs. It’s not great if the price of the bar is that legitimate bugs sit open for years because nobody has a few evenings to spend on them. It happened with django-tree-queries before I went through it with Claude Code. I think the bar for contributing to Django is too high. I would value a little more motion and a little less stability, even as someone running dozens of Django websites and apps.

Then there’s the pile-on dynamic that plays out on Mastodon and GitHub. When the Harfbuzz and chardet maintainers disclosed LLM usage, the reaction from some corners was something to behold. People expressing what amounted to personal grievance over tooling choices in projects they may not even use. There’s a particular kind of entitlement in telling a maintainer – who is keeping software alive, possibly even in their spare time – that the way they choose to do that work is an affront. Open source is a gift, whether paid or not, and nobody has to accept it, but disclosing your tooling isn’t an invitation for complaints. The ethical concerns about training data, resource use and other negative externalities are legitimate and worth raising. Performative outrage directed at individual maintainers is not the same thing.

I don’t have an easy conclusion. The tools are useful, the ethics are murky, and communities are still figuring out how to respond. A cautious, honest use of them feels better to me than the alternatives.

Weeknotes (2026 week 11)

2026-03-11T12:00:00Z

Weeknotes (2026 week 11)

Last time I wrote that I seem to be publishing weeknotes monthly. Now, a quarter of a year has passed since the last entry. I do enjoy the fact that I have published more posts focused on a single topic. That said, what has been going on in open source land is certainly interesting too.

LLMs in Open Source

I have started a longer piece to think about my stance regarding using LLMs in Open Source. The argument I’m thinking about is that there’s a balance between LLMs having ingested all of my published open source code and myself using them now to help myself and others again.

The happenings in the last two weeks (think Pentagon, Iran, and the bombings of schools) have again brought to the foreground the perils of using those tools. I therefore haven’t been motivated to pursue this train of thought for the moment. When the upsides are somewhat questionable and tentative and the downsides are so clear and impossible to miss, it’s hard to use my voice to speak in favor of these tools.

That said, all the shaming when someone uses an LLM that I see in my Mastodon feed also annoys me. I’ll quote part of a post here which I liked and leave it at that for the moment:

The AI hype-cyclone is bad, but so is the anti-AI witch hunt. Commits co-authored by Claude do not mean that a project has “abandoned engineering as a serious endeavor”

[…]

– @nedbat on Mastodon

Other goings-on

Health: My back continues to improve. Some days are still bad, but the idea that the herniation may go away entirely doesn’t sound totally unreasonable anymore.
Gardening: We started weeding the garden last week. Lots to do! Being outside is fun. Weeding isn’t the greatest part ever, but it’s meditative.

Releases since December

django-json-schema-editor 0.12.1: CSS fixes. I have again looked at other, more modern JSON schema editor implementations but all of them are more limited than is acceptable to act as a replacement.
django-debug-toolbar 6.2: I haven’t done much work here! Just some reviewing.
django-content-editor 8.1: Started emitting warnings when using non-abstract base classes for plugins. Using multi table inheritance is mostly an accident and not intended in my experience when using django-content-editor, therefore we have started detecting this case and emitting system checks (warnings, not errors).
django-imagefield 0.23.0a3: We have done some work on supporting libvips as an alternative backend to Pillow because I hoped that memory usage in Kubernetes pods might go down a bit. Results are not conclusive yet, and I’m not yet convinced the additional code complexity is worth it. Debugging and monitoring continues.
FeinCMS 26.2.1: Released a few bugfixes. FeinCMS is still being maintained ~17 years later!
django-auto-admin-fieldsets 0.3: Added a helper to remove fields from the fieldsets structure.
django-tree-queries 0.23.1: Shipped a small bugfix for {% recursetree %} which unintentionally cached children across invocations.
feincms3-downloads: Used PATH from the environment instead of using a very restricted allowlist so that convert and pdftocairo are detected in more locations. This should help with local development for example on macOS.
django-prose-editor 0.24.1: Read the CHANGELOG; there’s too much in there for a short notice.
form-designer 0.27.3: Mosparo captcha support, bugfixes and additional translations.
feincms3 5.5: Started using the OrderableTreeNode from django-tree-queries.

Rich text editors: How restrictive can we be?

2025-12-17T12:00:00Z

Rich text editors: How restrictive can we be?

How restrictive should a rich text editor be? It’s a question I keep coming back to as I work on FeinCMS and Django-based content management systems.

I published the last blog post on django-prose-editor specifically in August 2025, Menu improvements in django-prose-editor. The most interesting part of the blog post was the short mention of the TextClass extension at the bottom which allows adding a predefined list of CSS classes to arbitrary spans of text.

In the meantime, I have spent a lot of time working on extensions that try to answer this question: the TextClass extension for adding CSS classes to inline text, and more recently the NodeClass extension for adding classes to nodes and marks. It’s high time to write a post about it.

Rich Text editing philosophy

All of this convinced me that offering the user a rich text editor with too much capabilities is a really bad idea. The rich text editor in FeinCMS only has bold, italic, bullets, link and headlines activated (and the HTML code button, because that’s sort of inevitable – sometimes the rich text editor messes up and you cannot fix it other than going directly into the HTML code. Plus, if someone really knows what they are doing, I’d still like to give them the power to shoot their own foot).

– Commit in the FeinCMS repository, August 2009, current version from django-content-editor design decisions

Should we let users shoot themselves in the foot?

Giving power users an HTML code button would have been somewhat fine if only the editors themselves were affected. Unfortunately, that was not the case.

As a team we have spent more time than we ever wanted debugging strange problems only to find out that the culprit was a blob of CSS or JavaScript inserted directly into an unsanitized rich text editor field. We saw everything from a few reasonable and well scoped lines of CSS to hundreds of KiBs of hotlinked JavaScript code that broke layouts, caused performance issues, and possibly even created security vulnerabilities.

We have one more case of Betteridge’s law of headlines here.

The pendulum swings

The first version of django-prose-editor which replaced the venerable CKEditor 4 in our project was much more strict and reduced – no attributes, no classes, just a very short list of allowlisted HTML tags in the schema.

We quickly hit some snags. When users needed similar headings with different styles, we worked around it by using H2 and H3 — not semantic at all. I wasn’t exactly involved in this decision; I just didn’t want to rock the boat too much, since I was so happy that we were even able to use the more restricted editor at all in this project.

Everything was good for a while, but more and more use cases crept up until it was clear that something had to be done about it. First, the TextClass extension was introduced to allow adding classes to inline text, and later also the NodeClass extension mentioned above. This was a compromise: The customer wanted inline styles, we wanted as little customizability as possible without getting in the way.

That said, we obviously had to move a bit. After all, going back to a less strict editor or even offering a HTML blob injection would be worse. If we try to be too restrictive we will probably have to go back to allowing everything some way or the other, after all:

The more you tighten your grip, Tarkin, the more star systems will slip through your fingers.

– Princess Leia

Combining CSS classes

The last words are definitely not spoken just yet. As teased on Mastodon at the beginning of this month I am working on an even more flexible extension which unifies the NodeClass and TextClass extensions into a single ClassLoom extension.

The code is getting real world use now, but I’m not ready to integrate it yet into the official repository. However, you can use it if you want, it’s 1:1 the version from a project repository. Get the ClassLoom extension here.

This extension also allows combining classes on a single element. If you have 5 colors and 3 text styles, you’d have to add 15 combinations if you were only able to apply a single class. Allowing combinations brings the number of classes down to manageable levels.

Conclusion

So, back to the original question: How restrictive can we be?

The journey from CKEditor 4’s permissiveness through django-prose-editor’s initial strictness to today’s ClassLoom extension has been one of finding that balance. Each extension — TextClass, NodeClass, and now ClassLoom — represents a step toward controlled flexibility: giving content editors the styling options they need while keeping the content structured, maintainable, and safe.

Weeknotes (2025 week 49)

2025-12-05T12:00:00Z

Weeknotes (2025 week 49)

I seem to be publishing weeknotes monthly, so I’m now thinking about renaming the category :-)

Mosparo

I have started using a self-hosted mosparo instance for my captcha needs. It’s nicer than Google reCAPTCHA. Also, not sending data to Google and not training AI models on traffic signs feels better.

Fixes for the YouTube 153 error

Simon Willison published a nice writeup about YouTube embeds failing with a 153 error. We have also encountered this problem in the wild and fixed the feincms3 embedding code to also set the required referrerpolicy attribute.

Updated packages since 2025-11-04

django-sitemaps 2.0.2: Uploaded a new release which includes a wheel build. Rebuilding the wheel all the time when creating new container images was getting annoying. The code itself is unchanged.
django-prune-uploads 0.3.1: The package now supports pruning a storage backed by django-s3-storage efficiently. I have also looked at django-prune-media but since the package uses the storage API instead of enumerating files using boto3 directly it’s unusably slow for my use case.
feincms3-forms 0.6: Much better docs and a new way to reference individual form fields in custom templates.
django-json-schema-editor 0.11: Switched from JSON paths to jmespath instances. Made the JSON model instance reference support easier and more fun to use. Added new ways of customizing the generated proxy model for individual JSON plugin instances.
form-designer 0.27.1: Added support for the mosparo captcha to the default list of field types.
asgi-plausible 0.1.1: No code change really, just added required dependencies to the package metadata.
django-tree-queries 0.23: The package now ships a OrderableTreeNode base model which you can use when you want to order siblings manually. feincms3 already uses this base model for its pages model.
feincms3-data 0.10: This is quite a big one. I discovered issues with the way save_as_new (to copy data) and delete_missing interacted. First the code was cleaned up to delete less data, and then to delete enough data. I’m now somewhat confident that the code does what it should again.
django-prose-editor 0.22.3: Started returning an empty string for an empty document instead of <p></p> also when using the frontend integration; previously, this transformation was only implemented when using at least the form if not the model field. Also, <ol> tags now have a data-type attribute since Chrome cannot case-sensitively match e.g. type="a" vs type="A" for lowercase or uppercase letters. I previously only tested the code in Firefox and there it worked nicely.

Thoughts about Django-based content management systems

2025-11-05T12:00:00Z

Thoughts about Django-based content management systems

I have almost exclusively used Django for implementing content management systems (and other backends) since 2008.

In this time, content management systems have come and gone. The big three systems many years back were django CMS, Mezzanine and our own FeinCMS.

During all this time I have always kept an eye open for other CMS than our own but have steadily continued working in my small corner of the Django space. I think it’s time to write down why I have been doing this all this time, for myself and possibly also for other interested parties.

Why not use Wagtail, django CMS or any of those alternatives?

Let’s start with the big one. Why not use Wagtail?

The Django administration interface is actually great. Even though some people say that it should be treated as a tool for developers only, recent improvements to the accessibility and the general usability suggest otherwise. I have written more about my views on this in The Django admin is a CMS. Using and building on top of the Django admin is a great way to immediately profit from all current and future improvements without having to reimplement anything.

I don’t want to have to reimplement Django’s features, I want to add what I need on top.

Faster updates

Everyone implementing and maintaining other CMS is doing a great job and I don’t want to throw any shade. I still feel that it’s important to point out that systems can make it hard to adopt new Django versions on release day:

The update cycle of many large apps using Django lag behind Django. Wagtail declares an upper version boundary for Django which makes it hard to adopt Django versions faster than Wagtail releases updates.
Some django CMS components such as django-filer have lagged behind in the past. Looking at the project’s CI matrix and activity suggests that this is not the case anymore. That said, a simpler alternative exists.

These larger systems have many more (very talented) people working on them. I’m not saying I’m doing a better job. I’m only pointing out that I’m following a different philosophy where I’m conservative about running code in production and I’d rather have less features when the price is a lot of maintenance later. I’m always thinking about long term maintenance. I really don’t want to maintain some of these larger projects, or even parts of them. So I’d rather not adopt them for projects which hopefully will be developed and maintained for a long time to come. By the way: This experience has been earned the hard way.

The rule of least power

From Wikipedia:

In programming, the rule of least power is a design principle that “suggests choosing the least powerful [computer] language suitable for a given purpose”. Stated alternatively, given a choice among computer languages, classes of which range from descriptive (or declarative) to procedural, the less procedural, more descriptive the language one chooses, the more one can do with the data stored in that language.

Django itself already provides lots and lots of power. I’d argue that a very powerful platform on top of Django may be too much of a good thing. I’d rather keep it simple and stupid.

Editing heterogenous collections of content

Django admin’s inlines are great, but they are not sufficient for building a CMS. You need something to manage different types. django-content-editor does that and has done that since 2009.

When Wagtail introduced the StreamField in 2015 it was definitely a great update to an already great CMS but it wasn’t a new idea generally and not a new thing in Django land. They didn’t say it was and welcomed the fact that they also started using a better way to structure content.

Structured content is great. Putting everything into one large rich text area isn’t what I want. Django’s ORM and admin interface are great for actually modelling the data in a reusable way. And when you need more flexibility than what’s offered by Django’s forms, the community offers many projects extending the admin. These days, I really like working with the django-json-schema-editor component; I even reference other model instances in the database and let the JSON editor handle the referential integrity transparently for me (so that referenced model instances do not silently disappear).

Weeknotes (2025 week 45)

2025-11-04T12:00:00Z

Weeknotes (2025 week 45)

Autumn is nice

I love walking through the forest with all the colors and the rustling when you walk through the leaves on the ground.

Updated packages since 2025-10-23

feincms3 5.4.3: Small fix for the YouTube IFRAME; it seems that the referrerpolicy attribute is now necessary for the embed to work everywhere.
django-json-schema-editor 0.8.2: Allowed forwarding more options to the prose editor component; specifically, not just extensions but also the undocumented js_modules entry. This means that custom extensions are now also supported inside the JSON editor component.
django-prose-editor 0.20: I reworked the menu extension to be customizable more easily (you can now specify button groups and dropdowns directly without using JavaScript code) and I also extended the NodeClass extension to allow assigning predefined CSS classes not only to nodes but also to marks.

Weeknotes (2025 week 43)

2025-10-23T12:00:00Z

Weeknotes (2025 week 43)

I published the last weeknotes entry in the first half of September.

Drama in OSS

I have been following the Ruby gems debacle a bit. Initially at Feinheit we used our own PHP-based framework swisdk2 to build websites. This obviously didn’t scale and I was very annoyed with PHP, so I was looking for alternatives.

I remember comparing Ruby on Rails and Django, and decided to switch from PHP/swisdk2 to Python/Django for two reasons: The automatically generated admin interface and the fact that Ruby source code just had too much punctuation characters for my taste. It’s a very whimsical reason and I do not put any weight on that. That being said, given how some of the exponents in Ruby/Rails land behave I’m very very glad to have chosen Python and Django. While not everything is perfect (it never is) at least those communities agree that trying to behave nicely to each other is something to be cheered and not something to be sneered at.

Copilot

I assigned some GitHub issues to Copilot. The result wasn’t very useful. I don’t know if I want to repeat it, local tools work fine for when I really need them.

Python and Django compatibility

It’s the time again to update the GitHub actions matrix and Trove identifiers. I do not like doing it. You can expect all maintained packages to be compatible with the latest and best versions, no upper bounds necessary. Man, if only AI could automate those tasks…

Updated packages since 2025-09-10

feincms3: We use hashlib.md5, but not for security.
django-tree-queries 0.21.2: django-tree-queries now bundles an admin interface for trees.
django-content-editor 8.0.3: Minor CSS fix so that the editor looks nicer with Django 6.0.
django-json-schema-editor 0.8.1: Fixes for multiple JSON editors in the same window, better JSONPlugin.__str__ default implementation.
django-cabinet 0.18.1: Fix a minor bug around the selected folder handling. Invalid folder ID values could crash the backend under some circumstances.
django-prose-editor 0.18.5: No large changes, mainly Tiptap updates.

My favorite Django packages

2025-10-22T12:00:00Z

My favorite Django packages

Inspired by other posts I also wanted to write up a list of my favorite Django packages. Since I’ve been working in this space for so long and since I’m maintaining quite a large list of packages I worry a bit about tooting my own horn too much here; that said, the reasons for choosing some packages hopefully speak for themselves.

Also, I’m sure I’m forgetting many many packages here. Sorry for that in advance.

Core Django

speckenv: Loads environment variables from .env and automatically converts them to their Python equivalent if ast.literal_eval understands it. Also contains implementations for loading database, cache, email and storage configuration from environment variables (similar to dj-database-url). I added this functionality to speckenv when some of the available environment configuration apps’ maintenance state was somewhat questionable.
django-cors-headers: CORS header support for Django. This would be a nice addition to Django itself.
sentry-sdk: I’m using Sentry in almost all projects.
django-template-partials: Template partials for Django! This has been added to the upcoming 6.0 release of Django. While the Django template language has always been evolving and improving, this feels like the first larger step in a long time. As I and others have said, the combination of htmx and django-template-partials is really really nice. It isn’t surprising at all that htmx is so well loved in the Django community.
django-s3-storage: Yes, django-storages exist, but I prefer django-s3-storage because of its focus and simplicity.
django-imagefield: Image field which validates images deeply, and supports pre-rendering thumbnails etc. I understand why Django only superficially validates uploaded images because of the danger of denial of service attacks, but I’d rather not have files on the sites I manage which the great Pillow library doesn’t support.
psycopg: Whenever I can I work with PostgreSQL, and psycopg is how I interface with the database.

Data structures

django-tree-queries: My favorite way to work with trees except when talking about real trees.
django-translated-fields: My preferred way to do model-level internationalization.

CMS building

I have been working on FeinCMS since 2009. So, it shouldn’t surprise anyone that this is still my favorite way to build CMS on top of Django. I like that it’s basically a thin layer on top of Django’s administration interface and doesn’t want to take over the whole admin interface or even the whole website.

feincms3: The modern, focussed foundation replacing FeinCMS.
django-content-editor: The admin interface extension providing core components to build content editing interfaces.
django-prose-editor: A nice HTML editor by yours truly.
django-json-schema-editor: JSON schema-based editing using @json-editor/json-editor.

Working with external content

micawber: Micawber is my favorite tool to embed third party content (YouTube, Vimeo, whatever) when feincms3’s own very limited embedding functionality is insufficient.
feincms3-cookiecontrol: Everyone likes cookie banner (or not). feincms3-cookiecontrol implements not just an informative cookie banner, but actually supports not embedding tracking scripts and third party content unless the user consented, either a blanket or a per-provider consent for embedded media. It does NOT support the very annoying interface where you have to deselect each tracking service individually.

PDF generation

Reportlab: Reportlab is nice if you need fine-grained control over PDF generation. Reportlab has created more than 10’000 invoices for the company I work at, so I’m definitely grateful for it :-)
Weasyprint: I have been using Weasyprint more and more for generating PDFs. Using HTML and CSS can be nicer than using Reportlab’s Platypus module. Weasyprint doesn’t instrument a webbrowser to produce PDFs but instead implements the rendering engine itself. It works really well.

Testing and development

I actually do like unittest. I have started using pytest somewhat more often because using -k keyword to filter tests to run is great.
factory-boy: This package has always treated me well when creating data for tests.
playwright: Playwright is the end-to-end test browser automation library I prefer.

Last but not least, I really like django-debug-toolbar. So much, that I’m even helping with the maintenance since 2016.

Serving

We mostly use Kubernetes to serve websites these days. Inside the pods, I’m working with the granian RSGI/ASGI server and with blacknoise for serving static files.

LLMs are making me a better programmer...

2025-09-12T12:00:00Z

LLMs are making me a better programmer…

I’m still undecided about LLMs for programming. Sometimes they are very useful, especially when working on a clearly stated problem within a delimited area. Cleaning the code up afterwards is painful and takes a long time though. Even for small changes I’m unsure if using LLMs is a way to save (any) resources, be it time, water, energy or whatever.

They do help me get started, and help me be more ambitious. That’s not a new idea. Simon Willison wrote a post about this in 2023 and the more I think about it or work with AI the more I think it’s a good way to look at it.

A recent example which comes to mind is writing end to end tests. I can’t say I had a love-hate relationship with end to end testing, it was mostly a hate-hate relationship. I hate writing them because it’s so tedious and I hate debugging them because of all the timing issues and the general flakyness of end to end testing. And I especially hate the fact that those tests break all the time when changing the code, even when changes are mostly unrelated.

When I discovered that I could just use Claude Code to write those end to end tests I was ecstatic. Finally a way to add relevant tests to some of my open source projects without having to do all this annoying work myself! Unfortunately, I quickly discovered that Claude Code decided (ha!) it’s more important to make tests pass than actually exercising the functionality in question. When some HTML/JavaScript widget wouldn’t initialize, why not just manipulate innerHTML so that the DOM looks as if the JavaScript actually ran? Of course, that’s a completely useless test. The amount of prodding and instructing the LLM agent required to stop adding workarounds and fallbacks everywhere was mindboggling. Also, since tests are also code which has to be maintained in the future, does generating a whole lot of code actually help or not? Of course, the amount of code involved wasn’t exactly a big help when I really had to dig into the code to debug a gnarly issue, and the way the test was written didn’t exactly help!

I didn’t want to go back to the previous state of things when I had only backend tests though, so I had to find a better way.

Playwright codegen to the rescue

I already had some experience with Playwright codegen, having used it for testing some complex onboarding code for a client project I worked on a few years back, so I was already aware of the fact that I could run the browser, click through the interface myself, and playwright would actually generate some of the required Python code for the test itself.

This worked fine for a project, but what about libraries? There, I generally do not have a full project ready to be used with ./manage.py runserver and Playwright. So, I needed a different solution: Running Playwright from inside a test!

If your test uses the LiveServerTestCase all you have to do is insert the following lines into the body of your test, directly after creating the necessary data in the database (using fixtures, or probably better yet using something like factory-boy):

import subprocess
print(f"Live server URL: {live_server.url}")
subprocess.Popen(["playwright", "codegen", f"{self.live_server_url}/admin/"])
input("Press Enter when done with codegen...")

Or of course the equivalent invocation using live_server.url when using the live_server fixture from pytest-django.

Of course Tim pointed me towards page.pause(). I didn’t know about it; I think it’s even better than what I discovered, so I’m probably going to use that one instead. I still think writing down the discovery process makes sense.

So now, when LiveServerTestCase is already set up and I already have a sync Playwright context lying around, I can just do:

page = context.new_page()
page.pause()

TLDR

Claude Code helped getting me to get off the ground with adding end to end tests to my projects. Now, my tests are better because – at least for now – I’m not using AI tools anymore.

Weeknotes (2025 week 37)

2025-09-10T12:00:00Z

Weeknotes (2025 week 37)

I’m having a slow week after the last wisdom tooth extraction. Finally! I’m slowly recuperating from that.

I’m trying to split up the blog posts a bit and writing more standalone pieces instead of putting everything into weeknotes. Publishing more focussed pieces sounds like a good thing and should also help me with finding my own writing later.

Releases

django-content-editor 8.0.2: I fixed the ordering calculation in the cloning functionality; the tests are a bit too forgiving for my taste now but I just can’t figure out why the gap for inserting cloned items is sometimes larger than it should be. It doesn’t matter though, since ordering values do not have any significance, they only have to provide a definite ordering for content items.
django-prose-editor 0.18.2: Cleaned up the documentation after the 0.18 cleanup (where automatic dependency management has been removed), fixed table styles when using dark mode.