Hi Theme.co team,
We are building on Pro Theme (with Cornerstone) for a client project, and we’re currently moving that site into a containerized, Git-based deployment pipeline — immutable Docker images built from a versioned repo, with the database and uploads treated as the only persistent, non-versioned state. Pro’s flexibility made it an easy choice for this project, and pairing it with ACF Pro covers almost everything we need on the content-modeling side. We wanted to share something the DevOps engineer of the client found while designing this pipeline, in case it’s useful input for Cornerstone’s future direction—not as a complaint, but as a specific, fixable gap we noticed while holding Pro to the same bar we’d hold any professional-grade dev tool to.
What we found. A page built with Cornerstone stores several distinct kinds of information together, as one document: section/column structure, per-component settings, editor-entered text, references to media IDs, form definitions and their actions, and bindings to Global Blocks/Components. A .tco export moves that whole document as a unit. In practice, that means if a developer changes a page’s structure in a dev environment while an editor changes that same page’s copy or an image in production, there’s no clean way to reconcile the two — the import is whole-document, not field-level, so one side’s changes get overwritten or the import conflicts outright. That in turn means any Cornerstone-built page is effectively pinned to one specific database/environment: it can’t be treated as portable, versioned release state the way the rest of our stack (theme templates, plugin code, theme.json ) can.
Why we’re flagging this specifically for Pro. Pro isn’t a beginner page-builder — it’s positioned for developers and advanced users building serious, ongoing client work, and it already includes the pieces (bundled Cornerstone, first-class ACF PRO support, a real update/licensing API) to be treated as a professional platform rather than a closed website-builder product. We think that segment increasingly expects the same CI/CD, multi-environment, reproducible-build workflow that’s now standard for the rest of a modern web stack — which is exactly what containerization and “Git as source of truth” are about. Right now, the Cornerstone-authored parts of a Pro site are the one piece of our stack that can’t join that workflow, which is a real limiting factor when we’re scoping this kind of client.
A model that already works, and that you already ship. ACF PRO solves a very similar problem for field groups with Local JSON : the definition of a field group is written to a versionable .json file and synced via wp acf json sync , while the values a user enters per post stay in the database, exactly where they belong. That split — schema/definition as a file, content as DB — is precisely what we think Cornerstone is missing today. We’re not suggesting page content itself (what an editor types into a specific page) needs to become file-based — that’s genuinely DB-shaped, per-instance data. But the design-system layer of Cornerstone — Global Blocks/Components, TSS style definitions, and Theme Options — is conceptually much closer to ACF’s field group definitions than to page content: it’s authored by developers, reused across pages, and is exactly the kind of thing a team would want to review in a pull request and ship as part of a release.
The ask, concretely: would Theme.co consider an opt-in “Local JSON”-style export/sync mechanism for Cornerstone’s Global Blocks/Components, TSS definitions, and Theme Options — mirroring the ACF PRO pattern you already ship today? Even a partial version (say, Global Blocks and Theme Options first) would let teams like ours put the reusable, developer-owned part of a Cornerstone site under version control and through a normal review/release process, while leaving actual page-by-page content exactly where it is now. We think this would meaningfully strengthen Pro’s positioning for the higher end of the professional/agency market, where reproducible, git-driven deployment is quickly becoming a baseline expectation rather than a nice-to-have.
Happy to share more detail from our internal research on this if it’s useful — we did a fairly deep dive into how Cornerstone’s update/licensing mechanism and data model work while building our pipeline, and would be glad to compare notes.
Thanks for reading, and for building a theme that’s actually worth taking this seriously about.