Matthias Kestenholz

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.

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.

Avoiding empty JavaScript files in CSS-only entrypoints from rspack builds

2026-05-25T12:00:00Z

Avoiding empty JavaScript files in CSS-only entrypoints from rspack builds

I previously wrote about my preferred way of integrating Django with rspack. Minor aspects have changed, but most of it still applies.

What changed

The largest change is probably that I have switched from HtmlWebpackPlugin to rspack’s own HtmlRspackPlugin and have stopped configuring the template generated by it. Instead, I’m pulling out link, script, and style tags the Cthulhu way¹. My own mistakes while configuring rspack have led to missing or duplicated assets. Letting rspack do its thing and post-processing the result feels safer.

The rest basically stayed the same.

`RemoveEmptyJsAssetsPlugin`

Poking around in rspack’s compiler hooks isn’t documented all that well, so I’m documenting this plugin here. It’s very specific, but being able to change rspack’s output may be useful to others and to my future self.

When using a CSS-only entrypoint or when listing CSS files in entry, rspack sometimes decides it wants to generate an empty JavaScript file. This wouldn’t be a problem in and of itself, but since we’re also letting rspack generate the associated script tag, we will make the browser download this empty script file unnecessarily. I didn’t find a good way to avoid these empty files, and the RemoveEmptyScriptsPlugin for Webpack doesn’t work with rspack anymore. The discussion hasn’t gone anywhere yet. So, I had to use my own plugin. Since I’m already copying the rspack.library.js file into each project, adding a plugin there is no headache.

class RemoveEmptyJsAssetsPlugin {
  apply(compiler) {
    compiler.hooks.emit.tap(this.constructor.name, (compilation) => {
      const emptyJsFiles = new Set(
        Object.entries(compilation.assets)
          .filter(([name, asset]) => /\.js$/.test(name) && asset.size() === 0)
          .map(([name]) => name),
      )

      for (const file of emptyJsFiles) {
        delete compilation.assets[file]
      }

      for (const filename of Object.keys(compilation.assets)) {
        if (!filename.endsWith(".html")) continue
        let html = compilation.assets[filename].source()
        for (const jsFile of emptyJsFiles) {
          const idx = html.indexOf(jsFile)
          if (idx < 0) continue
          const start = html.lastIndexOf("<script", idx)
          const end = html.indexOf("</script>", idx) + "</script>".length
          html = html.slice(0, start) + html.slice(end)
        }
        compilation.assets[filename] = new rspack.sources.RawSource(html)
      }
    })
  }
}

The plugin has to be added to the plugins list:

plugins: [
  new RemoveEmptyJsAssetsPlugin(),
  // ...
],

And presto, no more empty JavaScript files!

Closing

Ideally, rspack will handle this itself at some point and make the plugin obsolete. For now, it works without issues in several projects.

It’s mostly fine in this case since the output is very limited and well-structured – we don’t have to guard against invalid HTML. ↩

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.

Note

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.

Podcasts I like listening to (2026 edition)

2026-02-13T12:00:00Z

Podcasts I like listening to (2026 edition)

I have published another post like this almost two years ago. I like listening to podcasts even more than I did back then, when I only just started diving into this world.

Sometimes I really like the silence. Other times, podcasts accompany my training regime, my chores and my (short) commute when I’m going to the office and not working from home.

Let me say that I’m not going to differentiate between technology, society, politics and other topics. Everything is political. Especially technology. This is something which could perhaps be overlooked from a privileged position many years ago, but that’s not possible anymore without willful ignorance.

I’ve tried organizing the podcasts according to my listening habits, the order within categories doesn’t have any particular meaning.

Never miss an episode

These are the podcasts I listen to every time they publish.

Tech Won’t Save Us

Tech Won’t Save Us is unfortunately even more relevant than it was back in 2024. The CEOs of the tech industry sat in the front row of the current president of the US of A’s inauguration and there’s really no way to overlook their allegiance.

The tech industry and the political project goes hand in hand, and we have to push back. This podcast offers practicable ways to do that and also provides a lot of background on what’s going on.

