Discussing rich text capabilities in a CMS is an exercise in compromise. Authors want the flexibility to be creative in their content. Developers want to ensure said content fits in the box. This can feel like fighting over the bed covers with a spouse: everyone initially means well, but things turn sour and we all wish for a bigger duvet. Or a more understanding spouse.

I believe the fundamental problem is one of control – for end users, control over content formatting, and predictability of the overall system. And for developers, control over content processing and rendering. Let’s crack open the rich text black box, and give everyone their fair share of the duvet.

Have you ever worked with rich text editors? You know how frustrating of an experience that can be. Users enter content without much confidence in how the editor will preserve it. Developers have to harden their sites to handle the unstructured soup that is rich text. Designers see their layout completely destroyed by the cheer variation in shape and length. A recipe for frustration.

It’s time to add some noodles and flavour, give some structure to our bland broth and enjoy rich text again.

Developers love to automate things. Shave yaks. Automation can save tremendous time, but automating complex processes can also be a big time sink. This is a story in compromise.

The other thing developers love is free software. I love GitHub, Travis, and Heroku because they all provide a very generous free usage tier – let’s have a look at how we can leverage them to automate preview environments (think: preview the result of a new pull request) for Wagtail, a project I frequently contribute to.

A disclaimer – the end result isn’t full automation, it still is a manual process. We shall call this semi-automated preview environments.

Ever heard of Draft.js? We are rebuilding Wagtail’s rich text content management using this rich text editor framework from Facebook. Apart from a new editor, Draftail, we also needed an exporter to convert Draft.js content to HTML: the aptly-named draftjs_exporter.

In this post I’ll focus on this critical piece of the puzzle, which needs to operate as fast as possible regardless of how much content it has to handle. Memory profiling and benchmarks in a Python ecosystem were new to me, so here is what I learned along the way.

First draft of what could have been a very cool checklist for dataviz efforts where the data is also made reusable.