WordPress Gutenberg: the plugin that ships the block editor ahead of core

What the Gutenberg plugin actually ships

The block editor became part of WordPress in December 2018. The Gutenberg plugin is the separate distribution channel for that editor: it gives a site the latest version of the block editor before those changes land in a core release. The README states the intent plainly, describing the plugin as a way to test bleeding-edge features and to start playing with blocks.

The editing model is the part that matters. Every piece of content is a block, from a paragraph to an image gallery to a headline, and blocks can be added, arranged and rearranged. The README contrasts this with shortcodes and custom HTML, the workarounds the block model replaces. That is the specific problem: content that used to be opaque text with embedded markup becomes structured data the editor can render and manipulate.

Who it is for splits cleanly. Site owners install it to preview editor behaviour. Developers install it to build and test blocks against APIs that may not be in core yet. The repository is also the development hub itself, so contributors work from the same tree.

How the block editor is distributed and extended

Two things live in this repository and they are worth separating. One is the plugin that ships to wordpress.org. The other is a monorepo: package.json declares the private package gutenberg at version 24.0.0, and the top-level packages/ directory holds the individual JavaScript packages that make up the editor. The repository is maintained with lerna, per the badge in the README.

That layout explains the release numbering. The recent releases list shows v24.0.0 on 2026-09-16, preceded by v24.0.0-rc.1 on 2026-09-10 and v23.9.1 on 2026-09-07. A release candidate followed by a stable release a week later, with a patch release of the previous line in between, is a cadence built around continuous integration rather than long stabilization windows. The README links badges for end-to-end tests, static analysis, unit tests and a Create Block workflow, so the repository runs those suites on trunk.

Extension happens through plugins. The README points developers at the Quick Start Guide and the Block Editor Handbook for tutorials and API references, and the repository carries a docs/ directory alongside schemas/ and tools/. The package.json also declares a wpPlugin block listing admin pages such as font-library, options-connectors, experiments and site-editor-v2, several of them marked experimental. Those pages are part of the plugin build, not separate downloads.

Installing Gutenberg and trying the block editor

The README gives two routes. The shortest is the plugins page in wp-admin: search for Gutenberg, install, activate. The alternative is the WordPress.org plugins repository, where the plugin is published. There is also a live demo at the project homepage if you want to try the editor without touching a site.

If you work from the repository instead, the tooling is pinned. package.json declares engines for node >=24.18.0 and npm >=11.16.0, and the repository includes an .nvmrc file, so the expected Node version is recorded in the tree. A typical bootstrap from a clone looks like this:

nvm use
npm install

The first command reads .nvmrc and selects the Node version the repository expects. The second installs the workspace dependencies declared across packages/. If your Node version is below the engines range, npm will warn rather than silently proceed.

For a disposable WordPress environment, the repository ships a .wp-env.json file, which is the configuration @wordpress/env reads. The README does not document a start command, so check the contributor documentation under docs/ before running one; the config file is the source of truth for the environment it builds.

Once the plugin is active, the first real use is the editor itself. Create or edit a post and the block editor opens in place of the classic editing screen. Add a paragraph block, then an image block, and rearrange them; the README's description of blocks as addable and rearrangeable is directly observable here. If you are building rather than editing, the README points to the Quick Start Guide for the fastest path to extending the editor.

Where Gutenberg is the wrong tool

The plugin is a preview channel, and that is the limitation. Features can appear, change shape or disappear between releases, because the plugin exists to test what is not yet settled. On a production site where editorial workflows are frozen, that instability is a cost with no matching benefit. WordPress core already contains the block editor; the plugin is only worth it if you specifically want what core does not have yet.

The README is also explicit that the project is in the second phase of a four-phase process. Editing and customization are the current focus; collaboration, multilingual work and later phases are described as groundwork. Anyone adopting the plugin expecting the full four-phase vision to be present is reading ahead of the implementation.

Support routing is another boundary. The README directs users with problems to the Support Forums first, and bugs to the GitHub issue tracker, asking that you search before filing to avoid duplicates. A site owner who wants vendor-style support will not find it here; the support path is community forums and a public tracker.

Finally, the licence field in the repository metadata is NOASSERTION, while package.json states GPL-2.0-or-later and the README points to LICENSE.md for the full text of the GNU General Public License version 2 or later. The metadata and the package manifest disagree, so read LICENSE.md rather than trusting a single field.

How Gutenberg differs from Elementor and page-builder plugins

The closest alternative is a third-party page builder such as Elementor, and the difference is architectural rather than cosmetic. Elementor stores its layouts in its own data structures and renders them through its own front end. Gutenberg stores content as blocks in the WordPress post content, and the editor that manipulates them is the one WordPress core ships. That is why the README can describe the block editor as replacing shortcodes and custom HTML: the content stays in a form WordPress itself understands.

The practical consequence is portability. A site built on the block editor keeps its content readable by core WordPress even if the Gutenberg plugin is deactivated, because the plugin is a preview of core behaviour rather than a separate rendering layer. A site built on a page builder depends on that builder to render. The trade-off runs the other way too: page builders typically offer a more settled set of layout controls, while Gutenberg is the moving target described above.

There is a middle case worth naming. The search data includes people asking how to use Gutenberg blocks inside Elementor, which suggests the two are not always an either-or choice. The repository does not document Elementor integration, so treat that as a question for Elementor's own documentation.

Release cadence, version pinning and what upgrades cost

The plugin is not a set-and-forget dependency. The release history shows v24.0.0 on 2026-09-16, a release candidate on 2026-09-10, and v23.9.1 on 2026-09-07. Releases arrive close together, and the last push to the repository was on 2026-09-21, so trunk moves continuously between them.

For a site owner, the upgrade cost is testing. Each release can change editor behaviour, and the README frames the plugin as the place where you test bleeding-edge features. Budget for re-checking your blocks and templates after an update rather than assuming the editor looks the same.

For a developer, the cost is toolchain churn. The engines field requires node >=24.18.0 and npm >=11.16.0, and package-lock.json pins the tree; running npm install against a different Node line is the usual source of build failures. The repository also carries syncpack.config.mjs and lerna.json, so internal package versions are coordinated rather than independent.

On licensing, the README states the project is released under the GNU General Public License version 2 or, at your option, any later version, and points to LICENSE.md. If you redistribute the plugin or build on its packages, read that file and the GPL terms yourself; this is not legal advice.

Editorial conclusion

Adopt Gutenberg on a staging or test site if you want to see block editor features before they reach a core release, or if you are developing blocks and need the current APIs. Do not install it on a production site that only needs the editor WordPress already ships, because the plugin tracks a fast release cadence and the README positions it for testing bleeding-edge features. Before adopting it anywhere, check the version in readme.txt against your WordPress and PHP versions, and confirm your theme and plugins do not already register overlapping block editor functionality.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. WordPress/gutenberg on GitHub