![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Changes between Initial Version and Version 1 of Ticket #53412, comment 4
- Timestamp:
- 06/15/2021 09:32:12 PM (5 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #53412, comment 4
initial v1 1 As @ryelle mentions the core of this idea is already in place for blocks that are available in the block directory. The main inconvenient, though, is that most block libraries come in the form of plugin bundles and their blocks are not available standalone. A next step is to figure out a way to make it easy for plugins to make their blocks available in the directory as single blocks while still allowing collections of blocks to exist in some form (a plugin could just indicate what blocks from the directory are part of the bundle using the block namespace, for example). All in all it has to be easy for existing libraries to publish their blocks in the directory without disruption or overhead. Some of that work is described in https://github.com/WordPress/gutenberg/issues/233781 Indeed! As @ryelle mentions the core of this idea is already in place for blocks that are available in the block directory. The main inconvenient, though, is that most block libraries come in the form of plugin bundles and their blocks are not available standalone. A next step is to figure out a way to make it easy for plugins to make their blocks available in the directory as single blocks while still allowing collections of blocks to exist in some form (a plugin could just indicate what blocks from the directory are part of the bundle using the block namespace, for example). All in all it has to be easy for existing libraries to publish their blocks in the directory without disruption or overhead. Some of that work is described in https://github.com/WordPress/gutenberg/issues/23378
