PHP-Only WordPress Blocks: No React, No Build Step

Inside render.php you get three variables for free: $attributes (your block settings), $content (inner blocks, if any) and $block (the block instance). Use get_block_wrapper_attributes() so your block picks up alignment, custom classes and the block supports WordPress adds automatically.

Finally, register it. One line in your plugin or theme:

• add_action( 'init', function() { register_block_type( __DIR__ . '/blocks/notice' ); } );

Point register_block_type() at the folder containing block.json and WordPress does the rest. Refresh the editor, search for "Notice" in the inserter, and it's there. Three files, zero build tools.

Making it editable without a build step

The honest answer: for text and settings, you edit PHP-only blocks through the sidebar controls, and WordPress can generate those controls from your block.json attributes — but true click-into-the-block editing still needs JavaScript. Here's how to get a genuinely usable editing experience anyway.

For most content blocks, lean on inner blocks. Instead of storing the message as a custom attribute, let editors type directly using core blocks nested inside yours. In block.json you'd drop the message attribute and in render.php you echo $content. The editor then shows a normal paragraph the user can style, link and format with the tools they already know. You wrote no JS and gave them a rich editing surface.

For the settings that aren't content — a "tone" dropdown, a toggle, a number — you have two clean options. Expose them through the block's HTML comment attributes and let a power user set them, or add a tiny sidebar panel. That panel is the one place a few lines of JavaScript genuinely pay off, and you can inline it without a bundler because it's plain ES5-compatible wp.blocks and wp.element calls enqueued as a normal script. No compilation required — just don't write JSX.

When PHP-only is enough — and when it isn't

Use PHP-only blocks whenever the block's output depends on server data or the editing needs are simple; reach for a full JavaScript build when editors need live, in-canvas interaction or heavy custom controls. That line is clearer than most tutorials admit.

A useful rule of thumb: if you were about to write a shortcode, write a PHP-only block instead. You get the same server-side simplicity plus a proper inserter entry, block supports, and a preview — without the shortcode's clunky [bracket] UX. Dynamic content is where this shines, because that content should render fresh on every page load anyway.

Where PHP-only starts to strain is bespoke editing. If a client needs to visually arrange cards, drag a slider and watch spacing change in real time, you're rebuilding an interactive UI — and that's what React-based blocks exist for. Don't fight it. Knowing which side of the table you're on saves hours.

A quick pre-launch checklist

Before you ship a PHP-only block to a client site, run through these to avoid the common gotchas.

• Escape everything on output — esc_attr(), esc_html(), wp_kses_post(). Render callbacks run on the front end, so treat every attribute as untrusted.
• Use get_block_wrapper_attributes() so alignment and custom CSS classes actually apply.
• Set apiVersion to 3 in block.json — older values miss recent features.
• Enqueue block CSS via block.json using the style and editorStyle keys, not a global stylesheet, so styles load only when the block is present.
• Test in a staging copy first. If your host gives you an easy staging environment, clone the site, register the block there, and confirm the editor preview matches the front end before touching production.

That last point matters more than it sounds. Because PHP-only blocks render server-side, a fatal error in your render.php can white-screen the editor. Catching that on staging keeps a client from ever seeing it. On TPC Hosting you can spin up a staging site, break things freely, and push the working version live once it checks out — with real engineers on hand 24/7 if something goes sideways.

Why this is a genuinely good moment for freelancers

PHP-only registration means the barrier to custom blocks is now roughly the same as writing a shortcode — which most of us have done a hundred times. That's the whole story, and it's a big deal for anyone running client sites without a front-end build habit.

For small agencies especially, this cuts maintenance. A block with no compiled bundle has nothing to re-build when Node updates, nothing to break when a dependency deprecates, and nothing a future developer has to reverse-engineer. It's just PHP in a folder. When you hand a site over — or inherit one — plain PHP blocks are far kinder than a mystery build/ directory.

If you host client sites with us at TPC Hosting, you already have the pieces: PHP version control, staging, and free migration if you're bringing sites over from elsewhere. Build the block, test it on staging, ship it. No toolchain tax.

FAQ