My search engine parsed every crawled page with PHP 8.4's new HTML5 parser, Dom\HTMLDocument::createFromString(). In July, someone pointed out that a Danish result showed its title as "Bes�g i hansestaden L�beck" instead of "Besøg i hansestaden Lübeck".
The script that publishes articles on this site tests every article on a local copy of the site first, at https://linkhub.ddev.site. That local site runs in DDEV, and its HTTPS certificate is signed by a local certificate authority that mkcert created. On the Ubuntu install where the pipeline started, that just worked.
CaRMen's deploys start in GitHub Actions and end on a server, and something has to cross that gap. Here it's an SSH key, stored as a secret in the repository, that the deploy job uses to connect to the server and run the deploy. A key like that is exactly the kind of secret that leaks: it sits in a CI system, it's used automatically, and nobody watches each use. So the key can't open a shell.
CaRMen's public demo lives at /demo/ on the project's landing site. The landing site is its own nginx server block on the host; the demo is a separate application in Docker, listening on a local port.
My search engine's crawler backed off from hosts that kept failing: each consecutive failure doubled the wait before the next attempt, up to a cap of one day. During one long working session in July, one test of that logic failed in every run, and it kept being written off as a "pre-existing, unrelated" failure.
CaRMen's deploys run from GitHub Actions: once the tests pass on the main branch, a job builds and publishes the Docker images, and a deploy job connects to the server over SSH and tells it to switch to the new version. Within a day of setting that up, the deploy job started failing some of the time with SSH errors, while the images it was meant to deploy had been published just fine.
In early July the admin statistics page of my search engine started reporting zero: zero pages crawled in the last hour, zero in the last 24 hours, on a pipeline that was visibly busy. At the same time, re-crawls were being scheduled two hours early. Both had the same cause, and none of the data was wrong. The database and the application disagreed about what time it was.
The PHP language server setup in my Emacs used to be a single setting that offered Eglot a list of servers, phpactor and Intelephense, to choose from. In October, I replaced it with a small function and a settings function.
Tightening a file's permissions is supposed to be the safe direction. In July, on my search engine's frontend server, setting the application's .env file to mode 0600 instead did two things at once: it broke every newly started PHP process, and it left the admin area answering without a password for a few minutes. A smoke test after the deploy caught it.
In October, CaRMen, my CRM, got an endpoint for something other than a logged-in person: a website contact form that should be able to create a lead without anyone logging in. That needs an API key, and an API key is a password that's meant to be pasted into other systems.