A fork of WordPress 7.0
A CMS for data, not pages.
DMPress takes WordPress 7.0 and re-focuses it as a headless, data-management CMS. The block editor is gone. The plugin ecosystem, the hooks, and the REST API stay exactly where you left them.
Free & open source · GPL-2.0-or-later · Self-hosted
Headless — content over REST Content-Type Builder with custom fields Plugin API kept intact Signed update channel
Why a fork
Twenty years of hardening, pointed at a different problem.
WordPress is superb at what it grew up to be: a publishing platform that renders pages. If what you actually need is somewhere to model, store and serve structured data, a lot of that machinery is weight you carry but never use.
Starting from scratch would mean re-solving problems WordPress solved a long time ago — authentication, roles and capabilities, the media library, i18n, database abstraction, an enormous plugin ecosystem, and a security process with two decades of scar tissue behind it. Those are not the interesting parts of a CMS, but getting them wrong is expensive.
So DMPress forks rather than rebuilds. It keeps the parts that are tried and tested, removes the parts that only exist to render pages, and adds a first-class way to define your own content structures.
The short version
Keep the boring, battle-tested foundations. Drop the page-rendering layer. Make structured content the primary concern rather than an afterthought.
Content typeArticle
Title
Author
Category
Body
What we kept
The tried and tested parts stay, deliberately.
DMPress keeps the wp namespace throughout — internally, in hooks, and on the REST API — so what already works keeps working. This is the whole reason forking makes sense.
✓
The plugin ecosystem
Hooks, filters and the plugin API are unchanged, so existing plugins continue to work. The API is kept intact precisely so site-specific needs have a real home.
✓
The REST API
Same namespace, same shape. It is now the primary way content leaves the system rather than one option among several.
✓
Users, roles & capabilities
The permissions model, authentication and login flow are inherited as-is — two decades of security work you do not want to reimplement.
✓
The classic editor
A familiar, stable editing surface for the content that genuinely is prose, without a block layer on top of it.
✓
The updater machinery
WordPress's own WP_Upgrader still unpacks the package, copies it into place and runs the database upgrade. DMPress adds only the manifest check, the download and the signature verification.
✓
The bundled libraries
jQuery, Backbone, PHPMailer, SimplePie, Requests, getID3, sodium_compat and the rest are redistributed unchanged, licences retained.
Two version numbers, on purpose
$wp_version stays at 7.0 — what plugins check via Requires at least, and what WP-CLI sees. $dmpress_version (1.0.0-beta.83) is the product version shown to users. Plugins that depend on the block editor will not function, but they load without fatal errors: an inert block API shim keeps register_block_type(), has_blocks(), parse_blocks() and friends callable as no-ops.
What's different
Where DMPress parts ways with WordPress 7.0.
| WordPress 7.0 | DMPress | |
|---|---|---|
| Editor | Block editor (Gutenberg) | Classic editor only |
| Front end | Server-rendered by core | Headless — the active theme's index.html is served with no WordPress boot; content comes from REST |
| Themes | style.css + PHP templates, parent/child | A theme.json manifest plus an index.html front end; no child themes |
| Content types | post and page hard-coded | Defined in the Content-Type Builder; both are deletable |
| Taxonomies | category and post_tag hard-coded | Content-Type Builder entries; can be renamed, disabled or removed |
| Custom fields | Plugin territory | Built in — part of the Content-Type Builder |
| Admin menu | Flat top-level items | Consolidated Admin menu with grouped headings |
| Comments | Global sidebar item | Per-post-type submenu, enabled per type |
Also removed: Site Health, the Settings → Privacy and Connectors sections, the Customizer and Theme File Editor menu entries, the dashboard content widgets, and core self-update.
Every change relative to stock WordPress 7.0 is itemised in DMPRESS-CHANGES.md, together with the known consequences of each decision.
Built in — Content-Type Builder
Define your structure in the admin.
Post types, taxonomies, options pages and custom fields are all defined through the Content-Type Builder — no code, and no plugin to install first.
It is powered by Secure Custom Fields 6.9.1, the WordPress.org open-source fork of Advanced Custom Fields, bundled into core rather than bolted on. Even post, page, category and post_tag are ordinary entries here — you can rename them, disable them, or delete them outright.
Field group
Text
Relation
Repeater
Taxonomy
Headless by design
The front end is yours entirely.
DMPress renders no HTML. Any path that is not a real file is served the active theme's index.html, with no WordPress boot at all — so your front end owns its own routing and uses real URLs.
Because nothing is rendered server-side, the permalink structure is not about page rendering — it is the URL contract between the CMS and your front end. The structure is published in every REST link field, and your theme routes on those URLs. Unknown paths answer 200 with the app shell, and the front end renders its own "not found".
🔗
URL contract
Permalinks as routes
📄
App shell
Your index.html
Updates
Its own channel, signed end to end.
DMPress does not use the wordpress.org update channel — that would offer stock WordPress over the fork. It has its own, keyed on the product version and served from GitHub Releases.
🔏
Ed25519-signed
Packages are signed and verified before they are applied, so a spoofed or tampered download is rejected.
🕑
Checked, never forced
Installs check a signed manifest twice a day and surface an update in the dashboard. Nothing installs until an admin clicks.
🛡️
Fails closed
The channel stays dormant until a signing key is configured — it never offers an update it cannot verify.
No automatic rollback — take a backup first
DMPress publishes no rollback package, so a core update that fails partway is not reverted automatically. Back up, and try a new release on a throwaway install before applying it to anything you care about. This matters more than usual while DMPress is in beta.
Scope & release policy
DMPress aims to be boring to upgrade.
WordPress ships major releases several times a year, each one broadening what the platform does. DMPress deliberately does the opposite: the scope — a headless CMS for structured content and data — is settled, and staying inside it is the point.
✓
Security and stability first
Security fixes and real bugs are the reason a release happens, and they ship as soon as they can be verified.
✓
Infrequent by design
Fewer, smaller releases mean fewer regressions and less to re-test. An upgrade you can apply without studying the changelog is the goal.
✓
Features are the exception
Good ideas outside the scope are usually declined — good ideas are not scarce, but a small, predictable surface is. Site-specific needs belong in a plugin.
✓
Nothing ripped out casually
Churn in either direction costs the people running the software.
This is a default, not a doctrine. If the ground genuinely moves, the scope gets reconsidered openly rather than quietly extended — the bar being "this changes what the software needs to be", not "this would be nice to have".
Get started
Try the beta.
DMPress is at 1.0.0-beta.83. Take it for a spin on a test install — just not on anything you cannot afford to break yet.