Gutenberg 24.3.0 RC1 went up on GitHub on 20 October 2026, six days after 24.2 went stable. I read the whole RC1 changelog, and I also read the pull request behind its one headline feature, because that feature has a long history. Letting you press bold, italic or link on a selection that runs across several blocks was first opened as a pull request on 11 February 2024. The pull request page shows it merged into trunk on 13 October 2026.
My hand count of the Enhancements section is 45 Block Library entries, 36 Components entries and 13 Post Editor entries, plus one entry under Features. Most Block Library entries give an existing core block a design control it did not have before, which continues what I wrote about in the Gutenberg 24.2 notes. The count is mine, made by reading the release page, so treat the numbers as approximate and the entry names as the exact part.
One warning before the detail. This is a release candidate and I have not installed it. Everything below comes from the GitHub release page, the pull request and the WordPress.org and Make WordPress pages I link to, not from hands-on testing. Where I could not confirm something, I say so.
What Gutenberg 24.3 RC1 Actually Contains
The release page is marked Pre-release. When I captured it, the page said three commits had landed on the release/24.3 branch since the tag was cut. That is a small gap, but it is the reason I will not call anything here final.
The Features group has exactly one entry, and it is the cross-block formatting change. The Enhancements group then splits into general items, the Block Library, Components, the Post Editor, Extensibility, the Data Layer, Media, Patterns, the Font Library and Global Styles. The Block Library list is the longest, and none of its 45 entries adds a new block. Every one of them changes an existing block or the icon library.
Cross-Block Rich Text Formatting: What The Pull Request Says
The pull request description is unusually clear about what the feature does and does not do, so I will quote its logic in my own words rather than guess. The aim is that the format buttons in the block toolbar, and their keyboard shortcuts, work on a text selection that starts in one block and ends in another. That covers bold, italic, link and every other registered format.
The rules the description sets out are the part worth knowing:
- Only plain text blocks take part. Every selected block must be nothing but one rich text field, with no inner blocks. A quote, a button or a list item that holds a nested list gets no format buttons, because a format would reach only part of what looks selected.
- Active state follows the usual rule. A format counts as active when every selected character has it, and toggling applies or removes it for the whole selection.
- A link becomes one anchor per block. The description compares it to one link per line inside a single block.
- A format that replaces text can merge blocks. The example given is an inline image: the selected text is replaced and the selected blocks become one, the same as typing over a selection.
- Allowed formats are respected. The toolbar offers only the formats that every selected field allows.
- The selection is kept. Rendering new values moves the browser selection, so the code puts it back after each update. The description says Firefox records the moved selection in the store, while Chromium and Safari keep the store but show the moved highlight.
The pull request has no screenshots or screencast. Its Screenshots section says None. That is why I show the pull request page above and not the feature itself, and why I would not trust any article that shows a polished screenshot of this before you can install the stable build.
How I Would Test It On A Staging Site
The description includes testing steps, and they are a good checklist for a staging copy. I have not run them, so this is the author’s procedure, not my result:
- Type two paragraphs and select from the middle of the first into the middle of the second, with Shift plus the arrow keys or Shift plus click.
- Press Ctrl or Cmd plus B, or use the Bold button. Both parts should be bold and the selection should stay. Press it again to remove the bold.
- Press Ctrl or Cmd plus K and enter a URL. Each block should get its own link.
- Insert an inline image from the More menu. The selected text should be replaced and the blocks should become one.
- Select from a paragraph into a quote or a button. The toolbar should show no format buttons.
If step five behaves differently on your theme, that is worth reporting upstream before stable lands.
The Block Support Wave Continues
Design controls are still the bulk of the release. Reading the Block Library list, I count these patterns:
- Minimum width and height: 10 entries. Icon, List, Navigation Overlay Close, Paragraph, Playlist, Post Navigation Link, Post Template, Search and Video get both, and Cover gets minimum width.
- Background image, size and gradient: 5 entries. Icon, Paragraph, Playlist, Post Navigation Link and Tab List.
- Background gradient on its own: Accordion Heading, Search and Table.
- Shadow: Icon and Search.
- Colour and typography: link colour on Table, link and button colour on Cover, heading and button colour on Term Template, and typography on File. Tab List gains line height, font weight, letter spacing and text transform.
- Writing mode: Pullquote gets writing mode and text indent, and Quote gets writing mode.
- Fit text: Post Title gets fit text support.
Taken one at a time these are small. Taken together they continue a direction I described in the Gutenberg 24.1 post and again for 24.2: core blocks are getting the controls that used to be a reason to install a block plugin. A background image on a Paragraph block is a good example. A year ago that needed a Group wrapper or a plugin.
I would not read the list as a feature count to compare against a plugin. The useful question is narrower: which three blocks do you use most, and do they now have the controls you were paying for? I made the same argument in the post on whether you still need a blocks plugin, and it still holds.
Style States And Custom CSS
Five entries in RC1 touch how styles are scoped, and I want to be careful here because I only have their titles. The Block Library enhancement reads “Enable style state-specific custom CSS”. The Post Editor group adds a footer that shows the viewport and responsive styles status for style states, and Global Styles gets a preview of the selected state on element screens. Two bug fixes also concern custom CSS: one makes block style variations use the correct selector on the front end, and one generates custom CSS for blocks that are rendered by their parent block.
My reading is that this is the second half of the responsive and hover styling work that arrived in WordPress 7.1. I explained that feature in the guide to responsive block styles. I cannot tell you from the changelog how state-specific custom CSS looks in the interface or what it can target, and I will not invent it. If you write custom CSS for hover or focus states today, this is the entry to test first.
Notes, Patterns And Editor Housekeeping
The Post Editor group is mostly about Notes, the comment feature that WordPress 7.1 expanded with mentions and inline feedback, according to the 7.1 release post. RC1 adds five emoji reactions to notes, makes the Add note toolbar button add-only, marks the text an unsent note is about with a draft marker, and removes the divider between the canvas and floating notes.
Patterns get two changes I find practical. Users can now detach synced patterns they are not allowed to edit, and the inserter lists synced patterns a user can read but not edit. The inserter tab called My patterns is renamed Site patterns and gains an author filter. If you train clients or editors, update your screenshots and instructions once 24.3 is stable.
Smaller items worth a glance: a copy option and a show or hide details button for save failures, a stabilised DataForm-based inspector, and elements listed alongside blocks in Global Styles. The Font Library marks installed font variants in collections.
Performance, Accessibility And React 19
Two performance entries are the ones I would watch on a large site. One caches the theme.json data that is merged from all origins, and the other speeds up rendering of the icon library in the Icon block. The Interactivity API gets a faster toVdom walk, and the Connectors screen preloads its REST API responses. I have no benchmark for any of these, so I cannot say how much they save.
On accessibility, the Cover and Video blocks no longer autoplay a background or front-end video when the visitor prefers reduced motion. That is a front-end behaviour change, so check any hero section that depends on an autoplaying video.
RC1 also adds more plugins to the React 19 incompatible list. React 19 became the default in 24.2, and I wrote about what can break and how to switch it off. If you run plugins that load their own React code in the editor, read that post before you test RC1.
Is 24.3 Stable Yet, And Which WordPress Gets It?
No. The plugin directory page still lists 24.2.0 as the current version, so 24.3 is a release candidate only. Make WordPress publishes a What is new in Gutenberg post after each stable release, and the 24.2 post is dated 14 October. I expect the same for 24.3, but I do not know the date.
The same agenda says WordPress 7.2 Beta 1 was released on 20 October 2026 and Beta 2 is scheduled for 27 October. I could not find a statement of which Gutenberg version 7.2 will bundle, so I am not promising any 24.3 control for 7.2. My WordPress 7.2 roadmap post tracks what is confirmed.
The safe reading for production sites: Gutenberg plugin features reach WordPress core only when a core release bundles a newer Gutenberg. Until then, nothing in this post changes a site that runs core alone.
What I Would Not Assume About Block Plugins
Because the Block Library list adds controls and no new blocks, the gap between core and a block plugin is still about blocks that core does not have. Nexter Blocks is our plugin, so weigh this accordingly, but the example is checkable: a flip box that turns over on hover is not in the RC1 list.
Nexter Blocks lists 120+ blocks on its product page. Which are free and which are Pro is on the free versus Pro page, and I would trust that page over my memory. If you already use Nexter Blocks, the new core controls are a reason to compare, not to stop. The companion piece on Button styling in Nexter Blocks shows how I do that comparison for one block.
I did not check any other block plugin’s changelog for this post, so I make no claim about what Spectra, Kadence Blocks or Stackable do today. Their changelogs change every few weeks, and a comparison needs the vendor page on the day you read it.
What I Would Do Before 24.3 Ships
- Site owners on a block theme: do nothing yet. There is no reason to install a release candidate on a live site, and core will not have these controls until a release bundles them. The Nexter Theme page explains how a block theme fits with the editor.
- Agencies and freelancers: test RC1 on a staging copy of a client site and run the five formatting steps above. Pay attention to hero sections with autoplay video and to any custom CSS that targets hover or focus states.
- Plugin and theme developers: read the Components list, which has 36 entries including many Emotion to SCSS Modules migrations, and the React 19 list. Those are the entries most likely to need a code change.
- People who pay for a block plugin: write down the three blocks you use most and check whether each now has the control you need in core. That list is more useful than any count, mine included.
If you want the background on how the editor got here, What Is Gutenberg is the plain starting point.
What This Doesn’t Cover
- I did not install or test 24.3 RC1. Every statement about behaviour comes from the changelog and the pull request description.
- I did not see the cross-block formatting feature running, and the pull request has no screenshots, so I cannot describe how it looks or feels.
- I only have titles for the style state and custom CSS entries, so I cannot say what they can target.
- I counted entries by hand from the release page. Entries may move between sections before stable.
- I do not know which Gutenberg version WordPress 7.2 will bundle, and I have not guessed.
- I did not compare Nexter Blocks feature by feature with other block plugins. That needs each vendor changelog on the day you read it.
- I did not benchmark any performance entry.
Suggested Reading
- Gutenberg 24.2: What’s New For Block Styling And The Interactivity API
- Gutenberg 24.1: Design Tools Now Reach Almost Every Core Block
- Gutenberg 24.2 Turns On React 19 By Default
- How To Use Responsive Block Styles In WordPress 7.1
- WordPress 7.2: Release Date, Ipsum Theme And Every Feature On The Roadmap
To try the blocks mentioned above, start with Nexter Blocks.
