Proposal for Core Blocks in the Directory

[mtias]

There's a growing subset of blocks that we may contemplate creating that are either more niche or—for various reasons—not necessarily an immediate fit for the bundled library in core. [Some examples.] This would include blocks that have enough appeal, demand, and where offering an endorsed implementation can significantly help both creators and viewers given best practices can be ascertained.

I propose we look at a mechanism where such blocks can be designed, developed, published, and maintained by core contributors in this repository (benefits from collocation and testing infrastructure) but for them to be published as standalone blocks in the directory instead of bundled in the default library. These blocks would show up as authored by [WordPress.org]. It'd allow themes and patterns in the directory to leverage them with certainty.

[colorful-tones]

and where offering an endorsed implementation can significantly help both creators and viewers given best practices can be ascertained.

❤️

(benefits from collocation and testing infrastructure)

This is a significant benefit that could easily be overlooked, while certainly offering some risk. Overall, I endorse this idea and I look forward to any dialogue or side-effects that come along with it.

[philwp]

I really like the idea of this. There is no reason to give all users tons of blocks by default, but having the option to install the "Core" blocks your site needs is a great idea.

It'd allow themes and patterns in the directory to leverage them with certainty.

This sounds like themes and patterns would be able to list these blocks as dependencies, strongly support this.

[Luehrsen]

Very much yes. I am all in favor of a slimmer, easier to maintain core.

Maybe, as a follow up, we could critically examine the existing blocks in the block library and check if they could be migrated to the repository.

[ndiego]

Love this idea. I know of a little icon block that might be a good candidate for this 😉

[colorful-tones]

It is critical to update the issue description and call out that we're talking about the Block Directory and not plugins that will each install a block. Folks still need clarification on these two separate paradigms.

[ndiego]

It is critical to update the issue description and call out that we're talking about the Block Directory and not plugins that will each install a block. Folks still need clarification on these two separate paradigms.

Please correct me if I am wrong, but I think we are talking about single-block plugins, which will show up in the Block Directory. These plugins will live here in this GitHub repo and in the Plugins Repository as standalone plugins that can be installed individually. These would be "Community" plugins that are authored by WordPress.org.

[colorful-tones]

Please correct me if I am wrong, but I think we are talking about single-block plugins, which will show up in the Block Directory. These plugins will live here in this GitHub repo and in the Plugins Repository as standalone plugins that can be installed individually. These would be "Community" plugins that are authored by WordPress.org.

I think it is critical to evaluate the definitions a bit more and likely update the Issue to description in order to focus folks' feedback. Heck, my own understanding may be fragmented, and it does not help anybody in assuming. 🤷

[joedolson]

I think this is a good way of providing some stable blocks for features that are desirable but don't meet the 80/20 rule. I'd just want to make sure that blocks that end up in the directory still meet our standards for accessibility, and that a system is in place for ensuring that they get regular updates. Gutenberg should still be the place for experimentation; anything shipped elsewhere (core or a standalone plugin) should meet all the other expectations for core.

[aurooba]

I think this is a fantastic idea! I agree with @joedolson's concerns. If a good system is setup for ensuring it stays maintainable, then this is awesome. (The Time to Read block would also be a great candidate for this)

[hashimwarren]

Great idea!

Would also like to see these additional core blocks developed around tight uses cases.

As a site builder that would make discovery and usage easier.

For example:

• e-commerce block collection (that's not tied to Woo)
• calendar block collection
• newsletter block collection with email client safe HTML
• form block collection, with blocks for many different form fields

[StevenDufresne]

Would these blocks be given preference in the block directory search results?

[bph]

Here is the list of blocks, people I talk to find often missing.

• Table of contents, (in GB but not in Core) (still needs some refactor)
• Tabs,
• Breadcrumbs
• Mega Menus,
• Accordion variation for Detail/Summary, or stand alone
• Icons (Nick's plugin could work)
• Card block
• Slider - especially for mobile viewing

Yes, should they should bubble up as suggestion with preference
Yes, I agree with @ndiego as to single block plugins would be best as they show up in the inserter on searches. (Such a great hidden to discover new blocks!)

[carstingaxion]

Yes, this would help a lot!

As I understood the proposal, we talk about single-block plugins that are installable like every other plugin. Plugins of such a kind should be tagged with the new community tag, which seems more important (to me) than the ownership itself.

The WordPress Performance team has made some attempts to publish parts of the Performance lab plugin as separate plugins and just recently published two new plugins. Both have the community tax term, but unfortunately I don’t know where the plugins are built from and if they took this way. We should ask them if nobody over here knows.

My additions to the wishlist would be the following:

• Abbreviation Button for the Block Editor by @audrasjb
• a kind of a Copyright Block like the one by @mkaz
• Block Catalog by @jeffpaul among others
• Block Visibility by @ndiego
• Icon Block by @ndiego
• Lang Attribute for the Block Editor by @gturpin-dev
• Markdown Comment Block by @richtabor
• Social Sharing Block by @ndiego
• Superlist Block by @aurooba
• Todo Block by @davidtowoju

[audrasjb]

Thanks for the proposal! And thanks for the mention @carstingaxion!
Worth noting that my Lang Attribute plugin (co-authored with @gturpin-dev) was merged in #49985 :)
But it would be nice to get the abbreviation one merged as well!

[carolinan]

How would WordPress ensure that all single block plugins are kept up to date and at the very least receives security updates?
Speaking from experience the contributors have not been able to keep the default themes updated.
I'm just saying that it might not be an easy promise to keep and expectation to live up to.
Is this something you would expect the plugin's team to manage?

How would WordPress manage retiring the single block plugins, in case it was decided that the feature should be in core, after all?

I don't agree that these single block plugins should be in this repository, it could create more confusion about what Gutenberg is, and wouldn't be easier to maintain.

[courtneyr-dev]

If this passes, can we have a way to install all Core blocks (including new), akin to Monster Widget. For testing purposes, it'd be helpful to have an "install all" and perhaps update theme unit test ongoing to have the blocks available in posts.

[annezazu]

Thinking about the Data Liberation project and some of what I've personally seen when switching between page builders to Core blocks, I could see the work being done there helping influence what Core blocks are needed to fill the gaps so someone can switch without losing functionality. Ideally, we have a strong feedback loop as guides/tools are built and gaps are found. For example, I know I've heard a lot around carousel blocks and form blocks in particular.

[cleo3]

Speaking here as just a builder, please consider the remarkable plugin Find My Blocks. It is essential to real world site maintenance. It would be even more useful if it could find blocks in Patterns too.

As changes in block collections happen over time and as core blocks improve, sites need this plugin to do basic housekeeping. I'd prefer core, but this suggestion (which overall is great!) would be a good home for these features too.

[karmatosed]

I like this but want to keep mindful that the block stay blocks not patterns. We have patterns for good reasons and perhaps another part of this is even more maintained core patterns. We also as part of this might think what templates/defaults (templates is used in want of a better word), existing blocks might have. For example, the menu block should really have a mega menu or other types. How can that happen without yet another block? Blocks aren't also as easy to find as we often think for many users. How can surfacing things be done better? Just in time blocks are hard to get when many people think in patterns over blocks. I would suggest gently looking at ways to improve surfacing blocks is part of this along with patterns.

[pagelab]

Neat idea. Shameless plug on another option for a copyright block, which is a community plugin that's actively maintained – and growing.

[tomxygen]

I like the idea, and I think it should have a dedicated space at the bottom of the 'Blocks' tab in the block editor. This would ensure visibility even if the user hasn't typed anything in the search bar but is simply browsing the available blocks.

Also, another idea for Single Block Plugins is keeping them visually separated from the plugin list, in wp-admin/plugins.php
Intuitively, they're different from plugins (although technically they're not), and since the block editor has the goal of being accessible for beginners, I would make this distinction.

[nickhamze]

If you want any of my blocks you are more than welcome to them. I spent a ton of time and money on them and it makes me sad to think about the sad in their little repos --> https://github.com/sortabrilliant

[marcarmengou]

Some blocks of the directory could be grouped together to reduce the size of the directory.

Now, to create an ordered list, must select the list block and in the toolbar can select ordered list or unordered list.

• List
  • Unordened
  • Ordened

Perhaps we could group other blocks in the same way:

• Author:
  • Author
  • Author Name
  • Author Biography
• Quote
  • Quote
  • Pullquote
• Date
  • Date
  • Modified Date
• Comments
  • Comments
  • Comments Form

[creativecoder]

@vcanales and I are planning to take a look at what tooling would need to be added to support deploying individual block plugins from the Gutenberg repo. Some initial thoughts for an experiment:

• Add a new top level folder in the Gutenberg repo dedicated to standalone plugins
• Copy a block (that isn't part of the core block library yet) into the folder, adding the necessary plugin files (readme, PHP plugin header, etc). The time to read block might be a good one to start with, since I understand it's already functional.
• Set up CI/workflows for building and deploying the standalone plugin to the plugins directory
• Look into how to set up CI testing so it runs correctly when plugins files are changed (run only tests relevant to the plugin on plugin PRs, and don't run plugin tests on general Gutenberg PRs)

[jasmussen]

A suggestion: Playlist from #805. Tracking it here because the older issue has not seen movement, and the mockups are outdated.

[creativecoder]

I've opened an experimental draft PR here using the Time to Read block: #61504

Copying the block files and adding the necessary pieces to turn it into a stand-alone block plugin is straight-forward, though there are lots of little details to be mindful of, as when launching any plugin. It'd be nice if we could script this, basically have a version of @wordpress/create-block that has some additions specific to canonical block plugins, like adding the appropriate lint configuration files and plugin header values.

To streamline managing this and other plugins, there's a lot that could be done. Some initial ideas:

• Workflow for building plugin zip assets that can be downloaded for testing
• Update CI configuration so that plugin file changes don't run CI actions specific to Gutenberg file changes, and vice versa
• Setup unit/e2e tests that are specific to each block, and run independent of the Gutenberg test suites
• Automated check that a plugin is self-contained and works without the Gutenberg plugin activated (e2e tests might handle this)
• Automated check that block plugins pass Block Plugin Checker tests
• Verify PHP version support declared in the plugin header/readme
• A workflow that auto version bumps, updates the changelog, and triggers a dotorg plugin update, when appropriate
• Integrating npm install and build commands with lerna/monorepo configuration, so they don't need to be run separately
• Bump "Tested up to version:" on demand, like after new versions of WP are released and e2e tests for the plugin pass

---

Separately, there are process questions that come up, some mentioned in previous comments here, and deserve continued discussion

• How will we decide what blocks qualify as "canonical" and live in this repo?
• What will the process be for maintaining them, such as fixing bugs and adding new block.json features as they are available?
• Who will monitor support forums for these block plugins and provide support?

Overall, I'm quite excited about the possibility for more high quality blocks that are easy to install directly from the editor, as individual block plugins. I think a lot of the management burden can be mitigated with mindful scripting and automation, using tooling and infrastructure we've already developed for the Gutenberg plugin. But we still need to be intentional about selection, support, and maintenance--it would be disappointing to put in the effort to develop several canonical block plugins and then have them sit neglected.