Matthias Kestenholz: Posts about feincms

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.

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).

Preserving referential integrity with JSON fields and Django

2025-06-04T12:00:00Z

Preserving referential integrity with JSON fields and Django

Motivation

The great thing about using feincms3 and django-content-editor is that CMS plugins are Django models – if using them you immediately have access to the power of Django’s ORM and Django’s administration interface.

However, using one model per content type can be limiting on larger sites. Because of this we like using JSON plugins with schemas for more fringe use cases or for places where we have richer data but do not want to write a separate Django app for it. This works well as long as you only work with text, numbers etc. but gets a bit ugly once you start referencing Django models because you never know if those objects are still around when actually using the data stored in those JSON fields.

Django has a nice on_delete=models.PROTECT feature, but that of course only works when using real models. So, let’s bridge this gap and allow using foreign key protection with data stored in JSON fields!

Models

First, you have to start using the django-json-schema-editor and specifically its JSONField instead of the standard Django JSONField. The most important difference between those two is that the schema editor’s field wants a JSON schema. So, for the sake of an example, let’s assume that we have a model with images and a model with galleries. Note that we’re omitting many of the fields actually making the interface nice such as titles etc.

from django.db import models
from django_json_schema_editor.fields import JSONField

class Image(models.Model):
    image = models.ImageField(...)

gallery_schema = {
    "type": "object",
    "properties": {
        "caption": {"type": "string"},
        "images": {
            "type": "array",
            "format": "table",
            "minItems": 3,
            "items": {
                "type": "string",
                "format": "foreign_key",
                "options": {
                    # raw_id_fields URL:
                    "url": "/admin/myapp/image/?_popup=1&_to_field=id",
                },
            },
        },
    },
}

class Gallery(models.Model):
    data = JSONField(schema=gallery_schema)

Now, if we were to do it by hand, we’d define a through model for a ManyToManyField linking galleries to images, and adding a on_delete=models.PROTECT foreign key to this through model’s image foreign key and we would be updating this many to many table when the Gallery object changes. Since that’s somewhat boring but also tricky code I have already written it (including unit tests of course) and all that’s left to do is define the linking:

Gallery.register_data_reference(
    # The model we're referencing:
    Image,
    # The name of the ManyToManyField:
    name="images",
    # The getter which returns a list of stringified primary key values or nothing:
    getter=lambda obj: obj.data.get("images"),
)

Now, attempting to delete an image which is still used in a gallery somewhere will raise ProtectedError exceptions. That’s what we wanted to achieve.

Using a gallery instance

When you have a gallery instance you can now use the images field to fetch all images and use the order from the JSON data:

def gallery_context(gallery):
    images = {str(image.pk): image for image in gallery.images.all()}
    return {
        "caption": gallery.data["caption"],
        "images": [images[pk] for pk in gallery.data["images"]],
    }

JSONPluginBase and JSONPluginInline

I would generally do the instantiation of models slightly differently and use django-json-schema-editor’s JSONPluginBase and JSONPluginInline which offer additional niceties such as streamlined JSON models with only one backing database table (using proxy models) and supporting not just showing the primary key of referenced model instances but also their __str__ value.

The example above would have to be changed to look more like this:

from django_json_schema_editor import JSONPluginBase

class JSONPlugin(JSONPluginBase, ...):
    pass

JSONPlugin.register_data_reference(...)

Gallery = JSONPlugin.proxy("gallery", schema=gallery_schema)

However, that’s not documented yet so for now you unfortunately have to read the code and the test suite, sorry for that. It’s used heavily in production though so if you start using it it won’t suddenly start breaking in the future.

django-content-editor now supports nested sections

2024-09-13T12:00:00Z

django-content-editor now supports nested sections

django-content-editor (and it’s ancestor FeinCMS) has been the Django admin extension for editing content consisting of reusable blocks since 2009. In the last years we have more and more often started automatically grouping related items, e.g. for rendering a sequence of images as a gallery. But, sometimes it’s nice to give editors more control. This has been possible by using blocks which open a subsection and blocks which close a subsection for a long time, but it hasn’t been friendly to content managers, especially when using nested sections.

The content editor now has first-class support for such nested sections. Here’s a screenshot showing the nesting:

Finally it’s possible to visually group blocks into sections, collapse those sections as once and drag and drop whole sections into their place instead of having to select the involved blocks individually.

The best part about it is that the content editor still supports all Django admin widgets, as long as those widgets have support for the Django administration interface’s inline form events! Moving DOM nodes around breaks attached JavaScript behaviors, but we do not actually move DOM nodes around after the initialization – instead, we use Flexbox ordering to visually reorder blocks. It’s a bit more work than using a ready-made sortable plugin, but – as mentioned – the prize is that we don’t break any other Django admin extensions.

Simple patterns

I previously already reacted to a blog post by Lincoln Loop here in my post My reaction to the block-driven CMS blog post.

The latest blog post, Solving the Messy Middle: a Simple Block Pattern for Wagtail CMS was interesting as well. It dives into the configuration of a Wagtail stream field which allows composing content out of reusable blocks of content (sounds familiar!). The result is saved in a JSON blob in the database with all the advantages and disadvantages that entails.

Now, django-content-editor is a worthy competitor when you do not want to add another interface to your website besides the user-facing frontend and the Django administration interface.

The example from the Lincoln Loop blog post can be replicated quite closely with django-content-editor by using sections. I’m using the django-json-schema-editor package for the section plugin since it easily allows adding more fields if some section type needs it.

Here’s an example model definition:

# Models
from content_editor.models import Region, create_plugin_base
from django_json_schema_editor.plugins import JSONPluginBase
from feincms3 import plugins

class Page(models.Model):
    # You have to define regions; each region gets a tab in the admin interface
    regions = [Region(key="content", title="Content")]

    # Additional fields for the page...

PagePlugin = create_plugin_base(Page)

class RichText(plugins.richtext.RichText, PagePlugin):
    pass

class Image(plugins.image.Image, PagePlugin):
    pass

class Section(JSONPluginBase, PagePlugin):
    pass

