Rotatio (en)

Multiplane – a frontend on top of Cockpit CMS

2026-09-28T01:12:19Z

Tags: frontend, framework, PHP, JavaScript, HTML, CSS, Cockpit CMS, CMS
Start: 20.02.2019
End: 05.02.2024
Roles: developer

Multiplane is a lightweight PHP frontend – based on the headless Cockpit CMS. It was never meant as a one-click solution, but as a base for developers, who like to fiddle, to create individual websites.

Unfortunately, it never took off. After ~~wasting half a decade of my life~~ many iterations of learning and fine-tuning, I had to stop. The project heavily relied on internal APIs – and Multiplane became incompatible with Cockpit version 2.

Toggle table of contents

What I’ve learned

A lot! About object oriented programming, error handling, reactive UI frameworks, open source licenses, user interaction, writing documentation, weird edge cases and much more…

Communicating in English with people from all around the globe was a great experience. At some point I noticed, that my restricted vocabulary wasn’t too small. It was actually the right amount to chat with other non-native speakers.

Finding and solving bugs, helping others, seeing my own source code being used by others felt great. Now I know, how content management systems work. I touched all parts, wrote many of them myself, read vendor libraries and fixed bugs over there.

Everything’s great, right? Some hard learned lessons:

Writing a CMS is too big for one person. Also for two. And probably for three.

Don’t use internal APIs! (Well…, I still do. But I keep the number low and add code comments with warnings now.)

Avoid vendor lock-in! Always! And keep the number of dependencies low.

Accessibility doesn’t work as an after-thought.

There is no such thing as an “open source community”. Rarely, I encounter beautiful people and have intense, eye-opening conversations. Sometimes, I can peek in a brilliant mind by reading their source codes. Often, I lose faith in humanity. Mostly it’s reclusive, sometimes lonely – or para-social.

Don’t use an open source project as the primary source for your self-esteem. You may break with the next vendor update. As a general rule: Don’t derive your self-esteem from a single source – not from work, not from a single person, not from your pet project. Or as marketers would say: diversification is key.

What I’ve done

I wrote a head for a headless CMS. “Why reinventing the wheel?” you may ask.

In short: I wasn’t able to find an existing system, that matched my goals:^[1]

Privacy by design and by default
Developer friendly
- no plugins needed to deactivate half of the core features
- ability to adjust everything
- theming without div soup
Clean backend for my clients
Structured data to keep the system and data portable and future proof
Modular and reusable code
Semantic html, responsive css, usable without JavaScript
Multilingualism by design

Long answer: In the past, I mostly worked with WordPress and the static site generator (SSG) jekyll. Sometimes I had a look at different systems.

I liked jekyll’s data structure. Personally, I don’t have a problem with writing text in markdown, changing a data set in YAML or adding missing (liquid) templates matching that change. But you can’t expect this from non-programmers. They need a well-arranged user interface. Also, I missed forms without loading third party services via JavaScript – an unsolved problem of all SSGs. And… it’s written in Ruby, which I never learned or even touched. I can’t write or modify plugins.

WordPress seems to be user friendly – as long, as your data fits their predefined structure. It’s not developer friendly: more than 2.000 functions in the global scope, backwards compatibility to the outdated PHP5, many similar named functions, no output buffer. Their plugin ecosystem is full of adware and bloatware. No sensibility for privacy (e. g. Google fonts, Gravatar), security issues… the list goes on.

With Cockpit, I found the ideal backend. It’s easy to extend, stores data in a structured way and provides multiple interfaces to query that data. While exploring it, I discovered a lot of on-board tools – for building a frontend.

My first prototype was Monoplane, only useful for simple, single-language portfolio websites. It evolved to CpMultiplane – later renamed to Multiplane – with many more features like multilingualism, full-text search and custom post types.

Components

Multiplane is both: a wrapper (or framework) and a Cockpit addon. It loads Cockpit as a library, sets some constants, changes a few variables and than registers itself, the module Multiplane.

Cockpit CMS (backend)

Cockpit is headless without a frontend. It is created for pure data management in a structured way and has multiple interfaces to get or change that data. Multiplane uses the PHP API for the frontend and the default user interface as backend.

The most important libraries are already included, but in total it was kept clean and simple. It’s modular, event based and was made to be customized.

