Building LagosLife Buzz: one publication gate for pages, feeds, and search

LagosLife Buzz — Wed, 14 Oct 2026 07:29:17 +0000

AI disclosure: This article was drafted by an AI agent and checked against the project’s implementation and release records. The code excerpt is simplified for explanation.

A static content site can accidentally publish an unfinished article without putting it on the homepage. A feed can expose its summary. A search index can reveal its title. An old HTML file can survive after the record returns to draft.

We maintain LagosLife Buzz, an independent fan publication about the LagosLife game. We are not affiliated with the game’s developer. Our implementation uses Python to generate HTML, a small Node adapter for discovery feeds, and Cloudflare Workers Static Assets for delivery.

The most useful design decision has been giving every output the same definition of “published.” Here is the approach, including the parts a publication flag cannot solve.

1. Separate evidence from publication

Our records have two different jobs: describing what the editor knows and deciding what visitors can see.

Research notes might mean “checked the menu” or “reported by another outlet.” Neither means the article is ready. We therefore use an explicit publication_status with five allowed values:

 draft → review → published
                   ↓
                withdrawn

 private: retained locally, excluded from public article output

That diagram describes an editorial workflow, not a transition system enforced by the code. The validator checks the current state.

This simplified excerpt shows the selection rule; production also validates record types, slugs, duplicate routes, and publication dates:

STATES = {"draft", "review", "published", "private", "withdrawn"}


def select_public(records):
    public = []
    for record in records:
        state = record.get("publication_status")
        if not isinstance(state, str) or state not in STATES:
            raise ValueError("Missing or unknown publication status")
        if state == "published":
            public.append(record)
    return public

An unknown value fails the build. Quietly treating a typo as a draft would hide an editorial mistake until someone noticed a missing page.

2. Reuse the gate across languages

The Python HTML builder imports the publication function. Our Node feed adapter calls that same Python module through a small JSON input/output interface.

That introduces a Python dependency into feed generation, which we accept because Python is already required for the site build. In return, we avoid maintaining two subtly different versions of the rules.

The selected records drive article pages, archives, search, and sitemap entries. The feed adapter additionally checks that each published record has a generated HTML page before emitting its feed item.

One useful test case is a draft that still has historical publication dates. Those dates must never make it public again.

3. Remove stale output deliberately

Filtering input does not remove yesterday’s files.

Before rendering articles, our builder compares existing article routes with the published allowlist. It removes stale index.html files only inside the expected one-level story and guide directories. It validates route shapes and avoids following directory symlinks.

This narrow cleanup preserves archive pages, the FAQ, and unrelated files. It also leaves images in the asset library. Consequently, private is an editorial state, not an access-control mechanism: confidential documents and images must stay outside the deployable asset directory.

Test both halves: the withdrawn article disappears, while neighboring files survive.

4. Keep evidence dates distinct

Publication dates live in a registry; original-source links and source-check notes live with content. Guides can also record the scope and limitations of a firsthand check.

That distinction matters when a game changes quickly. Seeing a registration field supports a statement about the interface. It does not establish how the backend validates every possible submission.

Our templates render source links beside supported paragraphs, a source list, and credited image captions. The source and image directory is another view of those records. None of this automates fact-checking; it gives editors a place to preserve the evidence and readers a route back to it.

5. Treat image derivatives as build artifacts

Original screenshots remain available at full size. A separate Pillow step generates uncropped WebP variants, capped at the original width, and records their dimensions and hashes in a manifest. Selected imagery also has AVIF variants.

The normal build validates the manifest against the originals and derivative files. Replacing a screenshot without regenerating its variants stops the build instead of silently serving outdated images.

Rendered pictures use srcset, layout-specific sizes, and explicit dimensions. Content-hashed filenames let us apply long-lived caching to the derivative namespace without applying that policy indiscriminately to every asset.

6. Verify the release beyond the build

Our checks compare published routes across HTML, sitemap, and feeds; validate canonical URLs and editorial dates; and check for links to non-public records. We also inspect mobile layouts and source-image readability.

Deployment remains a separate step: Wrangler uploads dist/, and we check public routes afterward. A repository push alone does not deploy this setup.

For a small publication, this keeps the architecture manageable. The recurring work is still editorial: checking sources, choosing relevant stories, and recording uncertainty. The build’s job is to make those decisions consistent everywhere the content appears.