The Weekly Show with Jon Stewart

(The description on YouTube contains links to other platforms. I don’t actually listen on YouTube.)

How could you not like what Jon Stewart is doing? Back in the days, the Daily Show was my introduction to the world of humorous political and societal commentary. I also like the other hosts of the daily show, the long form interviews on the weekly show are something special though.

404 Media

I’m one of those people who do not read all the articles 404 Media publishes, but I’m definitely listening to the podcast episodes where they talk about the stories they wrote. They have recently started publishing a series of interviews where I’m more selective, though I’m interested often.

Gute Frage!

A new podcast from the makers of the Republik online newspaper. I hope they keep it going. I’m also diving into other podcasts from Republik.

Meyer:Wermuth

I’m not even a member of the party (SP/PS), but I know some of the politicians personally and the podcast is a good way to get their insights.

Le Show

Le Show was recommended by a good friend who has roots both in New Orleans and Switzerland. I like the way the show mixes critical commentary on Politics, the AI hype, our smart world, the church and other topics with great musical interludes.

Regular rotation

These are podcasts I usually listen to but might skip some episodes.

Trash Future

I don’t think the Future is trash and I somehow, maybe despite the fact that I sometimes feel I should know better, don’t believe it is bleak either. I don’t think the makers of these podcasts genuinely believe that either. That said, black humor helps with coping, therefore this is a listen I always look forward to.

Django Chat

I always have a great time listening to news about my favorite web framework and especially my favorite web framework community.

Volksverpetzer

Volksverpetzer is the anti fake news podcast by the german Volksverpetzer team. The name is hard to translate because it’s both a joke and a pun. I won’t even try to explain it and instead link to their own about us page.

Datenschutzplaudereien

This is still required listening for people working with customer data in Switzerland.

Soft Skills Engineering

This is always a nice listen. The podcast has been recommended by Tim I think. I have to say I almost always skip the first 5 minutes. The questions are great and there’s still a lot of banter to be had after the introduction.

Oxide and Friends

I could listen to Bryan talk all day long. I’m sure I’m not the only one, maybe he himself included.

Talk Python to Me

A well-established podcast about my favorite programming language with interesting discussions about Python and the broader ecosystem.

Selective/Topic-based

These are podcasts where I pick and choose episodes based on the topic or guest.

SRF Podcasts

There’s no single show I always listen to, but the selection is impressive. Interviews with leaders, philosophy, politics. I think it’s especially important to mention this in these days, because some people want to slash public funding for the fourth estate. It shouldn’t surprise anyone that those people are mostly aligned with the political right. They would probably like if billionaires had more power about our media as well. Let’s hope it doesn’t come to that and definitely throw in a resounding NO! in the public referendum coming soon.

Rust in Production

When Oxide and Friends are not talking about Rust I have to get my fix somewhere else. I don’t work with Rust but I think it’s currently one of the most genuinely interesting programming languages.

core.py

I didn’t find a site for this, but I like this established podcast about my favorite programming language.

DOS Game Club

This is a fun one, especially when I have played the game discussed in the past, but more often than not also when I didn’t.

The Ezra Klein Show

The podcast is often not critical enough for my taste, but some topics and guests are still really interesting and worth the listen.

Honorable mentions

These are podcasts I still like but listen to less frequently, or they serve a specific purpose in my current work.

Hanselminutes

A long-running technology podcast that I still enjoy when I catch an episode.

React Native Radio

I’m working on a large React Native project these days or months, and RNR is a way to learn more about this technology.

Weird Studies

I really like this podcast because of its strangeness, though I listen less than I did two years ago.

Leavers

Some podcasts are too lighthearted or too centrist for my taste and I have stopped listening to them, not as a statement, just as a fact. There’s no point in listing them, since they are well made and I think listening to them is still much better than losing interest in our society.

My 2025 in review

2026-01-14T12:00:00Z

My 2025 in review

I have been inspired by several posts where people reviewed the past year to write such a post too.

