Gazette Builder

Feature: Publication & Release Controls

Worldbuilding content is not always ready for readers the moment it is created.

Some Entries may still be under development. Others may be complete but intended to appear later as part of a scheduled release, an unfolding campaign, or a serialized Story.

GazetteBuilder keeps those concerns separate.

An Entry can exist fully inside WordPress—with its content, metadata, semantic references, relationships, images, timeline information, and Story data already in place—while its publication and release settings determine whether readers can see it yet.

Drafts, Published Entries, and Release Dates

GazetteBuilder works with the normal WordPress publication state while adding a separate Release Date for reader-facing availability.

That creates three useful cases.

Draft

A draft Entry exists in the GazetteBuilder admin area but is not available to readers.

Draft status takes priority over release timing. A draft remains unavailable even if it has no Release Date or its Release Date has already passed.

Drafts are useful for material that is still being written, reviewed, or prepared.

Published and Available Now

A published Entry with no future Release Date is available immediately.

It can appear wherever its other settings allow, including:

  • its normal Entry page;
  • Entry Type indexes;
  • semantic links;
  • inverse relationship sections;
  • timelines;
  • Story sequences.

Published but Not Yet Released

A published Entry can also have a future Release Date.

The Entry is complete and published inside WordPress, but GazetteBuilder withholds it from readers until that date arrives.

This is useful when you want to prepare material in advance without making it visible early.

For example:

Status: PublishedRelease Date: 18 February 1889

Before 18 February, the Entry exists but is not reader-accessible through GazetteBuilder.

Once the Release Date is reached, it becomes eligible automatically.

Publication and Release Are Different Things

The distinction is intentional.

Publication status answers:

Is this Entry approved for public use?

Release Date answers:

When should readers be allowed to encounter it?

Keeping those separate means you can finish and publish an Entry administratively without having to expose it immediately.

There is no need to change the Entry’s content or restructure the Gazette when release day arrives.

Release-Aware Gazette Features

GazetteBuilder’s generated views respect Entry availability.

A future Entry should not appear early simply because another feature knows it exists.

Release eligibility can therefore affect:

  • Entry Type indexes;
  • semantic reference resolution;
  • inverse relationship listings;
  • timelines;
  • Story navigation;
  • other generated GazetteBuilder views.

If an Entry has not yet reached its Release Date, those features treat it as unavailable to readers.

This helps prevent accidental spoilers or premature disclosure through a secondary navigation path.

Semantic References and Future Content

A semantic reference can point toward an Entry that is not yet available.

For example:

[[The Southern Survey]]

GazetteBuilder may know that the target Entry exists, but if that Entry is still a draft or has a future Release Date, the reference should not expose it to the reader as though it were already public.

When the target becomes release-eligible, the same source content can begin resolving normally without requiring the original Entry to be rewritten.

That makes publication controls especially useful in worlds that are revealed gradually.

Release-Aware Relationships

The same principle applies to semantic relationships.

Suppose several Location Entries contain:

Located In: Syrtis Major

If one of those Locations has not yet been released, GazetteBuilder should not include it prematurely in the automatically generated Locations section on the Syrtis Major Entry.

Once it becomes available, it can join that reverse relationship listing automatically.

The structure of the relationship already exists. Only its public presentation changes.

Timelines Without Spoilers

Timeline Entries can also be prepared before readers are meant to see them.

An Entry may already contain its Campaign Date and Timeline Sort value, but a future Release Date prevents it from appearing on public timelines until it becomes eligible.

This is particularly useful when the fictional chronology and the real-world publication schedule are different.

For example:

Campaign Date: 10 January 1889Timeline Sort: 1889-01-10Release Date: 1 September 2026

The event belongs historically on 10 January 1889, but readers do not see it until 1 September 2026.

GazetteBuilder keeps those two timelines separate:

  • Campaign Date / Timeline Sort describe when something happens in the world.
  • Release Date describes when the audience may see it.

Story Releases

Release controls become particularly useful with sequential Stories.

A Story can be prepared well in advance, with later Entries already written and assigned their Story ID and Sequence Position.

Each step can then receive its own Release Date.

A reader might currently have access to:

0 — Story Landing1 — Chapter One2 — Chapter Two3 — Chapter Three

while positions 4 and 5 already exist but have future Release Dates.

GazetteBuilder prevents the reader from advancing into those unavailable steps.

At the current endpoint, a continuing Story can display:

To be continued…

When the next Story Entry reaches its Release Date, progression can continue automatically.

This allows serialized material to be scheduled without rebuilding the Story each time a new installment becomes available.

Keeping Future Material Manageable

Because unreleased Entries already exist in the system, administrators need a way to find them easily.

GazetteBuilder can distinguish between content such as:

  • Draft Entries;
  • published Entries with future Release Dates;
  • Entries already eligible for public display.

That makes it possible to review upcoming material without confusing “not finished” with “finished but intentionally withheld.”

Build Now, Reveal Later

Publication and release controls are designed around a simple idea:

The structure of the world should not have to change just because the audience has not seen all of it yet.

You can create the Entry, connect it to the rest of the Gazette, place it in the chronology, add it to a Story, and prepare its media in advance.

GazetteBuilder then controls when that already-structured material becomes part of the reader’s visible world.