Adds features to use WordPress as a headless CMS: extra fields and prepared block content on the REST API, custom routes for menus and site settings, a preview that points at your frontend instead of the WordPress theme, and cache revalidation for frontends that support it.
Configuration
The plugin is configured with constants in wp-config.php:
HEADLESS_HEAD_BASE_URL— base URL of your frontend. Preview and revalidation requests go here.HEADLESS_SECRET_TOKEN— shared token sent to the frontend’s/api/previewand/api/revalidateendpoints.HEADLESS_API_KEY_HEADER_KEYandHEADLESS_API_KEY_HEADER_VALUE— require this HTTP header on requests that use the plugin’s REST additions.
Who can read the responses
The plugin’s REST additions activate on requests carrying ?headless=true. That
query parameter is a routing flag, not authentication — anyone can set it. Unless
you configure HEADLESS_API_KEY_HEADER_KEY and HEADLESS_API_KEY_HEADER_VALUE, the
/headless/v1/menus and /headless/v1/settings routes and the added post fields are
readable by anyone who can reach your REST API. Configure the API key if that is not
what you want.
HEADLESS_SECRET_TOKEN is a single shared secret, and the admin pages hand it to the
browser so the editor can open a preview. Every user who can edit posts — Contributor upwards — can therefore read it and use it against your frontend’s preview and revalidation endpoints directly. Treat it as a secret shared with your whole editorial team, and give the frontend its own rate limiting.
Arbitrary section
- BREAKING CHANGE 1.7.0: core/block for block references has changed