Multiplane (frontend)

This module is the gateway between backend (Cockpit) and frontend (Multiplane) to create different configuration profiles or to adjust the user interface.

It also takes care of translating url paths into database request and to deliver the data as HTML.

UniqueSlugs addon

By default, Cockpit only provides cryptic strings as unique identifiers. This addon creates unique, human-readable and SEO-friendly url parts from page titles (called “slug”).

FormValidation addon

Cockpit’s core Forms module is quite rudimentary. The FormValidation addon provides a form builder and validator.

Other addons

Incomplete list of more useful addons:

ImageResize to handle different image formats (thumbnail, medium, big) automatically
rljUtils for useful helpers, UI adjustments and security fixes in multi-user setups
VideoLinkField to extract information and download thumbnails from videos on YouTube or Vimeo
EditorFormats (by Paulo Gomes) to fine-tune the WYSIWYG editor

Base and child theme

Multiplane ships with one base theme, creatively named “rljbase”, that serves as skeleton for child themes and provides:

template files for most use cases (using “Lexy” templating, part of Cockpit v1’s core)
a rudimentary, responsive layout (CSS)
a lightweight JavaScript library mp.js

It works without JavaScript, but without JS, some features would be missing:

simple cookie management
handling privacy events (cookie banner when embedding third-party resources)
video embedding
- without JS: display linked thumbnail to video
- with JS: emit privacy event for user consent before embedding
simple image lightbox
simple mail address protection (converts obfuscated addresses to valid ones)
preventing a :target jump in the pure CSS mobile navigation^[2]

CpMultiplane docs with the "docs" child theme. A two-column layout with a wide content area with light background and a thin, dark sidebar on the left with logo, search bar and a vertical navigation.

Resources

Multiplane on Codeberg
Thread in Cockpit forum about Monoplane and Multiplane
Thread in Cockpit forum about why I left
Multiplane docs repository (website with docs is offline)
inofficial docs for Cockpit v1 by zeraton (official v1 docs are offline)
Cockpit v1 source code
official Cockpit website

Footnotes

Accessibility wasn’t part of my listed goals back than. ~~Shame on me.~~ Better late than never. ↩︎
At that time, I was a bit obsessed with (ugly) CSS hacks to avoid JS wherever possible. Nowadays, I prefer progressive enhancement – with functional pure HTML/CSS defaults and fancy JS behavior. ↩︎

Cockpit – a headless, API-first CMS

2026-09-28T01:12:19Z

Tags: PHP, headless, CMS, Riot.js, Vue.js, UIkit, Cockpit CMS
Start: 31.05.2018
End: 26.11.2023
Roles: code contributor, addon developer, forum moderator

Cockpit is a headless Content Management System (CMS), developed by Artur Heinze. The core is written in PHP and it has a permissive license (MIT). “Headless” means: backend for data and content, but no inbuilt frontend for websites.

This article focuses mostly on Cockpit v1. Soon after the rewrite to v2, I left the project.

Toggle table of contents

My role

For multiple years, I helped as a volunteer to move the project forward. I fixed bugs, helped sorting out missing or outdated documentation, reported multiple security issues and wrote many addons.

After a few months, I became moderator in their community/support forum. Moderating was a low effort. The user base is small and – as I observed in many development focused forums – the troll count was immensely low. Mostly I helped explaining (hidden) core concepts or solving weird edge cases. To be honest: helping strangers was one motivation, but solving random code puzzles was the real fun. The forum and issue section became my favorite place for procrastination.

It was an interesting and intense time of my life.

Some numbers

1 Frontend written
23 Addons, 2 of them compatible with v2
51 Pull Requests for v1 (31 merged, 5 open, 15 closed)
66 Issues opened for v1
13 Pull Requests for v2 (8 merged, 1 open, 4 closed)
21 Issues opened for v2

And I’m always astonished, when looking at my forum statistics:

636 days visited
4 days read time
916 topics viewed
3.1k posts read
28 likes given
215 likes received
36 topics created
467 posts created
66 solutions

How Cockpit works

As mentioned, it’s headless. Cockpit focuses on data modeling and providing interfaces to access that data:

Admin panel: graphical user interface (GUI) for creating collections, modeling and maintaining data
REST API: access to data sets from outside, secured with API keys
CLI: many tasks can be done and automated via command line
as PHP library: access to all modules, functions and data with custom-made applications

The admin panel (backend) can be modified with addons. A frontend can be written in any language, accessing data via REST API. When frontend and backend live on the same server, they can communicate directly via PHP API or even via CLI.

At its’ core, Cockpit speaks JSON – or more specifically: MongoDB. Everything is document-oriented. Coming from SQL, I had to readapt:

No relations: e. g. renaming a category means changing a string in all documents. This can be automated using the event system to check for changed categories after saving. But without shifting the mental model to a non-relational database, these things were confusing.
Syntax and logic: applying filters ($and, $or) instead of trying to translate WHERE clauses.

And – although Cockpit speaks MongoDB – it comes with an abstraction layer (MongoLite) to use SQLite as database. And I like SQLite: no server, no passwords, no sql export before and after changing things in a local development setup – just copy and paste.

Why I chose it

In May 2018, after moving from WordPress to Github Pages (jekyll) with prose.io as UI, I searched again for alternatives. Until then, the term “headless” never crossed my mind. After knowing, what I was looking for, the concept convinced immediately.

Self-hosting and a permissive license were mandatory and I was most skilled in PHP – which left only two options: Cockpit and Directus^[1]. Both had Gravatar implemented. I asked for an option to disable it, to respect users’ privacy. A few hours later, Artur committed an update and disabled it completely. Months later, I got an answer from Directus. They never thought about Gravatar being a privacy problem and considered changing it.

Obviously, my decision was long done.

Why I left

From the beginning, I was more interested in the PHP (and the CLI) API, than in the REST API. On top of the headless Cockpit CMS v1, I wrote my own frontend (head) Multiplane. So my usage was unusual, not like intended. But I always cared about the headless paradigm when writing addons.

Over the years, I had a deep understanding of all internals. My ecosystem relied on Cockpit’s configurability and hackability. Then Cockpit grew up. Version 2 was released. It looked nice and I liked many changes. Most of my addons could have been rewritten for compatibility, but Multiplane became incompatible. I really tried to find workarounds, but it was unfixable. My vision of Cockpit didn’t match Artur’s anymore.

For a while, I kept a fork of Cockpit v1 alive – until I had to admit, that years of my work became worthless. Sure, I learnt a lot. And I don’t blame Artur for moving forward and building a stable business model. But it still hurts.

On top of that:

V2 re-introduced a security issue and multiple accessibility issues, I fixed in v1 already – very annoying.
Some core addons became proprietary, which was fine in general. But I couldn’t skim git diffs anymore to understand the motivation for some random looking core changes. Also annoying.
Multilingualism was poorly implemented.
Accessibility was clearly an after-thought.

In the forum thread about my reasoning for leaving, I go into more (technical) details.

Addons

Some of my addons were used in production for years, some were experimental and unfinished.

Babel: Manage translations of addons and modules; addon for Cockpit CMS v1 and v2
BetterMarkdown: Cache, tasks lists and table of contents for markdown conversion; addon for Cockpit CMS v1
BlockEditor: Visual block editor; draft/experimental; addon for Cockpit CMS v1
BootManager: addon dependency management, module loading order, conditional loading; draft/experimental; addon for Cockpit CMS v1
DashboardGrid: Custom dashboard with grid; addon for Cockpit CMS v1
Feed: RSS Feeds for collections; draft/experimental; addon for Cockpit CMS v1
FormValidation: Form validator and form builder; addon for Cockpit CMS v1
ImageResize: Resizes uploaded images automatically to predefined sizes; addon for Cockpit CMS v1
Migrate: Migrate and convert models, data, accounts etc. from Cockpit CMS v1 to v2.; draft/experimental, never published as official addon; addon for Cockpit CMS v1 and v2
ModuleLink: Field with linked data from modules; draft/experimental; addon for Cockpit CMS v1
MoreOptions: Utility addon with more options (collection grouping, color picker); draft/experimental, mostly superseded by rljUtils addon; addon for Cockpit CMS v1
Multiplane addon: Frontend logic (head) for the headless Cockpit CMS; addon for Cockpit CMS v1
MultiplaneDocsMods: Modifications for Multiplane docs; simple 2-way bind between markdown files and SQLite database; addon for Cockpit CMS v1
phpLiteAdmin: phpLiteAdmin interface for debugging and data inspection; addon for Cockpit CMS v1
rljUtils: Utility addon with security hardening, cosmetics and helpers; addon for Cockpit CMS v1
SelectRequestOptions: Select field with options based on custom requests; addon for Cockpit CMS v1
SheetExport: Spread sheet export (csv, odt, xls, xlsx); draft/experimental; quickly modified version of the sheet export from my Tables addon; addon for Cockpit CMS v1
ShowInMenu: re-enable the feature to display collections etc. in the system menu; superseded by rljUtils addon; addon for Cockpit CMS v1
SimpleImageFixBlackBackgrounds: provides a modified SimpleImage library to prevent black backgrounds in transparent images on some systems with a non-bundled PHP-GD version (really nasty bug); addon for Cockpit CMS v1
Tables: Manage SQL tables with 1:m and m:n relations; addon for Cockpit CMS v1
UniqueSlugs: generates unique url paths (called “slugs”) from page titles; addon for Cockpit CMS v1
VideoLinkField: extract, download and store thumbnails and meta data from videos on YouTube and Vimeo; addon for Cockpit CMS v1
WhiteLabel: Custom logo and custom colors; addon for Cockpit CMS v1