AccordionSection = Section.proxy(
    "accordion",
    schema={"type": "object", {"properties": {"title": {"type": "string"}}}},
)
CloseSection = Section.proxy(
    "close",
    schema={"type": "object", {"properties": {}}},
)

Here’s the corresponding admin definition:

# Admin
from content_editor.admin import ContentEditor
from django_json_schema_editor.plugins import JSONPluginInline
from feincms3 import plugins

@admin.register(models.Page)
class PageAdmin(ContentEditor):
    inlines = [
        plugins.richtext.RichTextInline.create(models.RichText),
        plugins.image.ImageInline.create(models.Image),
        JSONPluginInline.create(models.AccordionSection, sections=1),
        JSONPluginInline.create(models.CloseSection, sections=-1),
    ]

The somewhat cryptic sections= argument says how many levels of sections the individual blocks open or close.

To render the content including accordions I’d probably use a feincms3 renderer. At the time of writing the renderer definition for sections is a bit tricky.

from feincms3.renderer import RegionRenderer, render_in_context, template_renderer

class PageRenderer(RegionRenderer):
    def handle(self, plugins, context):
        plugins = deque(plugins)
        yield from self._handle(plugins, context)

    def _handle(self, plugins, context, *, in_section=False):
        while plugins:
            if isinstance(plugins[0], models.Section):
                section = plugins.popleft()
                if section.type == "close":
                    if in_section:
                        return
                    # Ignore close section plugins when not inside section
                    continue

                if section.type == "accordion":
                    yield render_in_context("accordion.html", {
                        "title": accordion.data["title"],
                        "content": self._handle(plugins, context, in_section=True),
                    })

            else:
                yield self.render_plugin(plugin, context)

renderer = PageRenderer()
renderer.register(models.RichText, template_renderer("plugins/richtext.html"))
renderer.register(models.Image, template_renderer("plugins/image.html"))
renderer.register(models.Section, "")

Note

A better way to to this is documented in the API docs, specifically RegionRenderer.render_section_plugins.

(Note added in Oct 2025.)

Closing thoughts

Sometimes, I think to myself, I’ll “just” write a “simple” blog post. I get what I deserve when using those forbidden words. This blog post is neither short or simple. That being said, the rendering code is a bit tricky, the rest is quite straightforward. The amount of code in django-content-editor and feincms3 is reasonable as well. Even though it may look like a lot you’ll still be running less code in production than when using comparable solutions built using Django.

Weeknotes (2023 week 42)

2023-10-18T12:00:00Z

Weeknotes (2023 week 42)

Vacation in Italy

We have spent a wonderful family week in Italy. The voyage by train was very comfortable and we had a great time there. I have lived close to lakes all my life but the sea is always something else. Now I enjoy the cold temperatures of fall.

Going back (forward) to GitJournal

I have tried several note taking apps but I’m now back using GitJournal with a Git repository filled with Markdown notes. It works well enough. I just wish that there was a way to make notes more distinguishable and I wish that the editor was more forgiving when encountering badly formatted checklists.

Analog blogging

I have long wanted to write about our switch from Slack to Discord. I have started to write this post with pen and paper. I find that I think better when using pen and paper than when using the computer keyboard. One factor is certainly that the computer offers more distractions, but I suspect that another, more important factor is that as a fast typist the fingers and the thinking are always getting out of step, and this happens less when using a slower method of writing. This actually isn’t an idea I had myself, but I don’t remember where I got it from.

Zero-based versioning: Good or bad?

I discovered ZeroVer sometime in the last few days. I have many many Django packages with zero-based versions. Some of them have been used in production for years now. I sometimes wonder if staying with 0. is unprofessional and I should just release 1.0 and be done with it or if it doesn’t really matter at all.

If I evaluate software packages more often than not I don’t look at the version number or the version numbering scheme (except when a package is still using 0.0.) when deciding whether to rely on it or not. The documentation and the code itself are much more important to me.

Releases

I haven’t uploaded any releases in the last 14 days. That’s good: I’m one of those people who have made their passion their job (which is great) but that sometimes makes it hard to not work at all since I can always tell myself that I’m not working, that it’s just a hobby.

Weeknotes (2023 week 40)

2023-10-04T12:00:00Z

Weeknotes (2023 week 40)

More work on hosting several websites from a single Django application server using feincms3-sites

I have mentioned feincms3-sites last week in my last weeknotes entry; I have again given this package a lot of attention in the last days, so another update is in order.

It is now possible to override the list of languages available on each site. That’s especially useful for an upcoming campaign site where the umbrella group’s site is available in three languages, but (most?) individual group sites (hosted on subdomains) will only have a subset of languages. Since I live in a country with four national languages (english isn’t one of them, but is spoken by many!) supporting more than one language, or even many languages is totally commonplace. It’s great that Django has good support for internationalization. For the sake of an example, I have the following sites:

example.com: The default. The host has to match exactly.
subdomain.example.com: One individual group’s site. The host has to match the regex ^subdomain\. (sorry, I actually do like regexes).

Overriding configured hosts for local development

One thing which always annoyed me when using django.contrib.sites was that “just” pulling the database from production to the local development environment always produced links pointing back to the remote host instead of working locally (when producing absolute URLs). This problem was shared by feincms3-sites as well. I have now found a very ugly but perfectly workable solution: Overwrite Site.get_host() locally:

if DEBUG:
    domain = "example.com"  # Or whatever
    _get_host = lambda site: site.host.replace(domain, "localhost:8000")
    FEINCMS3_SITES_SITE_GET_HOST = _get_host

This works especially well when using example.com and maybe subdomains of example.com: All absolute links will point to localhost:8000 or subdomain.localhost:8000. Since *.localhost always resolves to the local IP the browser knows where it should connect to, and since subdomain.localhost:8000 also matches the ^subdomain\. regex mentioned above, the site selection logic works as well.

Of course if you have more domains, not just subdomains, you could adapt the get_host override and the relevant regexes to those use cases.

Closing words

We’re at 100% code coverage now when running the test suite. That’s really nice.

Logging into the Django admin using your Google account

