← All posts

WordPress 7.0: PHP-only blocks without React or a build step

autoRegister in WordPress 7.0 lets you register a block in PHP alone—great for migrating legacy themes, weak for interactive new blocks.

Tags
Newsfrontendphpwordpress
WordPress 7.0: PHP-only blocks without React or a build step
Contents

In brief

Seven and a half years after blocks landed in Core, WordPress 7.0 lets you ship a custom block with PHP only—no React, npm, or build pipeline. The switch is supports.autoRegister: Core generates client registration and the editor preview. CSS-Tricks walks through Hello World, attributes, and why this path does not replace full JavaScript block development.

What happened

A traditional block is registered twice: once in PHP, once in JavaScript. The new mode keeps a single register_block_type call with a render_callback and 'autoRegister' => true. The editor shows server HTML; when settings change, the preview is re-fetched over REST.

Attributes are declared in PHP (string, number, boolean) and map to basic controls in the Settings sidebar—no custom React UI required.

The architecture is simple, with hard limits: the block preview is not a first-class citizen of the editor SPA. Markup is swapped asynchronously, so in-preview interactivity and reliable DOM hooks are effectively off the table.

Why it matters

Many teams stay on classic themes because of legacy PHP: shortcodes, widgets, custom headers. Moving to block themes meant learning React and wiring a toolchain. PHP-only registration removes both barriers for migration: wrap working server code in a block in hours instead of rewriting everything in JS.

For new interactive blocks the path is weak: no in-place editing in the preview, no image upload or multiline rich text in the sidebar, and no fresh client-store data (a PHP block showing the post title keeps the DB value until you save and reload). Post context via Loop globals is also unreliable in the REST preview—an architectural limit as of 7.0.

The author’s formula: valuable as a bridge into block themes, not as a substitute for JavaScript blocks built from scratch.

In practice

  1. Use PHP-only for widgets, shortcodes, headers/footers, and anything that already works on the front end without editor interactivity.
  2. Do not demand a perfect preview: front-end correctness wins; a placeholder (like Post Content) is fine.
  3. Styles via style / editor_style and get_block_wrapper_attributes(); scripts only as view_script on the front end.
  4. Detect editor vs front render with wp_is_rest_endpoint() plus a block-renderer route check—is_admin() will not help.
  5. Work around missing post ID carefully (local attribute from $_GET['post'] at registration)—new drafts get an ID only after save and a full reload.
  6. Only three attribute types today; dropdowns lack label→value pairs—avoid storing only a renameable category slug.

Takeaway

WordPress 7.0 closes a long gap: PHP developers can bring legacy into block themes without React. The cost is a thinner editor UX and stale preview data. Strong for migration; for a complex new block, still choose JavaScript.