Vacations

I have been going snowboarding for the first time in many many years in February. I have been skiing and snowboarding a lot in my teens and twenties. After moving further away from the alps and also rupturing my cruciate ligament while playing Fussball (soccer) I have been less motivated to pursue these riskier sports and have instead mostly been running and biking. Some may argue if mountain biking really is less risky but for me that seems sort of obvious.

Anyway, the motivation to go hit the slopes again was that the kids wanted to go and leaving the gray city in winter is always a great idea.

My wife and me have also been in the black forest in Southern Germany twice at the beginning of the year and been spending time together in a nice hotel, eating great food and spending a lot of time in the spa.

In late April we went to Liguria, Italy as a larger group. We did cook a lot, went on a few bike rides along the coast and were even bathing in the Mediterranean Sea even though the water was very cold, at least for my taste (about 15°C).

I also went to France with friends several times for manual work and leisure. We are still in the middle of renovating and altering a house to fit our tastes better. It’s always interesting and a good diversion from staring at the computer all day long. I have helped with larger projects inside the house and also restored a few city bikes to full functionality after they were collecting dust and rust in a moldy cellar.

In October we went to Sitges near Barcelona with my parents-in-law. We took the train and spent the night in Lyon both ways. It’s possible to do the voyage in a single day, but we thought it’s nice to spend a little less time per day in the train and visit Lyon since I’ve never been there before. High speed train networks in Europe are great, but we had some bad luck with a total collapse of the timetable because a deer was hit by a train. Very sad for the deer and unfortunate for us. I thought about going to Django on the Med 🏖️ and it would have been really close, but it didn’t fit into the schedule very well with everything else which was already going on.

In Sitges the locals didn’t go to the beach anymore, maybe it was too cold for them or they just had enough after months of summer?

Sports and health

My full suspension bike was stolen in 2024 and I have been riding an old 26” hardtail in the meantime. I bought a relatively cheap 29” hardtail instead of a full suspension bike and have been enjoying the slightly more technical descents and the much improved climbing behavior a lot. The bike trails around here don’t really call for a full suspension bike; a lighter bike works nicely and I feel like I get more out of the same trail again.

Unfortunately, later during the year I herniated a disc in the lower back, and biking doesn’t really help there. It isn’t over yet but at least I have now started some strength training again. I don’t enjoy it too much but doing some exercises while listening to podcasts is actually fine. Also, the gym subscription includes access to the spa (sauna and steam bath) so it’s not too bad. I do hope and am working on enjoying that more. It’s not the first time that my back is in a bad shape despite the fact that I’m generally athletic, just not in a very balanced way it seems.

Gardening

Not much to tell. The year wasn’t excellent, but was good enough and we are still happy with our little garden.

The shed (it’s really not much more than that) is causing some headaches. I somewhat wish it would come crashing down so that we could build something simpler and smaller. The roof is bad. At least the wasps enjoy the wood and the niches in there. They weren’t aggressive towards us so it was fine leaving them there, after all, wasps are really valuable for the ecosystem.

Computering

I still do not enjoy the idea of working with LLMs but I admit that they are useful. I generally work on websites and webapps, but I’m currently working on a React Native project and I have to say the headstart I get with those tools is really quite enjoyable. I think the Oxide RFD on LLM usage offers some excellent guidance. Using LLMs for writing seems like a really stupid idea, since writing is thinking, and you don’t want to offload thinking to a machine. I want the machine to do the busywork.

Like probably many other people I have too many computers. My main working machine is still a Thinkpad X1 carbon with Fedora. I also have a Windows Notebook for some gaming; I enjoyed Doom: The Dark Ages a lot. Not as much as Doom Eternal, but that one will be really hard to top. I also use a Macbook now for the React Native project to be able to run all of the iOS tools. The Mac hardware is nice again after the butterfly keyboard disaster and the touch bar abomination. Battery life and performance are great. The macOS interface is jarring though, each time I use it I wish I was using GNOME, which – as a power user – I like a lot. At least there’s now an easy way to switch the keyboard layout to a Logitech/PC layout. Not because the PC layout would be better, just because I’m accustomed to it.

