Published en private content refactoren

Toen de repositorystructuur duidelijker werd, heb ik opgeschoond hoe posts en projects getoond of verborgen worden. Ik wilde niet dat elke contentfile behandeld werd als volledig publiek of volledig afwezig.

De workflow moest twee aparte vragen beantwoorden:

• is deze entry klaar om mee te doen op de site?
• als ze meedoet, mag productie ze tonen?

Die beslissingen hangen samen, maar ze zijn niet hetzelfde.

De frontmattervorm

Posts en projects gebruiken nu twee expliciete velden:

published: true
private: false

published bepaalt of de entry deel uitmaakt van de site. private bepaalt of ze buiten productie moet blijven.

Dat onderscheid geeft mij een nuttige reviewstatus. Ik kan een draft lokaal renderen, de layout en metadata controleren, en hem toch van de publieke site weghouden tot hij klaar is.

De filterregel

De implementatie blijft bewust klein: unpublished entries zijn verborgen, publieke entries zijn zichtbaar, en private entries zijn alleen beschikbaar buiten productie.

Omdat die logica in de gedeelde content helper zit, moeten routepagina’s dezelfde checks niet herhalen. Posts en projects kunnen dezelfde regel gebruiken voordat ze gesorteerd of op locale gefilterd worden.

Waarom dit helpt

Dit veranderde hoe veilig contentwerk aanvoelt. Ik kan een post maken of aanpassen zonder meteen te beslissen dat hij live hoort te staan.

Het helpt ook voor projectpagina’s. Sommige portfolio entries vragen meer review omdat ze ouder werk, externe links, afbeeldingen of technische claims bevatten. Door ze lokaal zichtbaar te houden, kan ik ze verfijnen zonder drafts te verwijderen of de publishing workflow zwakker te maken.

Tradeoffs

De tradeoff is een extra frontmatterveld om te onderhouden. Dat is aanvaardbaar omdat het gedrag expliciet is en in elk bestand makkelijk te controleren blijft.

Belangrijk is dat templates en prompts dezelfde default respecteren. Nieuwe content kan private starten en pas publiek worden wanneer de pagina bewust klaar is.

Resultaat

Deze refactor maakte de contentworkflow minder breekbaar. Hij gaf mij een duidelijk pad om aan drafts te werken, ze lokaal te reviewen en ze pas te publiceren wanneer ze publiek bedoeld zijn.