eiriksm.dev: Social historical code archeology: cronner.module
Violinist.io is well into its seventh year. It has survived a couple of Drupal core major upgrades and remains a profitable SaaS based on Drupal and a vital tool for agencies and organizations. I’m not sure if there is such a thing as social historical code archeology, but if there was, then this blog post might be it. I have long wanted to write some blog posts about the development of violinist.io that not only focused on exciting or interesting technical aspects. Instead I think this will highlight when things do not go as planned, why that was, and maybe something around what it meant at the time comparing to present day?
The project started as a PHP file and proof of concept in Drupal Developer Days Seville 2017. Literally. It was one PHP script placed inside one file. After I got that working I figured I would make it a composer package and run it with Drupal cron. This was the first version of violinist.io. Run the method of a composer package with cron. I made a module to contain this hook_cron implementation. I called it cronner. It was the module to do things on cron so that was the name. The cronner module.
cronner.module was first checked in to git with the revision 55da4a9c:
From 55da4a9c
Date: Thu, 23 Mar 2017 08:38:57 +0100
Subject: [PATCH] This is a site now?
As we may deduce from the commit message, this was a pretty early one in the codebase. More precisely, this was the second commit to the codebase, after some initial scaffolding files. At that point, this was the entire contents of cronner.module:
<?php
/**
* Implements hook_cron().
*/
function cronner_cron() {
$nodes = Drupal::entityTypeManager()
->getStorage('node')
->loadByProperties([
'type' => 'project'
]);
$q = Drupal::queue('cronner_project');
foreach ($nodes as $node) {
$q->createItem($node);
}
}
Basically a cron implementation to queue all projects on the site periodically.
Fast forward to 2023 and some reflections around maintaining a codebase. Cronner. I can honestly say that cronner is among my least proud namings in the codebase. The hook_cron implementation is long gone and replaced with all sorts of fancy cloud computing. The name really is misleading now. It contains no cron implementations like that any more. Instead it contains (among other things):
- Schema for the database table called cronner_log
- Some random theme hooks used here and there
- A hook_node_insert implementation that is still the one responsible for adding new projects to the update queue
I have many times wanted to work on extracting parts of cronner.module into separate modules. But fixing bugs, improving test coverage or implementing new features has always been the priority. At this point, from time to time I open the file cronner.module and shudder. But after that initial feeling of annoyance or shame I instead focus on the image of something like the origin life form. Something like a web of branches and roots coming out of a mother plant. Something almost alien-like. The module that started it all, the breathing and growing mother of the codebase.
Some might call it legacy. I call it cronner, the origin mother of the codebase.