This functionality has long been provided by django-admin-sso; however, as mentioned a long time ago this package still uses a deprecated OAuth2 library. django-authlib supports using a Google account to authenticate with the Django admin since 2017. I have now fixed a small problem with it: If you are logged into a single Google account, and this account’s email address doesn’t match the configured admin login rule, you were out of luck: There was no way to add another account at that time because the library didn’t request the account selection. That has changed now, if the first login attempt doesn’t work, it now explicitly tells Google to let the user select their Google account. A small quality of life improvement for those using more than one Google account (voluntarily or not).

Releases

feincms3 4.4.3: Polished the CKEditor integration a little bit. Re-enabled the source button now that we’re back to using the classic iframe-based editor again.
feincms3-sites 0.19.3: See above.
django-authlib 0.16.4: See above.

Weeknotes (2023 week 39)

2023-09-28T12:00:00Z

Weeknotes (2023 week 39)

Again a few weeks have passed since the last weeknotes entry :-)

Moving feincms3 repositories into the feincms organization

The feincms GitHub organization has seen more active days when FeinCMS 1.x was still actively developed. Since my interest has moved to feincms3 some years ago I haven’t kept the organization up to date. That has changed this week, and I have moved most feincms3-related repositories into the organization.

This move doesn’t change much though, but it certainly feels more official now.

Adding scheduled tests

I have started using the cronjob schedule feature of GitHub actions to ensure that tests run at least once a month in a few important projects. I want to get notified of changes in Django@main affecting my packages not only when actively working on them. I try to keep up with Django@main in all packages I maintain.

Releases

feincms3-sites 0.18.2: Many releases in the last weeks. Stopped using permanent redirects in DEBUG mode. Avoid migrations when Django adds more languages. Added utilities which allow restricting model relations to objects in the same site (trickier than it sounds). Added utilities for building full URLs to other sites without taxing the database as much.
feincms3-language-sites 0.2.0: No biggie. No permanent redirects in DEBUG mode anymore.
feincms3-cookiecontrol 1.4.5: Reduced the byte size of the CSS and JavaScript some more. Added spanish translations.
django-authlib 0.16.3: I have published a post last week describing the new role-based permissions feature.
django-imagefield 0.17: The process_imagefields management command now allows specifying globs. If you wanted to prerender all imagefields in the pages app you can use ./manage.py process_imagefields pages.* now instead of listing all image fields’ labels explicitly.
feincms3 4.4.1: I’m enormously unhappy but I had to go back to the classic CKEditor instead of using the inline editor. The latter looked much nicer but overriding the Django admin CSS was very very painful. Also, I can totally understand why CKEditor 5 is completely different and why CKEditor 4 is only maintained in a paid LTS plan. It still is making me look for alternatives.
django-mptt 0.15: I unfortunately am still using this despite the fact that I have marked it as officially unmaintained since march 2021. I did a mediocre job of making the library run on Django@main again. Parts of the library do not work, but since I’m not using them I don’t care too much. I’m still wondering if someone wants to take over maintenance of the library since it still seems to be actively used in projects of others as well. When I don’t have to use django-mptt I’m still really happy with django-tree-queries.
form-designer 0.22: This is probably my oldest actively developed project these days. 13 years! (Except for django-content-editor of course.) I have modernized the package, switched to hatchling and put out a new release.

Keep content managers' admin access up-to-date with role-based permissions

2023-09-20T12:00:00Z

Keep content managers’ Django admin access up-to-date with role-based permissions

Django’s built-in permissions system is great if you want fine-grained control of the permissions content managers should have. The allowlist-based approach where users have no permissions by default and must be granted each permission individually makes a lot of sense to me and is easy to understand.

When we build a CMS at Feinheit we often use the Django administration panel as a CMS. Unfortunately, Django doesn’t provide a way to specify that content managers should have all permissions in the pages and articles app (just as an example). Adding all current permissions in a particular app is straightforward when using the filter_horizontal interface but keeping the list up-to-date later isn’t. When we add an additional content block plugin we always have to remember to also update the permissions after deploying the change – and often, deployment happens some time after the code has been written, e.g. because clients want to approve the change first. What happens all too often is that the manual step of updating permissions gets forgotten.

This has annoyed me (intermittently) for a long time and my preferred solution has always been to give superuser permissions to everyone and trust them to not make changes which they aren’t supposed to according to the Trusted Users Editing Structured Content principle which was mentioned in a Django book I read early in my Django journey.

The basic ideas of my role-based permissions implementation

A recent project has resurfaced this annoyance and I did finally bite the bullet and implement a solution for this in the form of a django-authlib extension. The basic ideas are:

All users are assigned a single role: Single roles sound inflexible, but is good enough for my default use case. Examples for roles could be default (no additional permissions granted), content managers (grant access to the pages and articles apps) or maybe deny auth (deny access to users, groups and permissions).

The permission check is implemented using a single callable: A custom backend is provided whose only job is to call the correct callable for the user’s current role.

The callable either returns a boolean or raises PermissionDenied to prevent other backends from granting access: No new ideas here, it’s exactly what Django’s authentication backends are supposed to do.

Permission checkers for the most common scenarios are bundled: django-authlib only ships one permission checker right now, allow_deny_globs, which allows specifying a list of permission name globs to allow and to deny. Deny overrides allow as is probably expected.

Using roles in your own project

Specify the available roles in your settings and add the authentication backend:

from functools import partial
from authlib.roles import allow_deny_globs
from django.utils.translation import gettext_lazy as _

AUTHLIB_ROLES = {
    "default": {"title": _("default")},
    "staff": {
        "title": _("editorial staff"),
        "callback": partial(
            allow_deny_globs,
            allow={
                "pages.*",
                "articles.*",
            },
        ),
    },
}

AUTHENTICATION_BACKENDS = (
    # This is the necessary additional backend
    "authlib.backends.PermissionsBackend",
    # Maybe you want to use authlib's email authentication ...
    "authlib.backends.EmailBackend",
    # ... or the standard username & password combination:
    "django.contrib.auth.backends.ModelBackend",
)

You have to extend your user model (you have to use a custom user model if you’re not using django-authlib’s little_user.User):

from authlib.roles import RoleField

class User(AbstractUser):
    # ...
    role = RoleField()

And that’s basically it.

Of course the globbing is flexible, you could also allow users to view all objects:

partial(allow_deny_globs, allow={"*.view_*"})

Or you could block users from deleting anything:

partial(allow_deny_globs, deny={"*.delete_*"})

And as mentioned above, you can also combine allow and deny (deny wins over allow) or even provide your own callables. If you provide your own callable it must accept user, perm and obj (which may be None) as keyword arguments. Implementing such a callable is probably less work than implementing an authentication backend yourself; I had to do more work than initially expected because only implementing .has_perm isn’t sufficient if you want to see any apps and models in the admin index page. The current allow_deny_globs implementation is nice and short:

def allow_deny_globs(user, perm, obj, allow=(), deny=()):
    for rule in deny:
        if fnmatch(perm, rule):
            raise PermissionDenied
    return any(fnmatch(perm, rule) for rule in allow)

My reaction to the block-driven CMS blog post

2023-08-23T12:00:00Z

My reaction to the block-driven CMS blog post

This morning I read an interesting post on the Lincoln Loop blog called Building a Future-Proof Platform with Block-Driven CMS. It shouldn’t come as a surprise to those (few 😄) who know my work in the area of content management systems that the post resonated with me. I found the description of the advantages of block-based CMS editing very clear and I like the emphasis on structuring data well so that it can be reused for multiple distribution channels.

Of course django CMS isn’t the only way to implement a block-driven CMS using Django. Since its inception FeinCMS was always the smaller, faster and nimbler counterpart to it, achieving the same basic goals with a fraction of the code and maintenance headaches. django CMS always seems to trail the official releases of Django. django-content-editor and feincms3 are almost always compatible with the development version of Django by way of running the tests with the main branch as well. This allows me to be an early adopter of upcoming Django releases with a software stack that’s already well tested, or also to report bugs to the Django project itself. All that probably wouldn’t be possible if feincms3 and its dependencies supported all the things django CMS does, but it doesn’t have to to be useful.

django-content-editor and feincms3 are the legacy of FeinCMS in an even smaller, even more maintainable and even more composable package and while I’m definitely always checking out other Django-based CMS I’m persuaded that sticking with feincms3 is a good choice.

Weeknotes (2023 week 33)

2023-08-20T12:00:00Z

Weeknotes (2023 week 33)

I’m not sure if I should call these posts weeknotes when I see the posting schedule, but oh well. Keep expectations up but also practice forgiveness when not meeting them, it’s fine really.

`py_modules` using hatchling

I converted speckenv and django-sitemaps after finding the following very helpful post on packaging projects consisting of Python modules without any packages: Packaging of single Python module projects with Hatch/Hatchling. It’s very easy in hindsight, but that’s basically always the case.

The relevant part is including the files in the build:

[tool.hatch.build]
include = [
  "speckenv.py",
  "speckenv_django.py",
  "speckenv_django_patch.py",
]

That’s all.

I have also started investigating what would have to be changed in django-debug-toolbar to make it fully support async Django. We currently patch Django’s database cursors per thread, which works fine in sync Django land to attribute SQL queries to a particular request/response cycle.

Since async Django executes DB queries in a thread pool executor and the rest of the work happens inside awaitables (async land) I don’t immediately see a way how we could do the same thing. It doesn’t seem possible to find out which task spawned another task (without dropping down to C?) but maybe there’s something I’m overlooking. I hope that someone smarter than me finds a way :-) or that I find the time and motivation to either find a way using Python or using C/Rust/whatever.

Releases

feincms3-sites 0.16: I added basic support for i18n_patterns when using feincms3-sites with its default_language_middleware (which allows setting a default language per site in case there is no other mechanism overriding it, such as i18n_patterns).
feincms3-cookiecontrol 1.4.1: The privacy policy is now linked inside the banner text instead of adding a link after the text. Looks much nicer.
speckenv 5.0: Finally released changes made a long time ago which make one edge case when parsing settings less surprising.
django-debug-toolbar 4.2: I didn’t do much work here again, mostly code reviews, some changes to the ruff configuration and general polishing. I also didn’t do the release itself, that was handled by Tim. Thanks!
FeinCMS 23.8: Fixes for Pillow 10, and some feincms3 / django-content-editor interoperability improvements which make it easier to reuse plugins/content types.
feincms3 4.1: Some basic support for using the apps middleware with async Django. Not documented yet and not deployed anywhere but it basically works. Some documentation edits and changes to the inline CKEditor styling because of the recent changes to Django admin’s CSS.

Composition over inheritance: The case for function-based views

2023-08-11T12:00:00Z

Composition over inheritance: The case for function-based views

A recent conversation with Carlton on Mastodon prompted me to write down some of my thoughts re. function- vs class-based views in Django.

The early days

When I started using Django some time after 0.96 and 1.0 all views were function based. Except when you added a class with a def __call__() method yourself – that was always possible but not really comparable to today’s class-based views.

The introduction of class-based views

Class based views (both generic versions and the base View) were introduced to Django in 2010. Judging from the ticket tracker the main motivation was to avoid adding yet another argument to the generic function-based views (GFBV) which were available in Django back then.

The GFBV’s argument count was impressive. Two examples follow:

def object_detail(request, queryset, object_id=None, slug=None,
    slug_field='slug', template_name=None, template_name_field=None,
    template_loader=loader, extra_context=None,
    context_processors=None, template_object_name='object',
    mimetype=None):
    ...

def archive_month(request, year, month, queryset, date_field,
    month_format='%b', template_name=None, template_loader=loader,
    extra_context=None, allow_empty=False, context_processors=None,
    template_object_name='object', mimetype=None, allow_future=False):
    ...

The GFBVs were immediately deprecated when GCBVs were introduced and later removed in 2012.

Class-based views have to be adapted by calling the View.as_view() method; as_view() returns arguably the thing which is viewed (sorry) as the view by Django, it’s the thing which gets called with a request and is expected to return a response. This thing in turn instantiates the view object once per request; this means that self can be used to save request-specific data such as self.request, self.args but also custom attributes.

The GCBV code is extremely factored and decomposed. The Classy Class-Based Views site mentions that the UpdateView has 10 separate ancestors and its code is spread across three files. But, the view code for instantiating a model object and handling a form really isn’t that complex. Most of the complexity is handled by Django itself, in the request handler and in the django.forms package. So, what’s the reason for all this?

