Withdrawing an entry is incomplete if related links or an old address still serve its body. I review listings, related connections, direct reading and generated artifacts against the same publication criterion, alongside exclusion of private evidence.
I read the current public-list handling and this website’s server checks, then distilled a reusable module. Its synthetic checks remain distinct from actual HTTP draft denial. The article helps readers apply the difference between a hidden card and a protected manuscript.
An absent list item does not establish manuscript protection
Filtering a draft from a list does not protect its body when that body is included in a public file. CSS concealment differs from server non-delivery. I inspect visible navigation conditions separately from actual body delivery and keep private material out of public JavaScript bundles.
The inspected tool source builds listings and related entries from published metadata and validates publication during generation. That aligns public connections. A server protecting sensitive drafts must also check the body request against stored state.
Resolve related entries against the current public set
An existing related identifier can still refer to a draft, withdrawn entry or missing destination. The current detail component resolves identifiers against the public article set and keeps found entries. The generator also validates related identifiers as published.
The new module excludes self, duplicates, unknown identifiers and non-public states. Display titles and summaries come from its explicit public projection. It does not reveal a draft title merely without a link. Publication state and permitted fields are considered together.
Apply the state check to direct body requests
Someone can request a known address without entering through a list. This website’s server checks state and type at direct detail routes and returns 404 for a non-public entry. Management preview uses a separate authenticated flow. The boundary needs to hold without list navigation.
The new direct-loader example returns a body only after checking publication in a server store. Running it with a simulated browser store below explains the condition. A client function alone does not establish authentication or protect a manuscript’s confidentiality.
Create a new public object from required fields
Sending an entire store object and displaying only some of it can still deliver internal evidence and settings. This CMS separates public manuscripts from private evidence and excludes evidence from public delivery. Absence from the response matters beyond absence from the visible screen.
The example creates list objects from identifier, title and summary, and copies only validated body strings for direct reading. Extra private fields do not follow. An editor with blocks and media needs its broader public schema reviewed; this small example does not replace every block validator.
Implementation using the current publication state
The functions separate a public catalog, related entries and direct body lookup in a server store. They require explicit state and reject duplicate identifiers. A copied body array prevents editing a returned object from changing the stored source array.
Nine synthetic-store checks covered public projection, related exclusions, direct draft and withdrawal denial, unknown addresses, private-field exclusion, invalid state, duplicates, body copying and a changed state on a fresh lookup. Deployed server behavior was checked separately over HTTP.
Explore the implementation
JavaScript · Public list, related and body boundary
function validEntry(row){
if(!row||!/^[a-z0-9]+(?:-[a-z0-9]+)*$/.test(row.slug||'')||!['published','draft','withdrawn'].includes(row.status)||typeof row.title!=='string'||typeof row.summary!=='string')throw new TypeError('Explicit entry identity and publication state required');
}
function publicSummary(row){return {slug:row.slug,title:row.title,summary:row.summary};}
export function publicCatalog(rows){
if(!Array.isArray(rows))throw new TypeError('Entry array required');const seen=new Set();
for(const row of rows){validEntry(row);if(seen.has(row.slug))throw new TypeError('Duplicate entry');seen.add(row.slug);}
return rows.filter(row=>row.status==='published').map(publicSummary);
}
export function publicRelated(rows,currentSlug,requested){
if(!Array.isArray(requested))throw new TypeError('Related identifiers required');
const bySlug=new Map(publicCatalog(rows).map(row=>[row.slug,row])),seen=new Set(),result=[];
for(const slug of requested){if(slug===currentSlug||seen.has(slug)||!bySlug.has(slug))continue;seen.add(slug);result.push({...bySlug.get(slug)});}
return result;
}
export async function loadPublishedEntry(slug,store){
if(typeof slug!=='string'||!/^[a-z0-9]+(?:-[a-z0-9]+)*$/.test(slug))return null;
const row=await store.find(slug);if(!row)return null;validEntry(row);
if(row.status!=='published')return null;
if(row.slug!==slug||!Array.isArray(row.body)||row.body.some(x=>typeof x!=='string'))throw new TypeError('Validated published body required');
return {...publicSummary(row),body:[...row.body]};
}
Separate actual draft denial from the synthetic example
I read the existing private QA entry through the authenticated API to establish its draft state, then verified 404 at both language addresses. Seven checks passed for direct denial and exclusion from listings, RSS and sitemap. This was read-only review without changing or publishing the fixture.
The example below changes states using wholly synthetic data and contains no actual private material. Its display result is distinct from deployed server denial. The public frame response is checked, while new rendered or clicking review was not performed with Studio Chrome preserved.