Matias Ventura, Gutenberg’s Lead Architect, recently made a pitch to incorporate some single-block plugins in the Gutenberg GitHub repository:
“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. 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.”
These plugins won’t just be guests—they’ll become roommates, proudly featured in the Blocks Directory: “designed, developed, published, and maintained by core contributors in this repository” but available to install as standalone blocks in the directory.
The tension between users’ demand to bundle more functionalities and the maintainers’ inclination toward keeping core as lean as possible won’t be resolved anytime soon. Yet this presents an interesting compromise: if the estimations are accurate, and most websites are built with a combo of Group blocks holding Heading, Paragraph, Image, List, and Button blocks, then having this living arrangement will benefit both segments of the community.
The History of the Block Directory
The Block Directory features a subset of single-purpose plugins that users can install right in the editor without leaving the page you’re working on.
Included in the Block Editor since WordPress 5.5, it has been the topic of several public debates since Matt Mullenweg prioritized it as an upcoming focus area in 2018.
As reported on WP Tavern, the original proposal was to host small, JavaScript-based blocks that users could easily install via searchable in-editor UI. The critical responses to the technical limitations, the divergence from the native UX, and the potential performance toll it would entail didn’t prevent the final implementation from being almost identical to the initial version (although a few early design prototypes did address the UX issue).
The Evolution of Gutenberg
No matter where they’re hosted, Blocks are plugins. And plugin developers are the jelly in WordPress’ sandwich.
Treating these smaller-scoped blocks as standard plugins that must adhere to the platform’s Plugin guidelines regarding monetization, along with the introduction of a set of technical restrictions—no Dynamic Blocks, no block extensions, preferably no block collections, and no style Variations—has left many frustrated.
The same technical and business-related concerns raised during the discussions on the initial proposal remain unresolved in this latest proposal. Still, it does offer a modest promise to share the burden of maintenance and updates and the benefits of the Authored by WordPress.org stamp of approval.
This time, though, the questions aren’t so much the technical functionality, the UI, or the business aspects; Ventura’s exploratory proposal is an administrative reform, hinting at the evolution of Gutenberg: no longer an experimental add-on that ships an ever-expanding array of specialized blocks but a maturate platform that focuses on fundamental core blocks, treating the former as cherished friends who are welcome to stay over.
Examples mentioned in the proposal
Update: the term “3rd-party” was removed to avoid confusion with non-core plugin developers. (Ronny Shani, 27.02.2024)
The problem is that so many blocks come in bundles. You have to install a bundle and a lot of blocks you don’t need in order to get the one you are looking for (if you find it at all). There are already so many block bundles in the plugin directory that it woul take hours of time to check out if they contain blocks you are looking for.