Join GitHub today
Block API: Initial explorations to migrate to server-registered blocks #3962
This pull request starts to iterate toward server knowledge of registered blocks. This isn't intended to limit the capabilities of a client editor, such that editors are strictly dependent on a WordPress back-end, but opens options for the server to operate from a list of all known blocks (e.g. a settings page dropdown for "default block type", REST API endpoints listing all available blocks on a site).
Eventually I could see this tying into #2756, where all blocks begin by registering a block type from the server, with an associated script handle to define the client-specific form handling. The script may even be optional for very early block prototyping. Having better awareness of blocks and their associated scripts and styles could also enable two optimizations:
The first iteration seeks to expand the scope of the already-present server block attributes bootstrapping to include a broader range of block properties, not just attributes.
It also improves the server fixtures generation to load more of a WordPress context, as previously we'd merely stubbed the
The paragraph block was ported as an example, though I'm not sure I'd want to merge with a single example port. I think it'd be preferable to either port all blocks, or none at all.
Verify that there are no regressions in the registration of the paragraph block, including title, icon, category, keywords, supports (custom class name), attributes behaviors.