A domain that serves something other than a wiki site cannot be recorded as served #87

New Issue

2026-09-21T07:18:26Z

cgalo5758 commented

2026-09-21 07:18:26 +00:00

What a person cannot do today

Record on the Domains page that a domain is served by something other than a wiki site. Every placement (the row that wires a domain to the thing serving it) is written by the wiki sync and points at a wiki site. A deployment's own hostnames, for the console itself and for whatever else it runs beside it, are served by other applications, and the only way to give one of them a placement today is to create a wiki site of that name under the system tenant, which records a service hostname as a wiki.

What they should be able to do

Author a placement for a domain with no site behind it, so the registry can answer yes when the TLS proxy asks whether that domain may get a certificate, and so the Domains page lists every domain the deployment serves and says what serves each one.

Why it matters

Until the registry holds these names, a second answerer has to stay in front of the console for them: a directory on the wiki farm, consulted whenever the registry says no. That fallback is then load-bearing for names that have nothing to do with the wiki, and no operator can tell from the Domains page which names the deployment actually serves.

Where

internal/domains, the placement writer and the ask; the operator Domains page.

Done when

An operator can create and remove a placement whose provider is not the wiki integration, the ask answers yes for it, the sync leaves it alone rather than treating it as an orphan, and the placements table says what serves each domain.

Migrated from status/issues.md at b7a0e15

## What a person cannot do today Record on the Domains page that a domain is served by something other than a wiki site. Every placement (the row that wires a domain to the thing serving it) is written by the wiki sync and points at a wiki site. A deployment's own hostnames, for the console itself and for whatever else it runs beside it, are served by other applications, and the only way to give one of them a placement today is to create a wiki site of that name under the system tenant, which records a service hostname as a wiki. ## What they should be able to do Author a placement for a domain with no site behind it, so the registry can answer yes when the TLS proxy asks whether that domain may get a certificate, and so the Domains page lists every domain the deployment serves and says what serves each one. ## Why it matters Until the registry holds these names, a second answerer has to stay in front of the console for them: a directory on the wiki farm, consulted whenever the registry says no. That fallback is then load-bearing for names that have nothing to do with the wiki, and no operator can tell from the Domains page which names the deployment actually serves. ## Where [`internal/domains`](https://git.coopcloud.tech/wiki-cafe/member-console/src/commit/b7a0e15/internal/domains), the placement writer and the ask; the operator Domains page. ## Done when An operator can create and remove a placement whose provider is not the wiki integration, the ask answers yes for it, the sync leaves it alone rather than treating it as an orphan, and the placements table says what serves each domain. Migrated from status/issues.md at b7a0e15

cgalo5758 added the

kind

enhancement

area/domains area/fedwiki area/operator-ui labels 2026-09-21 07:18:26 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wiki-cafe/member-console#87