Guide

The Quiet Website: Building a dark-first editorial theme in WordPress without a page builder

What I learned building Luminaris as a custom block theme without giving layout control away.

12 min readIntermediate17 April 2026

I wanted the Luminaris site to read like a small publication with a memory, not like a landing page that happened to inherit a blog. The more I sketched it, the clearer the split became: WordPress should handle content, routing, and editorial upkeep; code should handle pace, proportion, and the parts that need to move by a few pixels instead of a few dropdown settings.

That decision sounds more dramatic than it is. I am not at war with WordPress. I just do not want the layout to be negotiated by a stack of defaults I did not choose. If a headline needs to sit tighter, or a link needs to feel quieter, I want that decision in code, where it belongs.

Why editorial

Most personal sites pretend to be product pages. They open with a claim, sprinkle icons underneath, and hope the reader mistakes structure for personality. That format works when the only job is conversion. It fails when the site is supposed to hold projects, essays, tools, and unfinished ideas without flattening them into the same sentence.

Editorial design gives me a better operating model. It lets different kinds of work keep their own rhythm. A project can feel more decisive. A guide can breathe. A short post can stay small on purpose. The homepage becomes less of a brochure and more of a front desk for a body of work.

Color and type are operating decisions

Dark-first was not a style flex. It was a reading decision. On this site the dark background is not meant to feel neon or theatrical. It is supposed to act like a quiet room: lower the noise, make the bright elements earn their place, and give the text a stable surface to sit on.

The typography follows the same logic. I wanted a display face with some temperature and a body face that disappears at the right moment. Fraunces gives the headings a little gravity without turning them ornate. Inter keeps the rest of the interface clean. The pairing is not novel. It is just disciplined enough to let hierarchy do the work.

Why no page builder

I hear the obvious question every time I say this: why use WordPress at all if I do not want a builder deciding the page? Because WordPress is still very good at being a container. It handles publishing, revisions, routing, media, plugins, forms, and the boring infrastructure that should not require a ceremony every time I need one new guide or one new product.

What I do not want is the last mile of design being mediated by controls that turn taste into increments. Moving a heading three pixels is not the point. The point is that the site should not resist precise decisions. Builders are optimized for coverage. I care more about coherence.

How WordPress and custom code split the work

The block theme setup ended up feeling like the right compromise. Content types live in WordPress. ACF carries the structured fields. Helpers render the cards and the single views. The front page still uses blocks, but only as a thin template language around controlled pieces. That keeps the admin usable without giving the whole site over to drag-and-drop habits.

I like that split because it acknowledges two truths at once. The site needs a content engine. It also needs authored layout. A project card should know how to pull its own metadata. A guide should know how to build a table of contents. But the page should still feel like someone arranged it deliberately, not like a generic loop happened to populate.

What I would change next

The next round is less about style and more about connection. I want the relationships between projects, products, guides, and topics to become more legible. The home page should feel less like separate shelves and more like a system with gravity. That means better featured logic, stronger cross-links, and content rich enough that the structure actually has something to carry.

I would also keep reducing noise. The temptation with a site like this is to over-explain the philosophy until the philosophy becomes the product. I would rather let the tone show through the smaller decisions: spacing, copy, headings, what gets omitted, what is allowed to stay unfinished in public.

The quiet website is not an aesthetic rule so much as a working stance. Make the interface calm. Make the structure honest. Let the content speak in full sentences. Then keep the system flexible enough that new work can arrive without breaking the tone.

Topics covered

  • Choosing a dark-first palette without turning the whole interface into chrome.
  • Using display and body type with enough contrast in personality and almost none in friction.
  • Letting WordPress handle content while code holds the layout decisions that actually matter.
  • Structuring projects, products, and guides with ACF so the templates stay honest.
  • Why page builders solve speed problems while often creating coherence problems.
  • What still needs refinement after launch.

Code