The Restricted HTML Format That Forced Me to Write Better Code Examples
This site's articles get published through a Drupal role with exactly one text format available to it: restricted_html.
This site's articles get published through a Drupal role with exactly one text format available to it: restricted_html.
I keep a different password for the same service account on every environment it exists in, even on a project where I'm the only person who'll ever type any of them in. That habit paid for itself directly tonight, in a way that would have been a lot more confusing to untangle if I'd taken the obvious shortcut instead.
Upgrading this site to Drupal 11, the very first command I ran should have been the anticlimactic one: composer require drupal/core-recommended:^11. Instead it failed immediately, and the reason it gave was, technically, true and completely useless at the same time.
Nothing about this site is optimized for reach. No algorithm decides who sees a post here, there's no engagement loop pulling anyone back tomorrow, and there's no metric anywhere in the stack that rewards me for writing something that performs well versus something that's actually true to what I was thinking. That's not an oversight. It's the entire reason the site exists in this shape.
init.el on this machine is fifty-four lines long. That number hasn't grown much in a long time, and I used to think that meant my Emacs configuration was small. It isn't, really — it's just not in that file.
I'd deliberately deleted three unused modules from this site's codebase — old, disabled, doing nothing. A few minutes later, mid-conversation with the agent I was working with on an unrelated task, one of them reappeared on disk. Not because I'd changed my mind.
Every article on this site was, for a little while, quietly saying "Submitted by Lars Nielsen" twice. Not in two different places on the page where you might excuse it as intentional — stacked directly on top of itself, in the same footer, half a second apart in the markup.
A cryptominer showed up on production twice in one morning. The interesting part wasn't the malware — it was how ordinary the way in turned out to be, and how many wrong turns it took to find it.
I upgraded this site from Drupal 10 to Drupal 11. The Drupal part went fine, eventually. What actually took the site down for four minutes had nothing to do with Drupal at all — it was a missing setgid bit, and I only found it because I've learned not to trust a Drupal error log to tell me the whole story.
Most guides to enabling REST or JSON:API in Drupal tell you to go to /admin/config/services, tick some checkboxes, and save. That's fine advice for a one-off experiment, and terrible advice for anything you intend to depend on.