The CMS Block

The problem

Three clients wanted a blog. Copying the working one into the next site takes an afternoon and costs a year, because every fix after that has to be made three times, and the third copy is always the one nobody remembers.

What got built

A Payload package vendored into each site rather than published to a registry, because these are separate deployments and a client's back office does not belong on npm. A push writes the source into the site, which imports it through a tsconfig path: no build step, one copy of React, and server component boundaries that behave exactly as if the files were local. The line it draws is that behaviour ships and layout does not. What a comment thread does is the same everywhere. What a story looks like is the site.

Details worth naming

• One migration lineage shared by every site. A site that turns comments off gets the same tables and never shows them, so switching the feature on later is a config change instead of a migration.
• Nothing site-specific may go in a migration. A default written into one is the same string on every database it runs against, which is exactly how the second site would have inherited the first site's name.
• Two guards against editing the vendored copy: the push refuses to overwrite a file the site changed and says which, and the site's own check fails when anything has drifted from the manifest.
• Reader-facing components are styled entirely through CSS variables the site defines, so restyling is a token change rather than a fork.
• Comment threading and moderation, a search index with its own ranking, readership figures from a first-party beacon, and a WordPress import path.