18 · Separating the engine

Separating the engine from the content was the hardest operation in the project's history, because it was performed on a site that was running and had readers. The method: one question at every file — does this code know the name of the site it was written for.

A surprising number of files knew. The site name in the page description, in the RSS feed, in the app manifest. Series names in comparisons deciding how things look. Author pen names in signature rules. Old addresses in redirects. Colours in static files that cannot read configuration.

It went in four stages, each with a green build at the end. First: one instance configuration file as the single source of brand and keys. Second: author signature rules and address history moved into data. Third: eight static pages moved into content, with the routes reduced to thin adapters. Fourth, and most important: inverting the dependency so that the engine stopped reaching for content and started being handed it.

Up to the fourth stage you could say the engine was separated, and it would have been true about the directory structure rather than about the dependencies. As long as the engine imports content by path, a second instance is not a matter of configuration but a matter of branching the code — and a branch starts drifting from the original on day one.

The test of that separation was brutally simple: stand up a second instance, of an entirely different character, and check whether the old brand surfaces anywhere. The page you are reading is that test.