Ad placements on this site had started looking wrong — not broken, just not deliberate: spots that clearly weren't ones I remembered choosing. My first assumption was that some old ad unit had been dropped into a template years ago and half-forgotten, so I went looking for it in the theme. There's exactly one ad-related line in the entire theme, and it isn't a placement at all:
Look at the "created" date on a handful of consecutive articles from this site's automated pipeline, and you'd expect them to be scattered across a day — that's the whole point of scheduling posts hours apart instead of dumping them all at once. For three articles published during one run, they weren't.
This site's automated publishing pipeline runs under a scoped account, api_publisher, that has no permission to touch a node's status field. That's deliberate: a hook_node_presave() in this site's custom module forces any new node owned by that role unpublished, no matter what the content type's default says or what the API client asked for:
I had exactly four URLs I wanted redirected. Two articles had accidentally been published twice in July under different titles — a mixup during the early days of the JSON:API publishing pipeline — and once I'd settled on which copy of each to keep, the other needed to 301 somewhere instead of just disappearing. Four source paths, four targets, done.
Composer has a specific way of telling you a package is a bad long-term bet: when a dependency is marked abandoned on Packagist, the lock file itself records "abandoned": true against that package's entry, and every install or update that touches it prints a warning.
There's a specific kind of unhelpful a 403 can be. Try to set a field you don't have permission for through Drupal's JSON:API and you get a real, actionable message back — something like "The current user is not allowed to POST the selected field (status). The 'administer nodes' permission is required." That's a 403 that tells you exactly what to go fix.
Every Drupal config entity has a machine name and a UUID, and it's easy to go a long time treating the machine name as the entity's actual identity, because it's the one you type — id: api_publisher, right there at the top of the YAML file, human-readable and stable. The UUID sits a couple of lines above it, a string nobody reads, that looks like it shouldn't matter.
Drupal has two separate ideas of whether a module exists, and, unless something actively keeps them in sync, they're allowed to disagree with each other. One lives in core.extension config: is the module marked installed, does the database have its schema, does anything still reference its config objects.
Deploying the removal of a Drupal module looks like it has an obvious order: take the module out. In practice it's two separate operations that happen to both look like "removing a module" from the outside, and doing them in the wrong order left production in a broken half-state I had to clean up by hand.
A while back I had a genuinely finished article sitting on disk — the email self-hosting piece, several thousand words, technically accurate, ready to go — and it wouldn't publish. Not because anything was wrong with the writing.