Generic views could be simple

I wish that the existing generic views had better building blocks instead of a big hierarchy of mixins and multiple inheritance which is probably not understood by anyone without checking and re-checking the documentation, the code, or the excellent Classy Class-Based Views. Certainly not by me.

In my ideal world, generic views would be composed of small reusable and composable functions which wuld cover 80% of use cases with 20% of the code. And if not, you could copy the whole code of the view, change or introduce a line or two and leave it at that. And since the functions do one thing (but do that well) you can immediately see what they are doing and why. You’d avoid the Hollywood Principle (Don’t call us, we’ll call you) in your code. Sure, your view is called by Django but you don’t have to introduce more and more layers of indirection.

The internet is full of advice that you should prefer composition over inheritance. Let’s try to outline what generic views could look like if they followed the composition paradigm. Note that the goal isn’t to gain points by showing that the resulting code is shorter. One important goal is maintainability by being easier to understand. Another important goal is showing a better path from a beginner’s use of views to an experts understanding of everything underneath it by bridging the gap using more powerful building blocks which don’t leave all the minutiae to you if the defaults don’t work.

Some repetition caused by copy pasting is fine. Not all identical three lines of code are the same. The Three Strikes And You Refactor rule¹ leads to better and more maintainable code than following an extreme interpretation of the DRY (Don’t Repeat Yourself) principle.

ListView and DetailView

I’m going to profit from Django’s shortcuts module and also from feincms3’s shortcuts module which offers functions for rendering pages for single objects or lists of objects. The render_list and render_detail functions implement the same way of determining the template paths as the generic views use (for example <app_name>/<model_name>_detail.html) and the same way of naming context variables (object and <model_name> for the object, object_list and <model_name>_list for the list) as well as pagination but nothing more.

Here’s a possible minimal implementation of a list and detail object generic view:

# _get_queryset runs ._default_manager.all() on models and returns
# everything else as-is. It's the secret sauce which allows using models,
# managers or querysets with get_object_or_404 and friends.
from django.shortcuts import get_object_or_404, _get_queryset
from feincms3.shortcuts import render_list, render_detail

def object_list(request, *, model, paginate_by=None):
    return render_list(request, _get_queryset(model), paginate_by=paginate_by)

def object_detail(request, *, model, slug, slug_field="slug"):
    object = get_object_or_404(model, **{slug_field: slug})
    return render_detail(request, object)

You want to change the way a single object is retrieved? You could do that easily but not by adding configuration-adjacent values in your URLconf but rather by adding a view yourself:

def article_detail(request, year, slug):
    object = get_object_or_404(Article.objects.published(), year=year, slug=slug)
    return render_detail(request, object)

urlpatterns = [
    ...
    path("articles/<year:int>/<slug:slug>/", article_detail, name=...),
    ...
]

I don’t think that was much harder than a hypothetical alternative:

urlpatterns = [
    ...
    path(
        "articles/<year:int>/<slug:slug>/",
        object_detail,
        {
            "model": Article.objects.published(),
            "object_kwargs": ["year", "slug"],
        },
    ),
    ...
]

And think about the internal implementation of the object_detail view. Viewed one additional feature at a time it may be fine but when adding up everything it would probably be quite gross.

The additional benefit is that it shows beginners the way to intermediate skills – writing views isn’t hard, and shouldn’t be.

Finally, the official way of overriding DetailView.get_object() (I think!) doesn’t look that good compared to the def article_detail() view above:

class ArticleDetailView(generic.DetailView):
    def get_object(self, queryset=None):
        if queryset is None:
            queryset = self.get_queryset()
        return get_object_or_404(queryset, year=self.kwargs["year"], slug=self.kwargs["slug"])

Did you know that get_object() has an optional queryset argument? I certainly didn’t. It seems to be used by the date-based generic views but they also have their own get_object() implementation so who knows, really.

Detail view with additional behavior

def article_detail(request, year, slug):
    object = get_object_or_404(Article.objects.published(), year=year, slug=slug)
    data = (request.POST, request.FILES) if request.method == "POST" else ()
    form = CommentForm(*data)
    if form.is_valid():
        form.instance.article = object
        form.save()
        return HttpResponseRedirect(".#comments")
    return render_detail(request, object, {"comment_form": form})

A counterexample would be to move the endpoint which accepts a comment POST request somewhere else. But then you’d also have to keep the different CommentForm instantiations in sync.

You could also override get_context_data() to add the comment form to the context and override post() to instantiate check the form’s validity. But then you’d have to make sure that an eventual invalid form is handled correctly by get_context_data(). It’s not hard but it certainly isn’t as straightforward as the example above either.

The custom view is the most obvious way of keeping the form instantiation in one place.

Form views

Generic create and update views could look something like this, again reusing the shortcuts mentioned above:

def save_and_redirect_to_object(request, form):
    object = form.save()
    return redirect(object)

def get_form_instance(request, *, model, form_class, instance=None):
    assert model or form_class, "Provide at least one of model and form_class"
    if form_class is None:
        form_class = modelform_factory(model)
    data = (request.POST, request.FILES) if request.method == "POST" else ()
    return form_class(*data)

def object_create(request, *, model=None, form_class=None, form_valid=save_and_redirect_to_object):
    form = get_form_instance(request, model=model, form_class=form_class)
    if form.is_valid():
        return form_valid(request, form)
    return render_detail(request, form.instance, {"form": form}, template_name_suffix="_form")

def object_update(request, *, model, slug, slug_field="slug", form_class=None, form_valid=save_and_redirect_to_object):
    object = get_object_or_404(model, **{slug_field: slug})
    form = get_form_instance(request, model=object.__class__, form_class=form_class, instance=object)
    if form.is_valid():
        return form_valid(request, form)
    return render_detail(request, form.instance, {"form": form}, template_name_suffix="_form")

You want to redirect to a different URL and maybe emit a success message? Easy:

def article_form_valid(request, form):
    form.save()
    messages.success(request, _("Successfully updated the article."))
    return redirect("articles:list")

