Modern Block Editor APIs

Build editor and frontend experiences through current public block APIs while treating experimental packages cautiously.

2 min read

  • Article
  • Advanced
  • 2 minutes read
  • Reviewed August 4, 2026
  • Advanced WordPress and integrations

The Block Editor is an application platform built from server and JavaScript APIs.

Modern block development combines metadata, React-based editor components, server rendering, data stores and optional frontend interactivity.

block.json

block.json is the canonical metadata file for a block.

It can declare:

  • Name and version.
  • title and category.
  • attributes.
  • supports.
  • editor and frontend scripts.
  • styles.
  • server render file.
  • context.
  • variations and selectors.

Server registration from metadata allows WordPress to optimize asset loading and expose the block consistently.

Static and Dynamic Blocks

A static block saves markup through save.js.

A dynamic block renders through PHP on each request. Dynamic rendering is useful when output depends on current data, permissions or server logic.

Deprecations can migrate older saved markup.

WordPress Data and Components

The @wordpress/data package provides registered stores, selectors and actions.

The component library provides editor interface controls, but packages can have stable, experimental or private APIs. Avoid _experimental and __unstable exports in long-lived products unless the risk is accepted.

Block Bindings

Block Bindings can connect supported block attributes to external sources such as post metadata or custom binding providers.

Define schemas, permissions and editor behavior for the bound data.

Interactivity API

The Interactivity API provides a standard directive-based model for frontend block interactions.

It works with server-rendered markup and supports state, context, actions and client-side navigation. It is available in core from WordPress 6.5.

Script Modules and Builds

Modern blocks can use Script Modules and WordPress packages through tools such as wp-scripts.

Build manifests must preserve WordPress dependency metadata and production assets.

Frequently Asked Questions

Must every custom feature be a block?

No. Use blocks when the feature belongs in content or template composition.

Are all @wordpress packages stable public APIs?

No. Review documentation and experimental naming before depending on them.

Continue Learning

Previous: Deployment and Continuous Integration

Next: The WordPress Abilities API