Gutenberg 23.8 Adds Shareable Revision URLs and Code Diffs

🇹🇷 Türkçe: Bu yazının Türkçesini oku →

The single most-asked question I have fielded in twenty years of WordPress work is some variant of “who changed this, and can I see exactly what they changed?” It sits under the editorial audit trail on a newsroom site, under the “why did the hero copy shift on Monday” panic on a WooCommerce homepage, and under the change-control questions every enterprise client eventually asks. Revisions are one of the quiet reasons WordPress keeps winning against tools that look shinier on demo day.

For most of the block editor’s life, that primitive has been present but awkward. You had visual revisions, then a code screen, then a separate URL for each, and if you wanted to show a colleague “look at this specific edit” you were reduced to a screenshot and a Slack message. That is fixable UX, not a fundamental problem, and Gutenberg 23.8 finally fixes it.

What lands in 23.8 is not a headline feature — it is the kind of release where three or four small things together change how a team actually collaborates. That is usually the more valuable kind.

What is actually new

Gutenberg 23.8 shipped on August 19, 2026, the same day WordPress 7.1 “Mary Lou” cut. The release post on Make/Core is worth reading end-to-end, but four items are load-bearing for anyone working on real client sites.

Visual revisions now have shareable URLs. Every revision is addressable via a revision=<id> query parameter, so wp-admin/post.php?post=42&revision=987 opens the editor straight to that comparison. The address bar updates as you step through the timeline, using history replacement so the browser back button does not fill up with noise. There is throttling in place to stay within Safari’s 100 History API calls per 30 seconds, and invalid revision IDs fall back cleanly. Priethor’s PR #79934 merged on August 3 and was backported to WordPress 7.1.

The revisions screen gets a code diff view. Toggle “Show changes” and you see the raw block markup with added and removed lines highlighted. This is the fix for the long-standing problem that a visual diff misses attribute-level edits — a colour token, a class change, an ID swap that renders identically but behaves differently downstream. PR #80314 ships this without sending you back to the classic revisions screen every time you need to see the actual HTML.

Notes send email when someone @-mentions you. Adam Silverstein’s PR #79606 parses the mention markup out of saved notes, walks the mentioned users, and sends each one an email in their preferred locale via switch_to_user_locale(). Self-mentions are skipped, the post author is skipped to avoid double-notifying, only users who can edit the comment receive mail, and the whole flow respects the existing wp_notes_notify preference. Editing an existing note does not re-fire notifications. This is exactly the shape of behaviour you want for editorial workflows that involve more than one human.

Select all no longer freezes the editor on long posts. On a post with 1,000 paragraph blocks, pressing “Select all” twice used to take 16.8 seconds. It now takes 0.4 seconds. Mamaduka’s PR #81210 replaces per-block parent-walking with a pre-built set of selection ancestors and skips the deep inner-block check when there is no section block in play. That is a forty-times speedup landed as a bug fix; if you work on long-form content, this alone is worth the release.

One more thing worth flagging: PR #81231 replaces the empty-state block appender with an actual rendered default block. No layout shift when you start typing, focus and caret carry over, and screen readers announce it as a block rather than a button. Small change, better accessibility, no ceremony.

Why it matters for WordPress and WooCommerce people

Shareable revision URLs sound like a nice-to-have until you sit in an editorial standup and try to describe an edit without one. Every time I have run a content-heavy client through their first quarterly audit, the bottleneck is the same: someone needs to point at a specific change and say “revert this, keep that.” Being able to paste a URL that opens the editor to the exact before/after cuts that conversation from twenty minutes to two. It also gives your ticketing system something durable to point at, which matters more than it sounds like it should.

The code diff view is the more consequential feature for developers and design-system owners. WooCommerce product descriptions are full of attribute-only changes: a class flip that unhooks a global style, a schema tweak that breaks a filter, a data attribute that alters how a block behaves in the front-end. Visual diffs cannot see any of that. Having a code diff inline with the visual one means you can actually catch these in review instead of at deploy time.

Email on @-mention closes a real gap. Notes, introduced earlier in the 7.x cycle, were only genuinely useful if everyone on the team happened to be in the editor at the same time. Async notification turns them into a lightweight review workflow. It is not a replacement for a proper editorial tool, but for teams of two to five it is enough — and it does not require another SaaS subscription.

And the Select all fix — I would file this one under “reasons long-form authors stop threatening to move to another CMS.” Nothing kills trust in a tool faster than a two-second freeze on a keyboard shortcut, let alone sixteen.

What I would do (or not do) about it

If you are already on WordPress 7.1, most of this is already in your hands. The visual revisions changes and the Select all perf fix were backported to 7.1, so you do not need the Gutenberg plugin to get them. Verify on a staging environment first — the URL synchronisation is the kind of change that is well-tested but touches every editor session, and the one place I would look hard is any custom meta box behaviour that intercepts the revisions UI.

If you run editorial teams, update your handover doc this week. Two lines: how to grab a shareable revision URL, and what a @-mention in a note now triggers. Both are small enough that most people will not discover them on their own, and both change how the day-to-day feels once you actually use them.

If you run WooCommerce catalogues with hundreds of edits per week, turn the code diff view on in your review process. Not everywhere — just for the templates, product blocks, and any custom blocks where attributes carry meaning. That is the part where visual-only review has been quietly costing you.

What I would not do: install the Gutenberg plugin on production sites just to get 23.8 features that are already in 7.1. The plugin is a preview channel. On production, ride the core release train.

Gutenberg 23.8 is a quiet release with loud consequences for anyone whose day involves editing WordPress content with other humans. It does not add a new headline block or a new API surface. It fixes four things that have been quietly annoying editors and reviewers for years, and it moves the collaboration story forward without asking anyone to change their workflow.