The Collections page promises that deleting a Collection requires typing the Collection's name to confirm. No such control exists in Linkwarden v2.16.1 — the prose and the screenshot that illustrates it are both describing a version of the modal that is gone.
The documented promise
docs/usage/collections.md:69:
To delete a Collection, click the "Delete Collection" button in the menu for each Collection. Since this may be triggered accidentally and there's no going back, you are required to enter the Collection's name to confirm your request.
What the app does
Checked against linkwarden/linkwarden v2.16.1 (7550ebb8907e0cd22e8b3e0785bf3da03ab96e3a).
apps/web/components/ModalContent/DeleteCollectionModal.tsx:33-40 deletes on the button press. There is no text state, no comparison, and no input:
const submit = async () => {
if (!collection) return null;
deleteCollection.mutateAsync(collection.id as number);
onClose();
router.push("/collections");
};
The modal body (:42-72) renders a prompt, a warning box and one destructive button, nothing else. The server side checks ownership only (deleteCollectionById.ts:50-52); no confirmation string ever reaches it.
Driving it through the UI — collection menu → "Delete Collection", then looking for the confirmation field:
- expected: a field placeholdered
Type "tcref-confirm-by-name" Here. (the collection under test was named tcref-confirm-by-name)
- actual: nothing on the page matches that placeholder. Counting inputs directly: zero text inputs on the entire page while the modal is open.
Control. The same DOM query, run against the sharing modal, does find inputs — the "Add members by email or username" field and two checkboxes — so the query works and the delete modal's emptiness is real rather than a selector failure.

The screenshot on this page is stale too
static/img/delete_collection.png, still referenced at docs/usage/collections.md:71, shows the older modal: a "Warning!" heading, a bulleted list of what will be removed, the line To confirm, type "Health and Wellness" in the box below:, an input placeholdered Type "Health and Wellness" Here., and a "Delete Collection" button. None of that is in the current modal, so replacing the image is part of the fix.
Why this reads as a removed feature rather than a doc that was always wrong
linkwarden/linkwarden#823 — "Dont require typing collection name when deleting collections" (open, 2024-11-09) — asks for the requirement to be dropped, which shows the input existed at some point and was contested. So the safeguard was taken out and this page did not follow. #823 is a request to change the behaviour, not a report of the drift, so as far as I can tell the drift itself has not been reported.
This one seems worth more than a wording fix, because the sentence's subject is a guard against irreversible data loss. A reader who trusts it expects an accidental click to be caught, and today it is not — one click on Delete removes the collection and everything in it.
The Collections page promises that deleting a Collection requires typing the Collection's name to confirm. No such control exists in Linkwarden v2.16.1 — the prose and the screenshot that illustrates it are both describing a version of the modal that is gone.
The documented promise
docs/usage/collections.md:69:What the app does
Checked against
linkwarden/linkwardenv2.16.1 (7550ebb8907e0cd22e8b3e0785bf3da03ab96e3a).apps/web/components/ModalContent/DeleteCollectionModal.tsx:33-40deletes on the button press. There is no text state, no comparison, and no input:The modal body (
:42-72) renders a prompt, a warning box and one destructive button, nothing else. The server side checks ownership only (deleteCollectionById.ts:50-52); no confirmation string ever reaches it.Driving it through the UI — collection menu → "Delete Collection", then looking for the confirmation field:
Type "tcref-confirm-by-name" Here.(the collection under test was namedtcref-confirm-by-name)Control. The same DOM query, run against the sharing modal, does find inputs — the "Add members by email or username" field and two checkboxes — so the query works and the delete modal's emptiness is real rather than a selector failure.
The screenshot on this page is stale too
static/img/delete_collection.png, still referenced atdocs/usage/collections.md:71, shows the older modal: a "Warning!" heading, a bulleted list of what will be removed, the line To confirm, type "Health and Wellness" in the box below:, an input placeholderedType "Health and Wellness" Here., and a "Delete Collection" button. None of that is in the current modal, so replacing the image is part of the fix.Why this reads as a removed feature rather than a doc that was always wrong
linkwarden/linkwarden#823— "Dont require typing collection name when deleting collections" (open, 2024-11-09) — asks for the requirement to be dropped, which shows the input existed at some point and was contested. So the safeguard was taken out and this page did not follow. #823 is a request to change the behaviour, not a report of the drift, so as far as I can tell the drift itself has not been reported.This one seems worth more than a wording fix, because the sentence's subject is a guard against irreversible data loss. A reader who trusts it expects an accidental click to be caught, and today it is not — one click on Delete removes the collection and everything in it.