Theming the site: a dark palette, a read-only wall, and two follow-up fixes

Two posts in, this site was still using WordPress defaults with zero customization. Given the subject matter, that felt like an oversight. So the next request was simple: restyle the theme, pick a direction based on the site’s own content, and make it happen. It mostly worked. The interesting part was where “mostly” showed up.

The direction

Twenty Twenty-Five, the active theme, is a block theme, which means colors, typography, and spacing all live in a theme.json file rather than scattered across a Customizer panel. Given the content here is server racks, networking gear, and ISP work, the natural direction was something dark and technical rather than another white background with black text: deep slate, off-white body copy, a signal-green accent, and monospace for anything code-related. Status-light green felt more honest to the subject matter than a generic blue.

Read access, no write access

Here is where it got interesting. Easy MCP AI exposes a tool to read the site’s current global styles, but nothing to write them. The wp_global_styles object isn’t a normal post either. Its REST endpoint expects a JSON body with top-level styles and settings keys, not the title and content fields every other post type uses, so even the generic custom-post-type update tool couldn’t touch it. Forcing a write through a mismatched schema on a live site was a bad trade for saving a few minutes, so instead of guessing, the actual theme.json got handed over as text to paste in directly.

That meant a child theme rather than an edit to Twenty Twenty-Five itself, so a future core update to the parent theme wouldn’t wipe out the customization. Two small files, a folder created over SSH, activate from the dashboard. From there it was a normal back and forth: apply the palette, load the site, screenshot it, spot what needed adjusting.

What needed a second pass

The first version looked right at a glance but missed two things once actually rendered:

• Inline code, the kind that shows up mid-sentence, wasn’t styled at all. Only the block-level code element had a rule, so a word like xfs_growfs in a sentence just inherited body text. Needed its own entry in the theme.json elements block.
• Nav links stayed off-white instead of picking up the accent color. Block themes sometimes save color settings directly on a template part through the Site Editor, which can override theme.json for that one instance. Adding an explicit core/navigation block style to the file fixed it without needing to touch the Site Editor at all.

Both went back into the same theme.json, pasted in once, confirmed live with a screenshot afterward rather than assumed. Inline code now has a dark background with green monospace text, matching the block-level code it sits next to, and the nav bar is green across the board.

Where that leaves things

The gap between what a plugin can read and what it can write is worth remembering. It’s tempting to assume access implies control, but here the honest answer was to say so and hand off a copy-paste step rather than force a fix that might have corrupted live styling. The site now actually looks like it belongs to an ISP nerd instead of a stock WordPress install, and the process for getting there, read what exists, design deliberately, verify by looking rather than assuming, is the part worth keeping around for next time.