Gutenberg 24.2 moves notes beside the editor and changes React testing

Gutenberg 24.2 was released on October 14 with changes that affect both the writing desk and the code behind it. Notes now sit beside the editing canvas, navigation search covers more content types, and the plugin enables its React 19 experiment by default, with exceptions for known compatibility problems.

This is a Gutenberg plugin release. It should not be described as a new WordPress core version or as a change already present on every WordPress website. Check what your installation actually runs before scheduling an update or telling editors that their interface has changed.

Less switching while editing

The official release announcement says notes can remain visible while the Settings sidebar is open. Navigation link search also brings pages, posts, categories and tags into one search flow.

For a publisher, those are concrete tasks to try. Open a draft with an editor’s note, change a block setting and confirm that the thread remains usable at the screen widths your team works with. Then add a category link to a test menu and check its destination in the preview.

These checks matter more than counting new controls. A faster editing interaction is useful only if the publication can still save the intended content, preserve its links and produce the expected page.

Keep changes to a test menu out of the live navigation until somebody has checked the result. A menu mistake can spread across an entire site even when the underlying article is correct.

React 19 changes the compatibility question

The announcement says Gutenberg 24.2 enables React 19 unless a theme or plugin on its known-incompatibility list requires React 18. It also identifies an option to turn the experiment off under Gutenberg’s Experiments settings if a problem occurs.

That is a reason to test custom blocks and editor extensions, not evidence that they will fail. Ask the person maintaining the site to check a representative draft: add a block, edit it, save, reopen and preview. Include any bespoke sidebar or integration used in the publishing process.

If something breaks, record the Gutenberg version, active theme, relevant extension and steps that reproduce the problem. Avoid changing several plugins at once while diagnosing it. A repeatable fault is easier to report and fix than a vague observation that the editor feels different.

Make the update a controlled release

Use the WordPress update guidance to prepare a recoverable change. Keep a backup and a clear return path, then test the public output as well as the editing screen. The maintenance routine sets out how to keep those checks small enough to repeat.

There is no need to install Gutenberg on a production site solely to obtain an item from this announcement. First decide whether the release solves an actual workflow need, whether the site already uses the plugin and who will own compatibility checks.

If the update coincides with a hosting move, separate the changes where practical. A hosting migration checklist helps keep infrastructure changes from becoming another unknown in an editor problem.