Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal for Core Blocks in the Directory #58773

Open
mtias opened this issue Feb 7, 2024 · 53 comments
Open

Proposal for Core Blocks in the Directory #58773

mtias opened this issue Feb 7, 2024 · 53 comments
Labels
New Block Suggestion for a new block [Type] Discussion For issues that are high-level and not yet ready to implement.

Comments

@mtias
Copy link
Member

mtias commented Feb 7, 2024

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.

@mtias mtias added New Block Suggestion for a new block [Type] Discussion For issues that are high-level and not yet ready to implement. labels Feb 7, 2024
@colorful-tones
Copy link
Member

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
Copy link
Contributor

philwp commented Feb 7, 2024

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
Copy link
Contributor

Luehrsen commented Feb 7, 2024

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
Copy link
Member

ndiego commented Feb 7, 2024

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

@colorful-tones
Copy link
Member

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
Copy link
Member

ndiego commented Feb 7, 2024

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
Copy link
Member

colorful-tones commented Feb 7, 2024

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
Copy link
Contributor

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
Copy link
Member

aurooba commented Feb 7, 2024

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
Copy link

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
Copy link
Contributor

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

@bph
Copy link
Contributor

bph commented Feb 10, 2024

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
Copy link
Contributor

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:

@audrasjb
Copy link
Contributor

audrasjb commented Feb 11, 2024

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
Copy link
Contributor

carolinan commented Feb 12, 2024

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link

cleo3 commented Feb 14, 2024

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
Copy link
Member

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
Copy link
Contributor

pagelab commented Feb 23, 2024

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

@tomxygen
Copy link

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.
Add more 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
Copy link

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
Copy link

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
Copy link
Contributor

@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)

@afragen
Copy link
Member

afragen commented May 15, 2024

Honestly, if the idea is to move these blocks out of Gutenberg because they are not appropriate for inclusion in core, keeping in WordPress/gutenberg seems like a very confusing proposition.

What about just moving them to their own repository under WordPress.

@Zealth57
Copy link

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.

@youknowriad
Copy link
Contributor

youknowriad commented May 16, 2024

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.

@aaronjorbin
Copy link
Member

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:

  • What are the common requirements? How can we make sure quality is pervasive in all of the blocks that are shipped from WordPress?
  • What accessibility requirements must be met before a block can be released?
  • Are there requirements for a plugin to graduate to being shipped in Gutenberg the plugin or in core?

To go with my last question, I imagine stages that resemble something like the following:

  1. Experimental Block - Very low overhead to enter this stage. Blocks are not given any special treatment in the wordpress.org directory or in WordPress core.
  2. Canonical Block - This is when something is considered supported by core. Needs to meet certain guidelines. Given prominance in core and the block directory.
  3. Default in Gutenebrg - It's believed that this block is of high value to many users.
  4. Ships in core - There is evidence to suggest the majority of users will benefit from this block.

@creativecoder
Copy link
Contributor

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?

@afragen
Copy link
Member

afragen commented May 17, 2024

Instead of hiding the CI complexity in WordPress/gutenberg, wouldn't it be more instructive to others to have it demonstrated for the specific block in its own repository?

@talldan
Copy link
Contributor

talldan commented May 20, 2024

Instead of hiding the CI complexity in WordPress/gutenberg

@afragen What do you mean when you say 'hiding'?

@afragen
Copy link
Member

afragen commented May 20, 2024

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.

@talldan
Copy link
Contributor

talldan commented May 20, 2024

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.

@joemcgill
Copy link
Member

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.

@phanduynam
Copy link

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.

@priethor
Copy link
Contributor

Thanks for the healthy discussion, everybody.

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.

Indeed, after discussing with @creativecoder and @vcanales, we will publish a proposal to make/core for increased awareness.

@jeffpaul
Copy link
Member

jeffpaul commented Jun 4, 2024

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.

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

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.

@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."

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.

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

@talldan
Copy link
Contributor

talldan commented Jun 5, 2024

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.

@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:

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.

@joemcgill
Copy link
Member

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

@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 @wordpress/env package comes to mind as an example of this. I would assume that any blocks developed in this repo that are not fit for WP Core would not get synced to Core's SVN repo either.

@jeffpaul
Copy link
Member

I would assume that any blocks developed in this repo that are not fit for WP Core would not get synced to Core's SVN repo either.

@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?

@joemcgill
Copy link
Member

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

@mtias
Copy link
Member Author

mtias commented Jun 26, 2024

@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 core/ namespace, deciding later on to bundle one of these in the default installation shouldn't be much of a problem.

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

@creativecoder
Copy link
Contributor

Indeed, after discussing with @creativecoder and @vcanales, we will publish a proposal to make/core for increased awareness.

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.

@colorful-tones
Copy link
Member

So we're planning to build some of these new blocks first.

@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?

@tomxygen
Copy link

tomxygen commented Jul 9, 2024

That way we can we can consider how best to distribute each block (default block library or canonical block plugin)

@colorful-tones @creativecoder
A while ago I built a mockup of how additional blocks could be shown in the site/block editor.
307508885-b0e784ef-187b-4497-b03c-9d0f49473a91
Is it something that is going i this direction?

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.

@creativecoder
Copy link
Contributor

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

@dmsnell
Copy link
Member

dmsnell commented Jul 9, 2024

@creativecoder please add a Math Typesetting block to the list.

#58912

@carolinan
Copy link
Contributor

Can we add the back to top link to the list? #50433

@carolinan
Copy link
Contributor

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.

@creativecoder
Copy link
Contributor

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 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
New Block Suggestion for a new block [Type] Discussion For issues that are high-level and not yet ready to implement.
Projects
None yet
Development

No branches or pull requests