WordPress Explores Proposal for New Block Directory to Host Single Block Plugins

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.

A mockup of what inline block installation might look like

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.

12 Comments


  1. 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.

    Report

    Reply

    1. Pick your poison though. Would you rather have someone install a single plugin with 30 blocks in it loading all assets on every page and only needing a single block?

      OR

      Would you rather have someone install 10 different plugins containing a single block in each the amount of bloat is still less than the 30 blocking being bundled into a single plugin?

      Report

      Reply

      1. How about the plugin with the 30 blocks has an admin panel loaded with it that can turn on or off the blocks you are not using to get rid of so called bloat??

        Report


    2. So? Plugin count isn’t a problem, only complexity is.

      Report

      Reply

  2. This is no worse than anything else about Gutenberg.

    Report

    Reply

  3. Being able to install a block from within the editor sounds like a good idea to me. I find it similar to installing an extension in VS Code: while programming, if I find I need a certain functionality, the UI allows me to quickly install an extension, which will be enabled instantly, without having to restart the application. Programming like this is such a breeze. If Gutenberg could achieve something similar, so that the user could install a required functionality while editing the post, would be pretty helpful. (It’s one of those things that you don’t pay much attention to, but once you have it, you can’t do without it.)

    However, I do agree that this can lead to bloat, allowing users to install more blocks than are required. So the UI should make it easy to install blocks, but not so easy as to be overused, and always making sure the user knows what he/she is doing. And not all users should have access to this functionality, so I guess a capability “can_install_blocks_from_editor” would make the site admins be able to sleep at night.

    My vote is for it, but only if it is done properly.

    Report

    Reply

    1. Another thing to take into account is if the block is static or dynamic or, more specifically, if it will load JS assets only in the admin, or in both the frontend and the admin. If it is a static block, simply saving its HTML in the post content and not loading any JavaScript, then even if we install 300 of these blocks, it doesn’t really matter because the bloat is restricted to the admin side, so people browsing the website are not affected (also CSS, but it’s not as bad as JS bloat). And disabling these blocks at a later stage, once the user finds out about the bloat, will not break the website either, so it is kind of safe. Main problem is dynamic blocks, since these could break the site when disabled.

      Report

      Reply

  4. I think we need to keep block installation out of the editor itself (since blocks are going to go beyond the editor Real Soon Now), but I would far rather have 30 plugins that just do one thing than 3 plugins that do 10 things each–especially when 9/10 of those things are the same.

    It’s not how many plugins you have, but how well each is coded and whether there are conflicts. I want to be able to add just the blocks I need.

    Report

    Reply

  5. I really like this concept of unbundling blocks – ala carte baby!

    Even though these singular blocks are installed with a plugin, I don’t think they should be listed in the Admin – Plugins listing.

    Perhaps all the installed singular blocks would be included in a new Admin menu. For example Admin – Blocks or Admin – Appearance – Blocks.

    Bottom line, I would like to be able to manage Blocks quickly without having to drill down into the Block Editor…

    Report

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.