Block Plugins and the Block Directory

Over on Make Design, the design project for installing plugins from within Gutenberg is underway.

It’s time to kick off the discussion about blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. plugins themselves. There’s already been some discussion of this on an earlier post about blocks in the plugin directory. That raised a bunch of great points and questions, which this project will attempt to solve.


Our plan is to create a new kind of pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the Plugin Directory or can be cost-based plugin from a third-party, where *the plugin is a block*. These plugins will be familiar to plugin developers, but specially crafted so that they can be safely and seamlessly installed by users from within the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. editor. They’ll be hosted in a special new section of  the existing WordPress plugin directory.

Main requirements:

  • Gutenberg editor designers and developers need a way to search the plugin directory for blocks that can be seamlessly installed.
  • The plugin directory needs to index and show metadata about blocks.
  • Users need a way to make a simple and safe decision about whether or not to install a block.
  • Site administrators need a way to manage the blocks and plugins that are available on a site.
  • Plugin developers need ways to clearly communicate the purpose and features of their plugin blocks.
  • The plugin review team needs to set and enforce clear rules about plugin code and behaviour.


  • We’ll be designing the architecture for a new type of plugin that is focused on single blocks. These plugins are blocks.
  • The  new plugin type will be a subset of the existing WordPress plugin architecture, and compatible with the existing install and update systems.
  • The new plugin architecture will have some additional limitations and restrictions over and above regular plugins, such as limited UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. and server-side code.
  • We’ll consider the feasibility of block previews, that could be displayed inside the editor prior to installing the plugin itself.
  • Security implications will be critical.
  • We’ll look at the needs of developers with respect to server-side rendering and coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. APIs.
  • We’re aiming to produce a simple initial version that can be ready in time for the WordPress 5.3 release.

Next steps:

  • Scoping the plugin architecture in more detail.
  • Designing the simplest block plugin that could possibly work.
  • Creating a separate section within the plugin directory for block plugins.

When and where to follow along:

  • The fortnightly MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. Chat, every second Wednesday at 2100 UTC (right after the Core Dev chat)
  • Regular discussion in #meta between formal chats
  • Important updates will be posted on Make Plugins and Make Meta

Who is involved:

#block-directory, #blocks