WordPress PHP-Only Block Registration

In WordPress 7.0 the core team introduced a new `register_block_type` option—`'supports' => ['autoRegister' => true]`—that lets a block be defined solely in PHP. The example from CSS‑Tricks shows a “Hello World” block whose render callback returns HTML and whose attributes are declared in the same PHP array. WordPress then emits the minimal client‑side script required for the block to appear in the editor and to render in the preview sidebar. This removes the traditional double‑registration step (PHP plus a separate JavaScript module) and eliminates the need for a Node‑based toolchain, which has been a barrier for many PHP‑centric WordPress developers.

The change arrives 7½ years after Gutenberg’s debut, at a point where the block ecosystem is dominated by React‑based plugins and theme builders that rely on npm, webpack, and Babel. By offering a “no‑JS” path, WordPress is trying to broaden block authoring to the huge base of developers who are comfortable with PHP but hesitant to adopt modern JavaScript stacks. However, the trade‑offs are built into the architecture: PHP‑only blocks are rendered via a REST endpoint, so they cannot participate in the editor’s client‑side store, cannot embed interactive controls in the block preview, and cannot attach JavaScript behavior to their markup. Consequently, dynamic features such as in‑place editing, sliders, image uploads, or any UI that depends on live post data (e.g., the post title) will be stale until the post is saved and reloaded. Moreover, because the REST call does not receive the current post ID, template tags that rely on global `$post` (like `the_title()`) are unavailable in the editor preview.

Developers should view the PHP‑only API as a shortcut for simple, static‑content blocks—e.g., a static call‑to‑action or a decorative divider—rather than a replacement for full‑featured Gutenberg blocks. Watch for core updates that might expose the post ID to the render callback or allow custom client‑side scripts to be attached, which would mitigate the current limitations. In the meantime, plugin authors may need to maintain parallel JavaScript implementations for richer blocks, preserving the existing build pipelines they already support.