WordPress 7.0 Introduces PHP-Only Block Registration
WordPress 7.0 introduces a streamlined approach to building blocks using only PHP via an autoRegister flag, though key interaction and data limitations remain.
Stock photo for illustration only, not from the actual event
- WordPress 7.0 adds a way to build blocks using only PHP without writing JavaScript.
- The key addition is the 'autoRegister' => true flag in the supports section.
- Major limitations include no content interaction inside the block and no in-place editing.
- PHP-only blocks query the database directly, leading to potential stale data issues before saving.
Seven and a half years after blocks arrived in Core, WordPress has introduced a method to build blocks without requiring any traditional JavaScript development. With WordPress 7.0, developers can now register a block using strictly PHP.
This radically simplified approach streamlines the traditional process where a block had to be registered twice in both PHP and JavaScript. The core addition in this release is the 'autoRegister' => true flag within the supports section, which allows WordPress to automatically generate the required JavaScript for client-side registration and editor previews.
Stock photo for illustration only, not from the actual event
Beyond simple registration, defining attributes for customization is handled directly during the block registration phase without needing to build custom controls in the editor interface, reminiscent of simpler programming times for traditional developers.
This architectural shift in WordPress 7.0 highlights an effort to lower the barrier for backend PHP developers. However, relying entirely on PHP rendering via REST endpoints introduces architectural trade-offs regarding interactivity and real-time data synchronization that developers must carefully consider.
Despite its appeal, the PHP-only block approach comes with crucial limitations to understand:
- No interactions with block content: Users are restricted to auto-generated controls in the settings sidebar, with no support for in-place editing or image uploads inside the block.
- No JavaScript attachment to markup: Because markup is fetched asynchronously and replaced on every re-render, interacting with the DOM for interactive UI components like sliders breaks inside the editor authoring experience.
- No access to fresh data: PHP-only blocks bypass the client-side store and query the database directly, meaning changes made in the editor like post titles will not appear until the post is saved and reloaded.
- No access to current post context: Because REST APIs are stateless and the editor component does not pass a post ID parameter, template tags and functions like get_post_meta() fail to recognize the active post context in the editor preview.
Source: CSS-Tricks
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment