Everything is a page.
Nothing heavy. Nothing hidden.
Pages are folders, content is JSON, and a SQLite index makes it fast at scale. Simple where you look, quick where it counts.
Everything is a page
The admin panel, a blog post, a gallery item, an API-shaped endpoint: in PhlatPage these are the same primitive. There's no separate concept of a route, a content type, or an admin URL bolted on top, just pages nested in a tree, each pointing at a view that defines how it behaves. Learn the one abstraction and you understand the whole system, including how the admin panel itself is built: an addon, mounted as ordinary pages.
The filesystem is the API
Content is JSON, sitting in a folder right next to the page it belongs to. Want to see how a page is structured? cd into it. Want to edit copy? Open data.json in any editor. Want to know what changed last week? git log the folder. There's no export step and no sync job between what's on disk and what's live, the tree you see is the tree that's served.
site/pages/
about/
index.json # uuid, view, metadata
data.json # title, body, whatever fields you add
Views are composable blueprints
A view bundles everything a kind of page needs into one package: its template, its controller, its router, and its field schema. Define "article" once, and every article page gets the same layout, the same request handling, and the same fields to fill in, without wiring each page by hand. An addon can ship a view for free; only a page the site author actually placed in the tree can claim a URL.
Fast lookups, driven by a simple query language
A SQLite index sits alongside the page tree purely as a fast lookup, mapping UUIDs to paths, views, and statuses so a query like this doesn't have to walk the filesystem on every request. Delete registry.db and nothing is lost: rebuild it from the pages on disk with one command, zero migrations, zero drift that can ever become an outage.
$app->find('view=article,sort=-created,limit=4');
The folder structure IS the page tree
A page at /blog/hello-world/ lives at site/pages/blog/hello-world/. There's no routing table to reverse-engineer and no "where does this URL actually render from" detective work, the site's architecture is explorable with ls and cd. Onboarding a new developer means walking a folder, not annotating a routes file.
Hypermedia-driven, not API-driven
Every route returns HTML. HTMX drives every interaction, clicking, submitting, swapping page fragments, over that same HTML. There's no JSON layer shadowing the real UI, no client-side router keeping its own copy of state, nothing to keep in sync with the server by hand. The URL is the API, and it's a URL you can also just visit.