urlpatterns = [
    ...
    path(
        "<slug:slug>/update/",
        object_update,
        {"model": Article, "form_valid": article_form_valid},
        name=...
    ),
    ...
]

Yes, these generic views wouldn’t allow overriding the case when a form was invalid. But, I’d assume that displaying the form with error messages is the right thing to do in 90% of the cases. And if not, write your own specific or generic view? After all, with the mentioned tools it won’t take up more than a few lines of straightforward code. (If the code was tricky it would be different. But views shouldn’t be tricky.)

Adding more form_valid handlers should be mostly painless. A few examples inspired by Django’s generic editing documentation:

def save_and_redirect_to(url):
    def fn(request, form):
        form.save()
        return redirect(url)
    return fn

def send_mail(request, form):
    form.send_email()
    return HttpResponseRedirect("/thanks/")

def set_author_and_save(request, form):
    form.instance.created_by = request.user
    object = form.save()
    return redirect(object)

You could also couple the form a bit to the request and do something like:

def process_form(request, form):
    return form.process(request)

Sure, forms probably shouldn’t know much about requests. But then, Django is a framework for perfectionists with deadlines and sometimes practicality beats purity.

Date-based generic views

I think I would want to offer a few analyzers which allow easily returning a data structure suitable for rendering links for yearly, monthly, weekly or even daily (who writes that much?) archives. The .dates() queryset method method should be a big help there.

The archive views themselves are straightforward adaptations of the object_list view above.

It may feel like leaving out the actually hard part but I’d have to be convinced that this is actually a hard problem and not just a problem of making basically arbitrary choices which people then adapt to and then think that this is the way things should be since it’s the way things are.

Wrapping up

Some points this post could have made or tried to make are made much better by Luke Plant in the guide Django Views - The Right Way. I don’t generally think that class-based views never make sense. I also don’t think that people shouldn’t use the available tools. I just think that I, myself, don’t want to use them, and I also think that I’m still happier with lambda request: HttpResponseRedirect(...) than with generic.RedirectView.as_view(url=...). The point isn’t to compare the character count. The point is: Does the RedirectView cause a permanent or a temporary redirect? I had to look it up for a long time, and then it changed. The former is completely obvious.

Closing words

I know that people have strong opinions. I’m not interested in all of them. I’m mostly interested in design critiques and arguments regarding the beginner to intermediate skills argument. It’s fine if CBVs work fine for you, and there’s no need to feel challenged by this post.

Thanks for reading!

Also called the WET rule (Write Everything Twice). (Not coined by me.) ↩

Weeknotes (2023 week 30)

2023-07-28T12:00:00Z

Weeknotes

Async Django

I have used Django Channels successfully in a few projects from 2017 to 2019. A few months back I have worked with Starlette. And now I have finally started digging into using Django itself with an ASGI server, and not just for one or two views but also including the middleware stack etc since I also need authentication, not just an endpoint forwarding requests to a remote server. I have looked at Granian, an RSGI/ASGI server written in Rust. But for now I am using uvicorn.

Django truly has come a long way but there’s much left to do. Django 5.0 is looking great already, but 4.2 misses many pieces still. I am really really glad Django wants to stay backwards compatible but I wish I could wave a magic wand and upgrade everything to async. Adding a prefixes everywhere for the async version is certainly a good compromise and probably the way to go but it’s just not that nice.

I have been playing around with making feincms3’s applications middleware async compatible because I want the full middleware stack to be async. The code is already released but undocumented and not even mentioned in the changelog. So, feel free to play around with it but it’s not supposed to be stable or supported yet.

Releases

feincms3 4.1: Switched to hatchling and ruff. Updated the feincms3-sites docs. Some async updates mentioned above. A Django 4.2 admin CSS update for the inline CKEditor.
feincms3-forms 0.4: Switched to hatchling and ruff. Started defining default icons for the form fields content editor plugins.
django-ckeditor 6.7: I’m still maintaining the CKEditor 4 integration for Django even though CKEditor 4 itself isn’t supported anymore. Minor updates to the editor itself and Pillow compatibility updates.
feincms3-cookiecontrol 1.3.2: The cookie banner doesn’t generate an empty <div class="f3cc"> element anymore if there’s nothing to add inside (e.g. if the user only accepted necessary cookies).

Weeknotes (2023 week 28)

2023-07-12T12:00:00Z

Weeknotes (2023 week 28)

Releases

html-sanitizer 2.2: Made the sanitizer’s configuration initialization more strict. Strings cannot be used anymore in places where the sanitizer expects a set (resp. any iterable). It’s useful that strings are iterable in Python and I wouldn’t want to change that, but the fact that ("class") is a string and not a tuple makes me sad. The fact that tuples are created by , and not by () will always trip up people.
feincms3-language-sites 0.1: The version number is wrong but whatever. I’m certainly happy with the state of things. The big change in 0.1 is that Page.get_absolute_url no longer generates protocol-relative URLs. Depending on the value of SECURE_SSL_REDIRECT it automatically prepends either http: or https:.
django-authlib 0.15: django-authlib’s admin Single Sign On module now supports a hook to automatically create staff users when a matching user doesn’t exist already. I don’t plan to use this functionality myself and I have recommended people to implement the functionality themselves using the tools in django-authlib if they need it, but the change was so small and well-contained that adding it to the core made sense to me.

pipx inject

We learned that pipx seems to remember injected packages even across pipx reinstall invocations. Not too surprising now that we know it, but we certainly spent some time scratching our heads. pipx uninject was the thing we needed to stop pipx from installing an old version of a dependency instead of the one being specified in pyproject.toml.

hatchling and data files

I’m very confused by the way hatchling sometimes includes data files and sometimes it doesn’t. I had to add [tool.hatch.build] include=["authlib/"] to django-authlib’s pyproject.toml file to make it include HTML files from subpackages. Maybe the subpackages are the reason, but I’m not sure.

Payment providers that must not be named

I have spent hours and hours battling with the badly documented, incomplete, inconsistent and confusing API of a (not that well known) payment provider based in Switzerland. I’m surprised that this still happens years and years after Stripe started offering a really well thought out and documented API geared towards programmers. It’s really sad because when the same structure is named with differing naming conventions (e.g. snake_case vs. camelCase) in different parts of the API you just know that somebody spent too much time writing too much code instead of reusing already existing functionality.