Other stuff

Cockpit v1 fork: Fork of Cockpit CMS v1 (next branch); stable release for usage with composer and PHP 8.1; contains some improvements from v2
Cockpit scripts repository: A collection of code snippets and notes to modify Cockpit CMS v1 and v2
WPMultiplane: Cockpit CMS v1 and Multiplane implementation as a WordPress plugin; draft/experimental; still not sure, if brilliant or utterly stupid

Footnotes

This was before their complete rewrite to node.js. ↩︎

How I developed an ADHD friendly fitness routine

2026-09-01T01:24:43Z

Tags: ADHD, routines, ADHD strategies

Recently I scrolled through social media and got stuck on a simple question by @c0debabe:

Anyone have any ADHD friendly fitness tips or resources?

Three hours later (instant hyper focus), my deconstruction was done. Now (three days later doing other stuff) I finally finished this text.

Toggle table of contents

Solution

It must be fun, short and daily. I practice 10 minutes. Every morning. Before anything else.

Fun

You’ll never see me jogging or going to the gym. But I love dancing – in my case: playing Hula Hoop and Dragon Staff.

Short

It’s short enough to:

get started without being overwhelmed
do it while other things seem more important
pull through the last 4 minutes when I’m already bored or feel sick

It’s long enough to see and feel an effect.

Daily

And it’s daily! If I forget it once, I still practice a whole hour per week. Missing a weekly one-hour session instead would halve the overall time. Missing a weekly routine twice probably ends it for all eternity.

How I got there

It evolved from a daily reminder (10 minutes during the day). Often I didn’t practice. Instead of feeling bad, I tried to double the time after a missed day.

I coupled it with watching news (another task checked) or with procrastinating on YouTube (didn’t feel bad afterwards, because at least I practiced).

At some point I finally realized, that mornings are a useless time span. I literally can’t think. But I’m able to move. So I replaced 10 minutes of staring into the void with training.

After realizing, that my emotions are tightly coupled to music, I added “5 minutes listening to music” to my daily tasks. Now I could check two daily tasks after one training session from my list. Watching news moved to the morning bath routine.

Goals helped a lot. After committing to a show at an open stage, I had to practice multiple times per week. Goal: being able to speak after 10 minutes of movement.

Some more iterations, some more goals, a lot more awareness about myself… Now every day starts with 30 minutes of training and dancing. Maybe I’ll up it to 40 minutes soon. If I’m in a rush, 10 minutes is the minimum. Not debatable.

Side effects

Making it a habit solved many problems:

An empty, useless time span every morning is filled with something healthy, that I enjoy.
Training, dancing and music help me to get awake. Often I’m able to think in less than two hours.
Making decisions – especially in the morning – is exhausting. Because it’s a strict routine, I don’t have to decide anything. When I bust myself debating about something more important, I remember the reasons: I need it to stop staring into the void and to be able to make decisions. Realizing it and maintaining my routine makes me happy.
Some days are useless. Nothing works. But at least I practiced.
Finishing two tasks (music, training) from my daily reminder – every morning – causes a small dopamine spike.
The music stays on after practicing and causes dancing during breakfast. Nice! Sadly, it also has bad side effects:
1. I can’t hear my shower timer anymore (can live with that).
2. I don’t hear my coffee sizzling. This is dangerous (fire involved, old gas stove). If I don’t eat nearby, I have to remember to start the coffee timer. I accept that risk.
After a few months I really know my old music library. I listened to albums, I heard decades ago, which brought back childhood memories or great moments at concerts.
The last thing I want to do in the morning is tidying up. So I always clean my living room to have enough space for training tomorrow.

Conclusion

“Just” make it a habit. To get there, combine fun, multiple goals and other side effects.

Accept, that a new routine will break some others. When you notice it, deconstruct it (writing, talking).

Really: make notes! In a few months or years, that beautiful daily training routine will suddenly fade away. Some side effect may be lost or not important anymore. But they were essential to start the routine. Using full-text-search in my notes folder helps to find the lost path. Now I can try to replace anchor points to get started again. Or I just needed that reminder (loved to do that thing every day in the past, but randomly stopped months ago) to restart the routine immediately.

It’s that easy ;-)

Trivia

Three days ago, I allowed myself to have a break. No obligations, no appointments, nothing urgent (OK, my plan was to clean up – nothing very urgent). So I scrolled through social media, read blogs and got stuck on that question.

A few lines became an article. After pausing my “monthly task” of publishing a blog post for four months, this felt great. Also I planned to write about my ADHD strategies anyways, but didn’t expect it to be in English (new task: translate it to German). Because of that sudden instant hyper focus, I forgot to finish my morning routine (brushing teeth, watching news). Also I forgot to eat. Because I didn’t go to the supermarket (part of the plan to tidy up), I ate muesli for lunch after 7pm – which caused heartburn (hungry and no time to soak because the supermarket closed at 9pm).

During the last hours, to finish this post, I learned a lot. About the blockquote’s cite attribute or the cite tag. I started to read a blog post about @matuzo’s head section I found in @c0debabe’s feed – and was able to stop that side quest. Then I found a bug in markdown-it-attr in combination with markdown-it’s linkify inline parser, read many lines of source code and found a workaround (new task: open bug report).

Keep this in mind, if you want to trust my advice about building routines ;-)

But at least I practiced this morning.

Multiple domains, rewrite rules and localhost

2025-11-18T20:10:35Z

Tags: Uberspace, htaccess

So yesterday I finally published this shiny, new website. After weeks of work to tell 11ty to match (most of) my expactations it felt like a relief. But a new problem came up: redirecting some of my other domains to this site.

As mentioned in my last post (de), I have a small collection of domains. One is only used for mails: raffaeljesche.de. Another one from my first website verstyler.de, abandoned for a few years and re-acquired recently, collects dust, too. Both should redirect to rotatio.de now.

The following text is very technical. I expect you to know about the basics of:

Now let’s move on (if you’re still interested).

Options

