WordPress core contributor Alex Shiels has published a proposal for a WordPress.org block directory that would host JavaScript-based, single block plugins. The directory would make blocks searchable and installable from within the Gutenberg editor. Building a directory for discovering blocks and seamlessly installing them is one of the nine projects that Matt Mullenweg identified as a priority for 2019.
Block collections have become one of the most popular ways for distributing a group of related blocks but this method can cause bloat. Users currently cannot search for individual blocks by name and plugin names and descriptions are not always a good indication of what the blocks do.
Shiels proposed the new directory be limited to single block plugins, frontend JavaScript blocks with no UI outside of the editor. It would be a separate section inside the Plugins Directory, optimized for users to find blocks by name and description. Developers would be required to use a block.json file with metadata as outlined in the Block Registration RFC, which provides a technical specification for block type registration.
The most controversial part of the proposal is having blocks installable from within the Gutenberg editor. The long term goal is to make that process as seamless as possible. Block collections and blocks that do not meet the requirements of the single block directory would still be available via the normal plugin installation process. This could be confusing for users who do not know that blocks can be found in two separate directories.
“The Gutenberg editor should NOT be a plugin installation source,” Matt Cromwell commented on the proposal. “That just seems ripe for scope-creep. That’s not its purpose or function. Let it be an editor, layout builder, content manager, etc. Moving into searching an external library and installing plugins is the definition of losing site of the purpose of a ‘product.’”
Cromwell suggested a centralized block manager as an alternative that would offer a better experience for searching and installing blocks. He also echoed other participants’ opinions on the importance of including dynamic blocks in the directory, instead of limiting it to “JavaScript only” blocks.
“A centralized Block Manager like has already been suggested is a far better user-experience for searching and installing blocks than doing that in the Gutenberg editor. I like the idea of single-block plugins being the only option in the Directory. But make sure Dynamic Blocks that depend on other existing plugins or outside functionality are able to be added to that very important Directory as well. I really don’t see a benefit to limiting this Directory so much.”
WordPress developer Jamie Schmid also expressed hesitation about pursuing a solution that puts block installation inside the editor, as it may discourage users from thinking about their block usage across the entire site.
“I am not convinced that making blocks searchable and installable from within the editor is the best solution,” Schmid said. “This, along with page level block controls and style overrides, is encouraging a very short-sighted, page-level solution to an issue that is very likely a global site (or content or even business) issue. I’d love to instead see a central view for all installed blocks – similar to how plugins are, but more organized by type/function/etc and with a visual alongside. This will encourage making decisions at the site level, encouraging some bigger-picture reflection. And same to being able to apply access controls to the installation of new blocks.”
The proposal would place the single block plugin search interface inside the block inserter in the Gutenberg editor. This would enable users to quickly search for and install a block if they don’t see one they need among the existing blocks.
Riad Benguella, Gutenberg’s technical lead for phase 2, encouraged participants in the discussion to think about blocks as pieces of content that do not rely on the post editor but can be configured anywhere inside WordPress.
“It is important to think of blocks as its own unit that have a meaning on its own, and that can be used in different contexts,” Benguella said. “A block is a piece of content (static or dynamic) that can be configured and rendered anywhere.” This includes blocks found both inside and outside post_content, content in a full site editor, inside the WordPress admin, a headless application, or even another CMS.
“We should be ambitious and think about all these contexts (the final picture), but at the same time we should be pragmatic and iterate to achieve this goal,” Benguella said.
The discussion regarding the new block directory and block plugin architecture continues across WordPress contributor teams. Shiels said the proposal was meant as a starting place and contributors are still in the preliminary stage of exploring ideas.
Having a single block in a single plugin causes a fast growth of number plugins installed on a site. That’s a nightmare for users. And the .org will see likely 1000+ plugins for 1000+ different blocks (that doesn’t count duplicated blocks). While the idea of making the blocks searchable, filterable is great, the question on how to manage them is important.