WordPress 7.0 finally lets you build a block without writing JavaScript

A WordPress block could be tiny as a product feature and oddly oversized as a toolchain.

Take three lines calculated in PHP. The server already knows how to produce the HTML. Gutenberg still wanted a client presence: register the block in the browser, load @wordpress/blocks, provide edit, and often build the JavaScript. A lot of machinery to say a second time that the block exists.26

Since WordPress 7.0, that detour is no longer mandatory for the simplest case.

Declare supports.autoRegister, provide a render_callback, and a server-rendered block can appear in the editor without your own JavaScript registration.12

The new option is almost a one-line change. For some blocks, that is enough to keep the useful definition in PHP.

register_block_type(
    'irz/server-note',
    [
        'title' => 'Server note',
        'attributes' => [
            'text' => [
                'type'    => 'string',
                'default' => 'Hello',
            ],
        ],
        'render_callback' => function ( $attributes ) {
            return '<p>' . esc_html( $attributes['text'] ) . '</p>';
        },
        'supports' => [
            'autoRegister' => true,
        ],
    ]
);

That declaration is enough for the minimal case documented by WordPress.1

It does not mean Gutenberg has become a PHP application.

What actually disappears

Before WordPress 7.0, the documentation normally recommended registering blocks on the server and on the client. Server registration enables dynamic rendering, Block Supports, Block Hooks, style variations and other features that depend on the PHP registry. Client registration, through registerBlockType(), gives the Block Editor its definition of the block and its editing interface.2

A dynamic block could end up with two entry points:

register_block_type(
    'irz/server-note',
    [
        'render_callback' => 'irz_render_note',
    ]
);

and then in the browser:

import { registerBlockType } from '@wordpress/blocks';

registerBlockType('irz/server-note', {
    edit: Edit,
});

Around those two calls you would often find block.json, imports, @wordpress/scripts, dependencies and compiled output. The older CSS-Tricks tutorial captures the exact moment a modest block walks into “React and JSX land”.6

For a genuinely rich editing UI, that was reasonable. For one server-calculated value and two Inspector settings, the plumbing could become larger than the feature.

PHP-only means your PHP

The most important nuance is hidden in the feature's name.

WordPress calls it PHP-only block registration, not a JavaScript-free editor.1

When autoRegister is true, Core sends the block definition to the client. The WordPress 7.0 Field Guide says these blocks are exposed client-side through a JavaScript global variable.4 The Block Supports documentation says the editor then registers them automatically and uses ServerSideRender for their preview.3

In practice, the developer can remove several pieces:

• you no longer write registerBlockType();
• you do not need an edit.js file for the minimal case;
• you can avoid a JavaScript build chain if the plugin has no other reason to need one;
• WordPress still runs JavaScript to make the editor work.

This is not WordPress going back to pure PHP. Core is simply removing manual synchronization when the server already knows enough.

The editor invents the controls it can

An auto-registered block would not save much if Gutenberg could only show an inert rectangle.

WordPress 7.0 then tries to build Inspector controls from the attributes registered in PHP.14

The official example includes string, integer, boolean and an enumerated string. When the attribute type is supported, the editor can turn that metadata into standard fields.1

The registry begins to act like a small data schema.

'attributes' => [
    'title' => [
        'label'   => 'Title',
        'type'    => 'string',
        'default' => 'Hello World',
    ],
    'count' => [
        'label'   => 'Count',
        'type'    => 'integer',
        'default' => 5,
    ],
],

You describe values. WordPress supplies conventional UI when it knows how.

The “when” matters. The dev note explicitly says controls are not generated for attributes with the local role or for unsupported attribute types.1

This is not a universal interface generator.

Rendering stays dynamic

An auto-registered block must provide a render_callback.13

That requirement immediately tells us where the boundary sits.

The final HTML still comes from the server and the current attributes; it is not frozen by a JavaScript save() function. This remains the familiar dynamic block model.

That is enough for plenty of ordinary components:

• a list calculated from database data;
• a panel whose content depends on site state;
• business data already available in PHP;
• a block integrating a server-side plugin;
• a simple component in a classic theme beginning to adopt Gutenberg.

The dev note specifically names classic themes and server-driven workflows as likely beneficiaries.1

For this sort of code, requiring React just to provide a basic editor presence often felt less like an interface requirement and more like an entry fee into the block ecosystem.

autoRegister lowers that fee.

What it does not replace

WordPress leaves little suspense here: the API is not meant to replace the client-side paradigm and is not intended to become equally featureful.1

That is the boundary worth keeping visible.

If your block needs:

• sophisticated direct editing in the canvas;
• rich interactions between several elements;
• a bespoke React component;
• client behaviour that cannot be described as a few attributes;
• a deeply customized editing workflow;

then a real client-side edit implementation remains the right abstraction.

There is no PHP-versus-React victory here. WordPress simply stops forcing the simple case to resemble the complex one.

That matters more than the number of files saved.

One less maintenance surface

Put ten small dynamic blocks in one plugin and the maintenance difference stops being theoretical.

Previously, each could have a server definition and a client definition that needed to stay aligned: name, attributes, supports and sometimes preview behaviour. block.json had already reduced some duplication by acting as shared metadata.2

autoRegister goes further for the subset that does not need custom client code.

Business logic can stay in PHP; you describe attributes and rendering, while Core manufactures the minimum editor presence.

The useful saving is not necessarily JavaScript weight. It is the number of places that can drift out of sync.

One registry instead of two. One less toolchain when it adds no value. One environment to debug for the business rendering.

That does not make Gutenberg simple.

It finally allows a simple block to remain simple.

The question is no longer “do I have to learn React?”

Gutenberg often turned a small product question into a stack decision.

“I want to add one small component to the editor” quickly became “do I need Node, JSX, WordPress packages and a bundle?”

For many blocks, yes. A rich extension of the editor still needs rich client-side APIs.

What changed is that there is finally an exit before you get that far.

If your requirement fits simple attributes and a render_callback, you can stay in PHP.15

If the editing experience becomes more ambitious, move to the client.

This is not a return to pre-Gutenberg WordPress.

It is Gutenberg finally learning that a trivial component does not need to pretend it is an application.