INWX url redirect in DNS settings
- This is not real DNS. It just looks like it in the user interface.
- Causes missing SSL certificate issues when typing https://example.com (with s) directly in the browser address bar. Just typing example.com without protocol hides this problem, because the first redirect on an INWX server is unencrypted.
point domains (with and without www.) to Uberspace
- Uberspace takes care of Let’s Encrypt certificates automatically (Uberspace docs: https
- causes duplicated content if not redirected properly

My old strategy

Uberspace has one real document root in /var/www/virtual/$USER/html/. By default, all domains point to this directory. If a folder /var/www/virtual/$USER/example.com exists, the site is served from over there. $_SERVER['DOCUMENT_ROOT'] still points to the real document root /var/www/virtual/$USER/html/. This can cause issues for some applications and may need a RewriteBase / in .htaccess, but all my files are static html files, so I don’t care. Apache can take care of the domain redirects by adding a .htaccess to all (sub) domain directories on my Uberspace.

.htaccess file:

# redirect all other domains (e. g. $USER.uber.space, www subdomain)
RewriteEngine On
RewriteCond %{HTTP_HOST} !=rotatio.de
RewriteRule (.*) https://rotatio.de/$1 [R=301,L]

Folder setup:

# https://rotatio.de (synced with 11ty output directory)
/var/www/virtual/$USER/html/

# https://www.rotatio.de
/var/www/virtual/$USER/www.rotatio.de/.htaccess

# https://rotatio.uber.space (default Uberspace user domain)
/var/www/virtual/$USER/rotatio.uber.space/.htaccess

This setup can be simplified by creating only one folder and creating symlinks for all domains to that directory. This strategy is nice, because I don’t have do deal with modifying .htaccess files provided by a CMS (which might change with an update unexpectedly).

When pointing some more (outdated) domains to this setup, it becomes messy:

# https://raffaeljesche.de
/var/www/virtual/$USER/raffaeljesche.de/.htaccess

# https://www.raffaeljesche.de
/var/www/virtual/$USER/www.raffaeljesche.de/.htaccess

# https://verstyler.de
/var/www/virtual/$USER/verstyler.de/.htaccess

# https://www.verstyler.de
/var/www/virtual/$USER/www.verstyler.de/.htaccess

Now I don’t use a CMS and I have full control on my settings. So I thought, I could skip the manual process of creating all these empty folder duplicates, that only exist for redirecting.

The problem with `.htaccess`

It’s complicated.

Sadly, while researching, Cloudflare was down (again) and with it half of the internet. Multiple search results weren’t accessible and the htaccess testing tool suddenly stopped working because it’s API requests were down too.

Some useful information from a Stack Overflow post didn’t work for me, but at least their server was online. And I found another thread on Stack Overflow with many tips for debugging .htaccess files.

Luckily I remembered, that I solved this problem in the past already – and I found a note from 2020. It needed some refactoring, but it showed me the missing piece: I forgot to match the port number while testing. So checking against localhost etc. always failed while running on http://localhost:8080.

Changes to my old note:

don’t use 301 for all domains, only for www subdomain
use 302 redirect instead for other domains
check against 127.x.x.x range instead of 127.0.0.1
added check against 192.168.x.x range

The final config:

<IfModule mod_rewrite.c>
	RewriteEngine on

	# Redirect all other domains (e. g. $USER.uber.space, www subdomain)
	# Checking for HTTPS or port 443 is not needed, because Uberspace doesn't
	# support unencrypted connections and they renew Let's Encrypt certificates
	# automatically.

	# 301 for www subdomain
	RewriteCond %{HTTP_HOST} =www.rotatio.de
	RewriteRule ^(.*)$ https://rotatio.de/$1 [R=301,L]

	# 302 for all other domains pointing to this server
	RewriteCond %{HTTP_HOST} !=rotatio.de
	# but not on localhost (with optional port)
	# The following conditions could be merged into one unreadable regex.
	RewriteCond %{HTTP_HOST} !^localhost(?::\d+)?$
	# still on localhost, but covering the whole 127.x.x.x range
	RewriteCond %{HTTP_HOST} !^127\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}(?::\d+)?$
	# and not while exposing dev machine to (W)LAN for cross device testing
	# covering 192.168.x.x range
	RewriteCond %{HTTP_HOST} !^192\.168\.[0-9]{1,3}\.[0-9]{1,3}(?::\d+)?$
	RewriteRule ^(.*)$ https://rotatio.de/$1 [R=302,L]
</IfModule>

Now my document roots are clean. All domains point to the html/ directory and are handled with a single .htaccess file.

Nice!

Of course, the whole file is a bit longer. You can inspect the .htaccess source code on Codeberg.

And don’t forget: Never set a 301 redirect before all your tests are finished.

Rotatio (en)

Multiplane – a frontend on top of Cockpit CMS

What I’ve learned

What I’ve done

Components

Cockpit CMS (backend)

Multiplane (frontend)

UniqueSlugs addon

FormValidation addon

Other addons

Base and child theme

Resources

Footnotes

Cockpit – a headless, API-first CMS

My role

Some numbers

How Cockpit works

Why I chose it

Why I left

Addons

Other stuff

Footnotes

How I developed an ADHD friendly fitness routine

Solution

Fun

Short

Daily

How I got there

Side effects

Conclusion

Trivia

Multiple domains, rewrite rules and localhost

Options

My old strategy

The problem with .htaccess

The problem with `.htaccess`