import { Section, Heading } from '@atlas/blocks';
export default Hero = () => (
<Section tone="clay">
<Heading level={1}>
Page builders hold you back.
</Heading>
</Section>
); VOL. I / A WORDPRESS PLUGIN
§ / 2026
Atlas
WordPress, rendered.
One Gutenberg block. Deterministic manifests, version-controlled in git. Zero hydration cost for static chrome.
§ 02 / The proof
Three artifacts. One source of truth.
You write the component. Atlas compiles it to a deterministic manifest in git. WordPress renders it server-side. No databases, no editor lock-in, no surprises.
{
"version": 1,
"sections": [
{
"type": "Section",
"tone": "clay",
"children": [
{ "type": "Heading",
"level": 1,
"text": "…" }
]
}
]
}<section class="atlas-section atlas-tone-clay">
<h1 class="atlas-heading">
Page builders hold you back.
</h1>
</section>
<!-- 0 hydration. 0 inline scripts.
Plain HTML in WordPress. -->§ Same JSON in — same HTML out, every time. Determinism is the feature.
§ 03 / The kill list
Five things Atlas refuses to do.
Every WordPress builder treats these as core features. Atlas treats them as bugs to design around. The constraints are the product.
- 01 Page builders hold you back.§ No drag-and-drop tax.
- 02 Shortcodes are a mistake.§ Components, not strings.
- 03 Database HTML is a liability.§ Manifests live in git.
- 04 Theme rewrites are not a feature.§ Your theme keeps working.
- 05 Hydration is a tax, not a default.§ Server-rendered, by default.
§ 04 / It just works
Atlas renders pages. It doesn't replace your stack.
Forms still submit. Hooks still fire. WooCommerce keeps working. Atlas owns the rendering of one block — the rest of WordPress is unchanged.
<Form action="/wp-admin/admin-post.php">
<Field name="email" />
<Field name="message" />
<Submit>Send</Submit>
</Form>// admin-post.php fires
// nonce verified, message sent
<div class="thank-you">
Got it. We’ll respond within a day.
</div>- § FORMS
Contact 7 still submits.
Atlas renders the chrome. Your form plugin handles submission. Same hooks, same nonce, same confirmation page.
- § COMMERCE
WooCommerce keeps working.
Cart, checkout, subscriptions — untouched. Atlas only renders the editorial pages around them.
- § HOOKS
Every action fires.
wp_mail, transition_post_status, woocommerce_thankyou — your existing automation is unaware Atlas exists.
§ 05 / Your site stays yours
Atlas installs as a plugin. It does not stage a takeover.
Your theme keeps rendering. Your plugins keep firing. Your host doesn't change. And if you uninstall Atlas, the pages stay put as plain HTML.
- § YOUR THEME
Stays active.
Atlas is a plugin, not a theme. Whatever theme is currently rendering your archive pages keeps rendering them.
/wp-content/themes/... - § YOUR PLUGINS
Keep loading.
WooCommerce, Yoast, Gravity Forms, Polylang — Atlas neither replaces nor wraps them. They run unchanged.
/wp-content/plugins/... - § YOUR HOST
Doesn't change.
Shared, VPS, Pressable, Kinsta — wherever you host, that's where Atlas runs. No edge worker, no separate runtime.
PHP 8.1+ / WP 6.4+ - § WHEN YOU UNINSTALL
Pages remain.
The last server-rendered output stays in the post body as plain HTML. No white screens, no broken shortcodes.
graceful degradation
§
The only thing Atlas adds to wp-content/plugins/ is itself. The only thing it adds
to your DOM is one Gutenberg block. Everything else is yours.
§ 06 / Same manifest, two surfaces
Developers ship the schema. Marketers edit the page.
One manifest, read by two people. The developer commits the component shape. The marketer edits content in Gutenberg. Neither blocks the other.
Author the component shape.
- → Define props in TypeScript
- → Commit the manifest to git
- → Open a PR if the schema changes
- → Marketers cannot break the build
Edit content in Gutenberg.
- → Inline-edit text in the block editor
- → Swap images from the Media Library
- → Reorder sections with drag handles
- → Cannot rewrite the schema by accident
SHARED SOURCE OF TRUTH manifests/homepage.atlas.json
Both surfaces read and write the same JSON. The schema is the contract; everything inside it is editable.
§ 07 / Two reads
Pick the door. Read in.
Two ways into Atlas, depending on whose hands the page lives in. Both lead to the same architecture — the entry point is the only thing that changes.
§ FOR DEVELOPERS
Components, manifests, git.
You write TypeScript. Atlas compiles to deterministic JSON. WordPress renders it server-side. Type-safe authoring, zero hydration cost for static chrome, every page diff-able in a pull request.
§ FOR AGENCIESRepeatable layouts, faster builds.
Build a manifest once, reuse it across client sites. Edits land as PRs, not as overrides smeared across post meta. Hand a site to the next agency without packing a runtime in the suitcase.
§ 08 / Get the plugin
One block. One plugin. Endless possibilities.
Composer, wp-cli, or the WordPress admin search. Pick the path you already know. Atlas activates as a plugin and adds one block to the editor.
$ composer require veroscale/atlas
§ VIA WP-CLI
wp plugin install atlas --activate § VIA ADMIN
Plugins › Add New › "atlas" One block. One plugin. Endless possibilities.