Proposal for Core Blocks in the Directory #58773
Comments
mtias
added
New Block
❤️
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. |
|
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.
This sounds like themes and patterns would be able to list these blocks as dependencies, strongly support this. |
|
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. |
|
Love this idea. I know of a little icon block that might be a good candidate for this 😉 |
|
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. |
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. 🤷 |
|
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. |
|
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) |
|
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:
|
|
Would these blocks be given preference in the block directory search results? |
|
Here is the list of blocks, people I talk to find often missing.
Yes, should they should bubble up as suggestion with preference |
|
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:
|
|
Thanks for the proposal! And thanks for the mention @carstingaxion! |
|
How would WordPress ensure that all single block plugins are kept up to date and at the very least receives security updates? 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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
Neat idea. Shameless plug on another option for a copyright block, which is a community plugin that's actively maintained – and growing. |
|
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 |
|
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 |
|
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.
Perhaps we could group other blocks in the same way:
|
|
@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:
|
|
Honestly, if the idea is to move these blocks out of Gutenberg because they are not appropriate for inclusion in core, keeping in What about just moving them to their own repository under |
|
I don't quite see the value in this proposal as there's already a concept of doing this. If core contributors think there's something of value but doesn't follow the 80/20 rule you can submit a plugin to the repository https://wordpress.org/plugins/two-factor/ and it can even be endorsed with it's own repo under WordPress as @afragen suggested https://github.com/WordPress/two-factor. We already have too many blocks that bloat the code base shipped by default. I don't suppose there will be any tighter integration into canonical plugin installs like the performance install, so unsure why we'd try to more tightly integrate block installations. If users want blocks create a plugin, submit to the plugin repo, and they can easily be installed from there. It's done all day every day with what we have in place. |
|
Shipping something and building something are very different things. The discussion about MonoRepos VS MultipleRepos has less to do with whether these things are published in different places and more todo with whether these things evolve together or not. We'll be reusing and evolving these blocks as we evolve the APIs and the other core blocks, the tools we use to build them, so we should be building them in the same repository. Putting the logic of separate repositories to the extreme, means each package of the Gutenberg repository should be its own repository, each tool, each block... There's obviously value there but I think at this point there's enough literature in the wild that explains that mono-repos are a better tradeoff. Eventually, some part of the mono repo can grow enough to warrant its own repo but as we start experimenting with these things, there's no need to reinvent all the infrastructure we have in place. |
|
I love this idea. To add to @creativecoder's questions, some I think would be good to answer before this comes out of the experimentation phase:
To go with my last question, I imagine stages that resemble something like the following:
|
|
I think I see some confusion about what's being proposed, which I'll try to clear up. How will these blocks be shipped? They will be shipped as independent single block plugins, separate from Gutenberg. This has a couple of advantages. Users who want to install these blocks won't need to install the entire Gutenberg plugin and all that comes with it. Also, single block plugins show up directly in the editor when searching from the inserter, and can be installed, activated, and inserted in one step, which makes theme easy to find and use. Why not put these blocks in a separate repo, rather than in the Gutenberg repo? I initially had the same thought about using a separate repo. But I've changed my mind after investigating it. Adding to @youknowriad 's answer above, the Gutenberg repo has a mature CI configuration, with various kinds of linting and multiple levels of automated tests. Maintaining this is not trivial and by keeping block plugin code in this repo, we can benefit from this without having to maintain it in a separate place. This should allow us to enforce the same coding standards, test requirements, etc we have in the Gutenberg plugin. For example, I think each block should have a e2e test suite to make sure it works from editor to render, and we can do that with less effort by using the existing infrastructure here rather than building a new one in a separate repo. Why not let the community fill this need; why have core contributors build and maintain these block plugins? I think there's room for both! There are a number of open issues for new blocks, and it seems clear that not all of them are a good fit for the default block library. And we've already seen contributors working on some of these (like the Time to Read block), so why not ship them to users? |
|
Instead of hiding the CI complexity in |
@afragen What do you mean when you say 'hiding'? |
|
I mean using the CI complexity as an excuse not to put these canonical block plugins in a repository of their own. By hiding them inside a single monolithic repository. Surely the relevant portions of the CI process can be duplicated into other repositories. |
|
Ah, I see. I don't really agree that it's 'hiding' or 'an excuse', I think you're trying to be deliberately provocative with your language and it's completely unnecessary. From my point of view (as a contributor to this project), using the monorepo is a valid way to keep the blocks up-to-date and error free. It also increases the test coverage across the codebase. So it is about CI, but more about maintenance. For example, if someone changes a core API in a way that's not backwards compatible, but the error only happens in one of these new blocks, the issue would be caught straight away by the CI in the monorepo. If it's a separate repo, it'll probably only be caught sometime later when the tests run for an unrelated change. A dev would also have to keep the APIs that those blocks use up-to-date. The likelihood is that eventually that other repo starts to fall behind as contributors forget about it. We already see this fracturing to some degree with the need to keep Gutenberg/WordPress core in sync, and there are often things that people forget to do. So I personally don't think it's good to increase the separation, but to keep things together more. |
|
I think having a set of specialized blocks that aren't fit for the default set but still demonstrate best practices is a great idea and fits very well into the idea of Canonical Plugins that we've discussed many times as a community. I particularly like that this provides a way for us to experiment with blocks without the implicit expectation that they have to ship in a WordPress release. I do think some thought should be put into the lifecycle of one of these blocks, not only to define what the criteria should be for a new one to be included, and how they'll be maintained, but also what does it look like for a block to become "retired" once a block is no longer being maintained for any number of reasons. Personally, I don't have strong opinions about whether the development should happen in this repo or in a separate repo, similar to the way https://github.com/WordPress/community-themes functions. If there are advantages to using the mono-repo from a tooling and visibility point of view, then I don't see a problem with it. As a matter of process, I understand that this issue was likely created as a low-friction way to get feedback on the idea, but now that it's being actively worked on, it would be best to have an official proposal for this project posted on the most relevant make.wordpress.org team site, like make/core. |
|
WordPress version 6.5.3 does not have a table of contents block, I recommend adding a Table of Contents block to WordPress 6.6 to quickly create a table of contents based on all the headings on a page. From then on I won’t need to install the Table of Contents Plugin anymore. |
|
Thanks for the healthy discussion, everybody.
Indeed, after discussing with @creativecoder and @vcanales, we will publish a proposal to make/core for increased awareness. |
@mtias This seems to argue in both directions for a block being part of core and not part of core at the same time... either a block is deemed as a valuable one in core or is not. And if a block is not deemed to be valuable enough in core but there's still an audience for it, then that's where the existing Block Plugins seems to exist as the best place for said block to be available. So I'm not quite sure I understand the "why" behind this Proposal and what the central problem here is, so some additional clarity into that would be helpful.
@talldan I inferred differently from @afragen's comment and in reading it what came to mind for me was more like ~"if there are CI things within the Gutenberg repo that would benefit other block plugins, perhaps that CI check could be spun off as its own GitHub Action that then Gutenberg and block plugins in separate repos (managed by whomever, not just core contributors) could benefit from together."
@joemcgill one noticeable difference between Canonical Plugins and this proposal is that Canonical Plugins don't exist within Core's SVN repo and instead are sourced elsewhere. The Canonical notation is primarily one to denote that they are "the official first-choice recommendation by core and w.org for an area, that share in the ethos and approach of WordPress itself but to a more niche area that might not be right for core." Following from that logic, and using @ndiego's The Icon Block as an example, perhaps there are block plugins that could be tagged as Canonical (instead of Community) and updated as such to ensure support for them is provided by the broader core contributor community. |
@jeffpaul One of the main the purposes of the monorepo is to build reusable packages that can be shared across projects. Lots of the tooling for CI is already shared. I really don't understand the criticism of 'hiding' and 'excuses'. It feels like very pointed criticism, but I'm still misunderstanding the core of what it's about. Anyway, my point still stands, it's less about the CI setup, which is largely a one time effort, but more about the ongoing maintenance and the benefit of code coverage in this repo, which as Riad mentioned above:
|
@jeffpaul: I appreciate the caution, but I don't think it's fair or wise to conflate this repo with Core's SVN repo. While much of the work in this repo does end up being synced to the SVN repo, not all of it does, nor needs to. The |
@joemcgill is your thinking/assumption here that those blocks are ones that are expected to be on a path to get synced to Core or that they'd ONLY ever exist separately? |
|
@jeffpaul I don't have any assumptions about whether they would eventually be included in Core, just that they were determined not to be fit for Core for some reason. If any block developed by this team eventually got onto a path to get synced, having them already in this repo would make that transition much smoother. Likewise, if we needed to deprecate a core block in the future, being able to move it to a canonical blocks plugin while keeping the code in the same repo could be a nice benefit. |
|
@carolinan part of the reason to keep them in the same repository as core blocks is precisely to ensure maintenance, rapid adoption of features, and the same standards of quality. If we use the @jeffpaul I see it as a pragmatic balance to unblock (no pun intended!) the creation of blocks that have had enough user demand that it would help the ecosystem to have official first-choice recommendations, for which users can expect the same level of accessibility and care that core blocks should have. There are valid reasons to then choose not to include them in default installations, from bundle size to 80/20 to things we may not want to necessarily encourage by default but recognize they can be used judiciously and it's better to offer a well thought out solution than nothing at all. These shouldn't be a reason for launching poorly thought out blocks or taking shortcuts. I think it's crucial they are developed as if they were going to be part of core, we are just choosing to release them separately through the block directory. |
An update about where @priethor , @vcanales , and I are with this effort: While continuing to explore the idea of canonical block plugins and drafting a proposal, we've realized that the underlying problem we're trying to solve is providing high quality and official/endorsed versions of blocks that are frequently missed by theme builders and users, like those mentioned in the discussion above: tabs, slider/carousel, icons, accordion, etc. In looking through past issues and PRs for new blocks added to the default block library, I see that each block is considered individually based on perceived need, functionality, quality, and accessibility. So we're planning to build some of these new blocks first. That way we can we can consider how best to distribute each block (default block library or canonical block plugin), rather than starting with developing a new process in the abstract. Initially our plan is to put these blocks behind an opt-in feature flag to allow quickly iterating and experimenting (in the same way the form/input blocks are currently behind a flag on the Gutenberg > Experiments page in wp-admin). If and when we return to canonical block plugins as a distribution mechanism, #61504 is in a good state to serve as a reference for how to incorporate additional plugins into the Gutenberg repo. |
@creativecoder @vcanales @priethor - Do you mind providing insight on how you'll determine what new blocks to build first and where the community might look to receive updates or even contribute directly to these new blocks? |
@colorful-tones @creativecoder Also, another idea for Single Block Plugins is keeping them visually separated from the plugin list, in wp-admin/plugins.php |
|
@colorful-tones Here's a list of issues I've collected, based on the suggestions in the comments here and searching for open issues and previous PRs. The best way to follow along right now is to follow these issues 😄. (Note that I don't know how many we'll get to, or in exactly what order.)
Also, potentially we'll take another pass at improving these: I'm planning to start with the Tabs block, since it has recent design work, doesn't look too complex, and seems like a good use case for using the interactivity API in a block. @tomxygen Thanks for looking to improve the block plugin experience! I think these efforts are best tracked in separate issues, as this issue is primarily about workflow and infrastructure for distributing block plugins, rather than the user experience of installing them. |
|
@creativecoder please add a Math Typesetting block to the list. |
|
Can we add the back to top link to the list? #50433 |
|
There is no open issue for it, but users seems to be interested in a style variation toggle for the front aka "dark mode" toggle block. This was mentioned multiple times in the post for Twenty Twenty-Five. |
|
In the interest of keeping this issue about block distribution and development processes (such as canonical block plugins), I've created a separate tracking issue for new blocks. To scope the effort, it's focused on blocks that help expand theme and pattern designs: #63501 Please continue with any block specific discussion over in that issue 🙏 |
and others
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.
The text was updated successfully, but these errors were encountered: