Phase 3: Block Library

[priethor]

This overview is a living document originally based on @mtias' Phase 3 Block Library post.

Now that blocks are able to model and express an entire site, it’s important to improve the way they can be organized, listed, and installed by users. The overall goal is to improve how block management works outside the editors — for example, by allowing the disabling of blocks globally across a site, not just as user preferences.

Wall of block icons
We should connect functionalities that might already exist but are not fully developed as user features yet. For example, the relationship between single blocks, post formats, and custom post types. There’s code built in that tries to coordinate what initial block to show on the editor canvas by checking what’s the default post format (paragraph for standard posts); if the default format was Image a user would see an image block placeholder when creating a new post instead of an empty text prompt. This kind of customization is currently a bit obscure and could be more powerful if it allowed to more easily configure default block type across post types. It should also connect with other workflows like “quick post” interfaces in the dashboard.

It also means introducing more robust permission handling across the various capabilities (block registration, locking, etc) so administrators can define what blocks are available for different user roles (or even what capabilities of individual blocks are to be exposed). The fact that theme.json files are inherently composable should allow for more granular handlings of capabilities in a systematic way. For example, consider a fictional author.theme.json that sets, disables, and controls what tools and settings are available for authors over the root config file.

There are a couple important block API items to list that can have consequences on user flows as well. One example is to introduce an auto-insert mechanism so that plugins can better interact with the site document (and block trees) in a way that respects user control.

Furthermore, as part of the ongoing work on patterns, it’s time to start formalizing a connection between blocks and meta fields to empower building flexibility while retaining user clarity. For example, it should be possible for an administrator to set up a custom post type, powered by a block pattern, where each individual block has content attributes connected to a specific meta field rather than post content. All could be accomplished within the block editor interface.

Finally, it’s also important to improve how installing blocks from the directory works, how we handle missing block types and reinstallation, how themes and patterns could reference third party blocks, etc. This also implies better visualizations of blocks introduced by larger plugins.

Scope

This is a summary of the broad tasks we need to look into:

• Add a section next to, or under, plugins to manage blocks globally. This means expanding the current block manager to allow enabling and disabling blocks across a site.
• Introduce more robust permission handling so administrators can define what blocks are available for different user roles.
• Create auto-insert hooks and API flows for block types. This is a developer tool with user flow implications. Block Hooks: Iteration for WP 6.6 #60252
• Improve the mechanics of the block directory with better visualization of blocks bundled in plugins and better flows for themes and patterns using third party blocks on templates.
  • Related: Proposal for Core Blocks in the Directory #58773
• Develop API integrations for mapping attributes to custom fields using the editor interface. The idea being blocks can provide a native UI for managing and introducing meta data through its attributes layer.
• Allow managing categories for saved patterns. Expose other pattern APIs, like block type or parent dependencies in the user flows.
• Develop the concept of Partially synced patterns #50456. These allows the design layout and the style properties to remain global while the content can be locally customized.
• Extensive application of theme.json partials on groups of blocks (control settings and styles on specific templates, parts, patterns). Explore full theme.json settings objects on a per user role.
  • Pattern styles #59404
  • Related: Colors and typeset variations from theme style variations #56604
• Introduce the concept of Blocks: States #57719 as a way to edit blocks that behave or look differently depending on certain conditions and triggers by any block.
  • Incorporate aspects of Block Visibility Plugin as core editor functionality