Weeknotes (2023 week 26)

2023-06-30T12:00:00Z

Weeknotes (2023 week 26)

Releases

I released updates to a few of my packages; I have continued converting packages to hatchling and ruff while doing that.

New releases in the last two weeks include:

django-tree-queries 0.15: Added a new function, .without_tree_fields() to the queryset which can be used to avoid the .with_tree_fields(False) boolean trap warning.
feincms3-cookiecontrol 1.3.1: This small update allows replacing the feincms3 noembed.com oEmbed code using other libraries such as micawber which support a wider range of URLs while still gating the embed behind users’ explicit consent.
feincms3-downloads 0.5.3: Updated translations.
django-ckeditor 6.6.1: Updated the bundled CKEditor 4 and merged a pull request adding better integration with Django admin’s dark mode.
django-js-asset 2.1: Just basic maintainability and packaging updates. The JS() implementation itself is untouched since February 2022.
html-sanitizer 2.0: Not really a backwards incompatible change (at least not according to the tests); I just wanted to avoid 1.10 and go directly to 2.0 this time.

GitHub projects

We are using GitHub project boards more and more. It definitely isn’t the most versatile way of managing projects but it sort-of hits the sweet spot for us. I’m mostly happy with it, and it seems to me that applying the rule of least power to project management software may not be such a bad idea after all.

The built-in workflows are a bit boring and limited; especially the fact that it seems impossible to automatically add issues to the project when using multiple repositories. Luckily, actions/add-to-project exists so that’s not really a big problem.

To cloud or not

I had a long discussion with a colleague about containerization, Kubernetes, self-hosting, etc. etc. and I still don’t know where I stand. I can honestly say that the old way of hosting (ca. 2010) still works fine. I worry about the deterioriation of service quality we’re seeing and sometimes I really would like to have root to apply quick fixes where now I have to jump to hoops just to get what I already know I need. Annoying. But migrations are annoying as well.

Scheduled publishing

I augmented the script generating this website with scheduled publishing support while again reducing the number of lines in the file. The code is still formatted using black and ruff, while only ignoring line-length errors (I do this everywhere now to avoid breaking up long strings, not to put much code onto single lines) and allowing named lambdas. The weeknotes from two weeks ago where published by GitHub actions’ cron scheduling support.

I like programming more than writing (even though I like writing)

I notice that writing is the first thing I start skipping when I have to prioritize. Programming, biking, gardening come first. That’s fine, really. But I’m still a bit sad that I do not manage to at least put out a short weekly weeknotes entry.

FeinCMS is a dead end (but feincms3 is not)

2023-06-19T12:00:00Z

FeinCMS is a dead end (but feincms3 is not)

I wouldn’t encourage people to start new sites with FeinCMS. Five years ago I wrote that FeinCMS is used in a few flagship projects which we’re still actively developing, which means that FeinCMS won’t be going away for years to come. That’s still true but less and less so. We’re actively moving away from FeinCMS where we can, mostly towards feincms3 and django-content-editor.

FeinCMS lives on in django-content-editor and feincms3; not only in spirit but also in (code) history, since django-content-editor contains the whole history of FeinCMS up to and including the beginning of 2016.

The implementation of FeinCMS is too expensive to clean up without breaking backwards compatibility. I still wish I had pursued an incremental way back then which would have allowed us to evolve old projects to the current best way of doing things (tm), but it didn’t happen and I’m not shedding too many tears about that since I’m quite happy with where we’re at today.

That basically means that I won’t put any effort into bringing FeinCMS and django-content-editor closer together. I haven’t spent much time on that anyway but now my mind is made up that this wouldn’t be time well spent. That being said, some of the items mentioned in the blog post linked above are available in django-content-editor now.

Weeknotes (2023 week 24)

2023-06-16T12:00:00Z

Weeknotes (2023 week 24)

Life happened and I missed a month of weeknotes. Oh well.

We have released django-debug-toolbar 4.1. Another cycle where I mostly contributed reviews and not much else. Feels great :-)

Going all in on hatch and hatchling

I got to know hatch because django-debug-toolbar was converted to it. I was confused as probably anyone else with the new state of packaging in Python world. After listening to a few Podcasts (for example Hatch: A Modern Python Workflow) I did bite the bullet and started converting projects to hatch as mentioned some time ago. I have converted a few other projects in the meantime because the development experience is nicer. Not much, but enough to make it worthwile. feincms3-sites is the latest package I converted.

CKEditor 5’s new license and django-ckeditor

The pressure is on to maybe switch away from CKEditor 4 since it probably will not be supported after June 2023. It’s totally understandable that the CKEditor 5 license isn’t the same as before, but I’m not sure what that means for the Django integration django-ckeditor which I’m maintaining since a few years. I don’t actually like the new capabilities of CKEditor all that much and don’t intend to use them; maybe it would be better to use a build of ProseMirror in the CMS since we’re intentionally only using a very small subset of the features most rich text editors offer.

Mountain biking.

My mountain bike is repaired, I’m back on the trail.

CSS variables and immutability

2023-06-14T12:00:00Z

Using CSS variables 1 to ship customizable CSS in Django apps

I have been working with SASS for a long time but have been moving towards writing CSS with a few PostCSS goodies in the last years. At first, I just replaced the $... with var(--...) and didn’t think much about it. The realization that CSS variables can be more than that came later. Edit basic values directly in the browser and immediately see the results! Change CSS depending on media queries or the cascade!

With all that power came back the wish to not just ship backend and HTML code in Django apps I (help) maintain but also reusable CSS, with a few overrideable CSS variables for basic changes to the visual style. Loading .scss files from somewhere inside venv/lib/python3.11/site-packages/<package>/styles/ would of course have been possible, but very obscure. Also, not everyone puts their virtualenv at venv, the README instructions for those packages would quickly have become unwieldy. CSS variables paved the way for shipping CSS as a Django static file while still allowing customizability by leveraging the functionality of the browser itself instead of the frontend build toolchain.

Patterns for overrideable values

A pattern for defining defaults for CSS variables is to always define the fallback (the example is intentionally bad but inspired by real world experiences when developing feincms3-cookiecontrol):

.box {
  background: var(--box-background, #222);
  color: var(--box-foreground, #fff);
}

Less repetition (but trouble awaits)

If --box-background isn’t set the var() function falls back to the second argument, #222. Repeating this value over and over gets annoying quickly, so you define a few defaults on the :root element and use those variables in the code, without specifying the default again:

:root {
  --box-background: #222;
  --box-foreground: #fff;
}

.box {
  background: var(--box-background);
  color: var(--box-foreground);
}

The project can now override the default background color using:

:root {
  --box-background: #444;
  --box-foreground: #ccc;
}

Of course now you’re back at the mercy of CSS loading order. If the app’s CSS is loaded first, everything works. If not, your custom value is immediately overwritten. You could avoid this by overwriting the default lower in the cascade:

.box {
  --box-background: #444;
  --box-foreground: #ccc;
}

Great, everything works again!

Later, the box also contains a button which uses a different background but the same foreground, so of course we add more variables in the package:

:root {
  --box-background: #222;
  --box-foreground: #fff;
  --box-button-background: #333;
  --box-button-foreground: var(--box-foreground);
}

What happens now when overwriting the --box-foreground variable just for the .box element?

You’re not sure? I certainly wasn’t and am not. But what I remember happening was that the overridden foreground color was just applied to the text and not to the button itself. I was confused (it seems clearer in hindsight…)

A better way

If values are supposed to be overridden and only used inside components, a better way is to define local CSS for components by following a convention (underscore prefix for local/private variables):

/* Defined on .box, not :root */
.box {
  --_background: var(--box-background, #222);
  --_foreground: var(--box-foreground, #fff);
  --_button-background: var(--box-button-background, #333);
  --_button-foreground: var(--box-button-foreground, var(--_foreground));
}

And then you only use the prefixed versions inside the component:

.box {
  background: var(--_background);
  color: var(--_foreground);
}

.box__button {
  background: var(--_button-background);
  color: var(--_button-foreground);
}

The --box-* variables are undefined by default; the only time when they are set is when the user of the package wants to override those values. If you only overide the box foreground the button also inherits the new foreground color. And while there would certainly be a way to achieve the same thing with the old way above it’s certainly not as simple to explain.

The reason why it’s simple to explain is immutability. The CSS variables which are overrideable by the user are only ever read by the package, never written to.

Custom properties would probably be the more correct naming, but CSS variables is nicer to say. ↩

Weeknotes (2023 week 18 and 19)

2023-05-12T12:00:00Z

Weeknotes (2023 week 18 and 19)

Not much programming this week :-(

oEmbed

Still occupying myself with oEmbed. I have been looking at a few libraries and have rediscovered micawber which probably does everything I need. Yay, another reinvented wheel avoided. I haven’t tested it yet but I’m quite sure that replacing the oEmbed functionality in feincms3’s external plugin with micawber would be a good idea.

Vacation

Vacation last week. Was nice. We went for a few hikes. I have learned that I’m not totally free from giddiness anymore. Oh well.

Weeknotes (2023 week 17)

2023-04-28T12:00:00Z

Weeknotes (2023 week 17)

Birthday

Another year achieved. Feels the same as last year. I’m glad.

feincms3-cookiecontrol

I have released feincms3-cookiecontrol 1.3. Mostly cleanups since 1.2, but also a new translation (already announced here). The script size has been reduced from 4519 bytes to 4228 bytes (-6.5%) while keeping all features intact. The reduction is totally meaningless but it was fun to do.

oEmbed

I have been digging into the oEmbed spec a bit. I didn’t even know that a central list of providers exists. Noembed still works great to embed many different types of content but I worry more and more about its maintenance state. Reimplementing the interesting parts shouldn’t be that hard, but maybe I don’t have to do this myself. oEmbedPy looks nice, I hope I get a chance to play around with it.

Weeknotes (2023 week 15)

2023-04-16T12:00:00Z

Weeknotes (2023 week 15)

Romansh translations for feincms3-cookiecontrol and django-fineforms

The feincms3 cookie control banner and django-fineforms have received a small update: Support for the Romansh language. I would be surprised if any readers of this blog even knew about this language at all. Switzerland has four official languages: German, French, Italian and the mentioned Romansh.

It’s not a coincidence of course that those two packages have received an update at the same time. Both packages are used for an upcoming campaign site where people may express their support for political action to preserve or protect the biodiversity. It’s at the same time laughable and horrifying that this is even a thing though: Who in their right mind could NOT agree that preserving biodiversity is important? It’s incomprehensible. Maybe I’m just a romantic Gutmensch after all…

django-ckeditor

I have set up the stale GitHub action for the django-ckeditor repository. So many support requests, so little time and almost no actual collaborators. Also, many support requests actually concern CKEditor itself, not its Django integration. I shouldn’t complain though, CKEditor has served me well and still does, especially when it’s being used with a very minimal configuration which basically makes most pain points of HTML editors go away.

I have reviewed and merged a few changes to django-debug-toolbar in the last week. Still a fun project, especially since it’s so widely used and loved.

Matthias Kestenholz: Posts about feincms

Rich text editors: How restrictive can we be?

Thoughts about Django-based content management systems

Preserving referential integrity with JSON fields and Django

django-content-editor now supports nested sections

Weeknotes (2023 week 42)

Weeknotes (2023 week 40)

Weeknotes (2023 week 39)

Keep content managers' admin access up-to-date with role-based permissions

My reaction to the block-driven CMS blog post

Weeknotes (2023 week 33)

Composition over inheritance: The case for function-based views

Weeknotes (2023 week 30)

Weeknotes (2023 week 28)

Weeknotes (2023 week 26)

FeinCMS is a dead end (but feincms3 is not)

Weeknotes (2023 week 24)

CSS variables and immutability

Using CSS variables1 to ship customizable CSS in Django apps

Weeknotes (2023 week 18 and 19)

Weeknotes (2023 week 17)

Weeknotes (2023 week 15)

Using CSS variables 1 to ship customizable CSS in Django apps