Third attempt at this one, and this time it holds. @NotRetarded pointed out in #2 that the cards at the bottom of the settings page show up on every tab — Backup, Info, the update window, both maintenance cards. They sat outside all five panes, so switching tabs simply left them there.
They are in the right tab now: Backup and Info under General, the update window under Updates, maintenance mode next to the cleanup it pauses. The Groups card is gone entirely — it was a signpost left behind in v1.21.1 when groups moved onto their own page, and "Gruppen" has been in the navigation on every page for the 52 versions since.
Why it took three tries, and the one that nearly shipped
The first two attempts broke the page outright and were backed out. The third looked perfect and was the dangerous one.
Those cards carry their own little POST forms — the maintenance buttons, the cleanup button, the window editor. Putting a card inside a tab pane put its form inside the big settings form, and nested forms are invalid HTML. The parser does not merely tolerate that: it drops the inner start tag and lets the inner </form> close the outer one.
Measured on the running instance:
settings form ends after the Updates tab
23 fields from Cleanup / Notifications / Channels fall outside it
Those fields would not have been submitted. And a checkbox that is not submitted reads as "off" — so a single press of Save would have turned off auto-cleanup, monitoring and the weekly report, and blanked both webhook URLs.
None of that was visible. ast.parse passed. The HTML structure check passed. Screenshots of all five tabs showed every card exactly where I wanted it. It only turned up when I read form.elements out of a real browser and counted what was actually attached.
So the settings form is empty now and its 26 fields hang off it by id (form="settings-form"), which is plain HTML5 and means no card can nest a form no matter where it is moved to. Verified by saving the page for real and diffing the stored config afterwards: not one value changed.
There is a test for it now — no <form> may open inside another anywhere in the UI, every settings field must reach the form, and the fields the page sends must be exactly the ones the handler reads. I checked it against three broken variants to make sure it actually fails when it should.
Still open
Per-container memory and CPU on the status page. Doing it properly means loading it after the page renders instead of making every page load wait two seconds on docker stats.
Upgrading is the usual docker pull ghcr.io/amayer1983/docksentry:latest, or nothing at all with auto-selfupdate on.