Apart from that the development setup is essentially unchanged.

Open source

I’m writing about that all the time on this blog, and I won’t even try giving an overview. I think it’s important to give everything else some space now.

Politics and society

I don’t really know how to say this. I’m offended that we live in a world where, instead of working together for a better future, we instead have to fight the slide back into authoritarianism and fascism. I’m not exactly surprised, but it’s hard to accept the news every day (or every week). I hoped for a better 2026 because the new year always has a promise for me that some new thing may happen. Let’s just say that the first two days of the new year were nice, and then I started reading the news again.

Not engaging with the world isn’t a choice I want to make either. So, all I can do is continue trying to make a difference.

Closing thoughts

Enough said. Let’s continue hoping for and working for a better 2026!

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.

Weeknotes (2025 week 35)

2025-08-29T12:00:00Z

Weeknotes (2025 week 35)

Summer was and is nice. The hot days seem to be over (for now), but in the last years summer hasn’t really left until the end of September, so we’ll see. I personally like the warm weather but I really hoped that our leaders were smarter. The climate emergency could be seen from far away. The pigheadedness is hard to stomach. And of course it’s not the only problem we’re facing as humanity at all.

Releases

I did some longer-form writing about two of the releases here: Menu improvements in django-prose-editor and django-content-editor now supports cloning of content

django-debug-toolbar 6.0: We have released a new version of the toolbar which supports persisting debugging data to the database. This is especially useful when using ASGI, because we cannot use threadlocal storage for this data then.
django-prose-editor 0.18: Reworked the menu system to support dropdowns, not just button groups. Added a custom TextClass extension which allows adding classes to spans and a NodeClass extension which allows adding classes to nodes. Tiptap supports adding arbitrary styles, I’d rather limit this a bit more and only offer predefined CSS classes.
django-content-editor 8.0: Added support for cloning content. Made the region tabs stick to the top of the browser window.
django-cabinet 0.18: Improved the folder deletion interface slightly.
django-mptt 0.18: I still seem to be maintaining the project even though I officially marked the project as unmaintained more than 4 years ago.

django-content-editor now supports cloning of content

2025-08-27T12:00:00Z

django-content-editor now supports cloning of content

What is the content editor?

Django’s builtin admin application provides a really good and usable administration interface for creating and updating content. django-content-editor extends Django’s inlines mechanism with an interface and tools for managing and rendering heterogenous collections of content as are often necessary for content management systems.

We are using django-content-editor in basically all projects, as a part of feincms3. The content editor is used not only for building page content, but also for blog entries, for building multi-step intelligent form wizards, for learning units and even to digitize teaching materials for schools, including static and interactive content.

The great thing about it is that it enables us to edit complex content inside Django’s administration interface without trying to replace it with a completely separate interface, as some other more well-known Django-based CMS want to do.

Cloning content

The complexity of managed content has grown a bit, especially since we introduced support for nesting sections. Teaching materials are often available in several learning levels, with only minor differences between them. Unfortunately, the differences aren’t purely additive: It’s not the case that higher levels just have more materials available. Otherwise, we’d probably have used a level on content items to hide content which shouldn’t be shown to students. Content is sometimes totally different. Because of this we’re using content editor’s regions for the learning level, one region per level.

Even then, the basic structure is often the same and building that manually for all levels is annoying at best. That’s why I finally got the occasion to add support for cloning content between regions to the editor.

Of course, cloning should also take the other features into account and allow selecting sections as a whole instead of having to select individual items. Here’s a screenshot of the current interface:

Closing thoughts

I’m still really happy with the content editor; I wish the Django admin would look a little bit nicer because then people would probably be more encouraged to actually learn how powerful it is. The first impression is unfortunately that it looks old and a bit too technical, but in my experience working with many many customers it’s not really the case. Most people are immediately able to work with it and find the interface well structured and appreciate the no bullshit attitude, because working with it really is efficient.