Consistent Navigation in WordPress 7.1 With Persistent Toolbar ![rw-book-cover](https://s.w.org/images/home/wordpress-default-ogimage.png) 🔗 **Source:** [Consistent Navigation in WordPress 7.1 With Persistent Toolbar](https://make.wordpress.org/core/2026/07/13/consistent-navigation-in-wordpress-7-1-with-persistent-toolbar/) > [!note]+ Document Notes > tags: [wordpress-core, editor-ux, gutenberg, admin-toolbar, developer-notes] > author: [MISSING] > source: Make WordPress Core > reference: https://make.wordpress.org/core/2026/07/13/consistent-navigation-in-wordpress-7-1-with-persistent-toolbar/ > date created: 2026-07-16 11:35 > > # 🏷️ Title: Consistent navigation in WordPress 7.1 with persistent toolbar > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Trac ticket #65091](https://core.trac.wordpress.org/ticket/65091) - [Trac ticket #65088](https://core.trac.wordpress.org/ticket/65088) - [Gutenberg iteration issue #79036](https://github.com/WordPress/gutenberg/issues/79036) - [Distraction Free mode documentation](https://wordpress.org/documentation/article/distraction-free-mode/) ## 📝 Summary - WordPress 7.1's editor now shows the persistent admin toolbar by default (matching the rest of wp-admin), fixing a longstanding navigation confusion: the top-left "W" logo/site icon previously doubled as both brand mark and "exit editor" back button, which didn't read as a back button to users. - Three coordinated changes fix it: the toolbar now appears in the editor everywhere except Distraction Free mode; the "W" logo/site icon is replaced by a dedicated chevron back button; and the site icon (when set) moves into the toolbar itself. - Result: each icon now means exactly one thing everywhere in wp-admin — "W" logo always opens the About page, site icon always opens the site menu, chevron always navigates back. The site title stays visible throughout the editor, including on the editing canvas. - This directly builds on the Beta 1 announcement's "persistent toolbar (Omnibar)" bullet, processed earlier this session — this dev-note is the detailed technical/developer-facing writeup of that feature. - Stakeholders: end users navigating Post/Site Editors (fewer accidental exits), plugin developers who add toolbar nodes (need to verify Site Editor compatibility, since a persistent toolbar there is new behavior), and Core/Gutenberg contributors who scoped and shipped the three-part fix. - Risk/tradeoff: this is a breaking behavioral change for the Site Editor specifically (no prior "fullscreen toggle" existed there the way it did in the Post Editor), so plugins that assumed the Site Editor never showed a toolbar node need to explicitly re-test or filter it out. The post ships a concrete PHP filter snippet for developers who want to opt out per-screen. - Bottom line: a small, well-scoped UX fix (three changes, one back button icon swap) resolving a multi-year point of confusion, with a documented opt-out path for Distraction Free users and a documented compatibility check for plugin authors. ## 📖 Main Content The post opens by naming the specific problem precisely: the "W" logo/site icon in the block editor's top-left corner served as the back/exit button, but visually and semantically a logo does not communicate "click to leave." This is presented as a "frequent source of confusion" — a usability complaint the Core team decided was worth fixing directly rather than working around with tooltips or onboarding hints. The fix is structural, not cosmetic: rather than just relabeling the existing icon, three separate but coordinated changes restore a consistent meaning-per-icon model across the entire admin interface. Before this change, the block editor was a UI exception — no persistent toolbar, and an overloaded logo icon. After, the editor behaves identically to every other wp-admin screen, with one carve-out (Distraction Free mode, which intentionally hides all chrome including the toolbar, preserved as-is). The post includes before/after screenshot pairs (both plain and with a custom site icon set) to make the visual change concrete — readers can see the chevron replacing the logo and the toolbar appearing above the editor canvas. Two audience-specific subsections follow the visual explanation. For users: default behavior changes (toolbar now shows), with Distraction Free mode as the existing escape hatch for anyone who preferred the old chrome-free editor. For plugin developers: an explicit compatibility warning that the Site Editor previously had no persistent-toolbar mode at all (unlike the Post Editor, which could already show the toolbar with fullscreen mode off), so any plugin injecting a toolbar node needs to verify it renders correctly there now — and a ready-to-use PHP snippet is provided for developers who want to suppress their node in the Site Editor or in any block editor screen, using `$screen->is_block_editor()`. The post closes with standard Make WordPress Core dev-note scaffolding: Trac ticket links (#65091, #65088), a Gutenberg iteration-issue link, and a props line crediting six reviewers. The comment thread (four public comments visible at scrape time) surfaces mixed reception: one commenter calls it a "great improvement" for less-technical users; another objects that a custom site icon should never have been allowed to visually replace the WordPress logo in the first place, and wants the site icon removed from the toolbar entirely (calling it "disrespectful for the brand" and unnecessary "load"); a third is simply glad to see it land; a fourth is more pointed, framing this as fixing a nine-year-old regression ("not sure why it's taken nine years to restore a persistent admin bar"), needling Gutenberg's broader UX design history with a "don't be like vim" jab, and specifically criticizing the historical decision to reuse the "About WordPress" icon for "Exit the Block Editor" as itself the original design mistake being corrected now. ### 🗒️ Notes - This dev-note directly operationalizes one bullet point from the WordPress 7.1 Beta 1 announcement post (processed earlier this session) — "Persistent toolbar (Omnibar): The admin toolbar now travels with you into the Site Editor and Block Editor, with a series of polish improvements throughout." This post is the polish-improvements detail behind that one-line summary. - The filter snippet given (`admin_bar_menu` action, checking `$screen->is_block_editor()` or `'site-editor' === $screen->id`) is copy-paste-ready and specific enough to use directly — worth flagging for any plugin/theme work (Outpost & Co., Post Kinds/IndieWeb companion plugins) that adds admin bar nodes, to audit whether Site Editor rendering needs an explicit check now. - The comment thread's brand-purity objection (site icon shouldn't visually stand in for the WordPress logo) is a real, if minority, UX-philosophy disagreement — worth noting as an unresolved tension rather than settled consensus, since the dev-note itself treats the site-icon-in-toolbar behavior as the intended, shipped design. ## 📚 References - [Trac ticket #65091](https://core.trac.wordpress.org/ticket/65091) — primary tracking ticket - [Trac ticket #65088](https://core.trac.wordpress.org/ticket/65088) — secondary tracking ticket - [Gutenberg iteration issue #79036](https://github.com/WordPress/gutenberg/issues/79036) — implementation discussion/iteration thread - [Distraction Free mode documentation](https://wordpress.org/documentation/article/distraction-free-mode/) — the escape hatch referenced for users who want the old chrome-free behavior ## 🗣️ Paraphrase - **Problem paragraph**: The editor's top-left icon used to do double duty as both the WordPress brand mark and the "leave the editor" button, and because a logo doesn't visually communicate "back," people kept clicking it by accident or missing it as a way out — a genuinely confusing overload of one icon's meaning. - **Fix paragraph**: Instead of a small tweak, Core shipped three linked changes — always-on toolbar in the editor (except Distraction Free mode), a dedicated chevron for "back," and the site icon (if set) relocated into the toolbar — so that from now on, every icon in wp-admin means exactly one consistent thing no matter which screen you're on. - **Developer paragraph**: Because the Site Editor never had a toggleable toolbar before, plugin authors who add toolbar nodes should specifically re-test in the Site Editor now that it's persistent there, and a documented PHP filter is available to opt a node out of block-editor screens entirely if desired. ## 📰 Newsletter **WordPress 7.1 fixes a nine-year-old navigation gripe: the "W" logo finally stops pretending to be a back button.** 🎯 If you've ever clicked the top-left logo in the block editor expecting it to take you back, only to have it act inconsistently (or not at all) depending on context — WordPress 7.1 fixes that directly. Three changes ship together: the toolbar now stays visible in the editor like it does everywhere else in wp-admin, a proper chevron back-arrow replaces the overloaded "W" logo, and your site icon (if you've set one) moves into the toolbar where it belongs. Plugin authors: if you add a node to the admin toolbar, this is the moment to check it in the Site Editor specifically — it never had a persistent toolbar before, so this is new surface area. The post ships a ready PHP snippet using `$screen->is_block_editor()` if you want to hide your node there. ## ✅ Action Items #### DevRel - Developer experience: circulate the `$screen->is_block_editor()` filter snippet to plugin authors who register toolbar nodes, framed as "check this before 7.1 ships," not just informational. - Developer advocacy: this dev-note is a clean example of "before/after screenshots + user-facing summary + developer-facing compatibility note + copy-paste code snippet" structure — worth using as a template for future dev-note guidance to Core contributors writing their own. #### OSPO - Not applicable to this source — no license, governance, or security-disclosure content. #### Community - Maintainers: the comment thread's brand-consistency objection (site icon vs. WordPress logo in the toolbar) is worth tracking as an open community sentiment item, even though it doesn't block the shipped feature. - Ecosystem: any plugin/theme with an admin-bar integration (analytics widgets, SEO tools, page builders) should be notified specifically about Site Editor toolbar-node compatibility ahead of 7.1's stable release. #### WordPress - Core: this is itself a Core UX fix — track its landing as confirmation that the Beta 1 "persistent toolbar" bullet shipped as described. - Accessibility: verify the new chevron back-button has an accessible name/label distinct from the site-icon and "W" logo buttons, since three visually distinct icons now carry three distinct actions — screen reader users need unambiguous announcements for each. - Documentation: developer.wordpress.org and any plugin-development handbook pages referencing `admin_bar_menu` should be updated/cross-linked to this dev-note's Site Editor compatibility guidance. - Themes: theme authors bundling their own admin-bar customizations (rare, but exists) should audit against the new persistent Site Editor toolbar. - Plugins: any plugin author who filters or adds to `$wp_admin_bar` should test in the Site Editor specifically before the 7.1 stable release, per this dev-note's explicit call-out. #### The WPCC - Not applicable to this source. ### FAIR - Not applicable to this source. ## 🧪 Hypotheses - H1: Replacing the "W" logo/site-icon back button with a dedicated chevron will measurably reduce accidental editor-exit support tickets/forum threads compared to the pre-7.1 UI. - H2: A meaningful share of existing plugins that add nodes to `$wp_admin_bar` will render those nodes unexpectedly (overlapping UI, broken styling) in the newly-persistent Site Editor toolbar until explicitly tested/patched. - H3: Users who previously relied on the Post Editor's non-fullscreen mode as a workaround to see the toolbar will show reduced usage of that workaround once the toolbar is persistent by default in 7.1. - H4: The minority "remove the site icon from the toolbar entirely" sentiment expressed in comments will not gain enough traction to change the shipped design before general release, since the feature is presented as already decided/shipped rather than open for comment. ### 📊 Methodology - H1: Before/after comparison of WordPress.org support-forum thread volume and Trac ticket volume tagged with editor-navigation-confusion keywords, in the 8 weeks before and after 7.1's general release. - H2: A structured compatibility audit — install a sample of top 50-100 popular plugins that hook `admin_bar_menu`, load each in the Site Editor under 7.1, and log rendering/behavior issues. - H3: Telemetry (if available, e.g. via a Core feature-usage survey or opt-in analytics) comparing fullscreen-mode-toggle frequency before and after 7.1's release. - H4: Track the linked Trac tickets (#65091, #65088) and the Gutenberg iteration issue for any follow-up changes responding to the site-icon-removal comment thread over the following release cycle. ### ❓ Questions - Does the new chevron back-button have a distinct, unambiguous accessible name (e.g., "Back to [previous screen name]") for screen reader users, given three icons now sit in close visual proximity with three different functions? - What specific rendering issues (if any) were found during Core's own internal testing of third-party toolbar nodes in the Site Editor before this shipped? - Will the site-icon-in-toolbar behavior be made optional/toggleable in a future release in response to the brand-consistency objection raised in comments, or is it considered settled? - How does this change interact with multisite / network-admin toolbar behavior, which isn't addressed in this post? ### 🔮 Future Research - A follow-up compatibility survey of the plugin directory's top admin-bar-integrating plugins post-7.1-release, to quantify how many needed patches for Site Editor rendering. - Accessibility audit of the three-icon toolbar cluster (W logo / site icon / chevron) against WCAG 2.2 AA criteria for distinguishable, unambiguous interactive controls. - Tracking whether the brand-consistency complaint (site icon in toolbar) resurfaces as a formal Trac ticket or Gutenberg issue in a future release cycle. ### 💡 Implications - **Practice**: Plugin/theme developers maintaining any WordPress product with admin-bar integrations should add "test in Site Editor" to their pre-7.1-upgrade QA checklist as a direct, actionable item from this dev-note. - **Policy**: This is a good example of Core treating a UX confusion report as worth a structural fix (three coordinated changes) rather than a documentation/tooltip patch — a pattern worth citing when advocating for similar UX-debt fixes elsewhere in wp-admin. - **Accessibility**: The three-icon toolbar redesign is an opportunity (not yet confirmed as executed) to ensure each icon has clearly distinguishable accessible names — worth an independent audit rather than assuming it was handled correctly by default. - **Education**: The dev-note's structure (problem statement → before/after visuals → user-facing summary → developer-facing compatibility note → code snippet → tracking links) is a strong template for technical writers documenting other Core UX changes. ### 🧠 Learning Styles Assessment - Reading level estimate: Flesch-Kincaid Grade ≈ 9–10 (technical dev-note prose, moderate sentence length, WordPress-specific jargon like "fullscreen mode," "Distraction Free," "admin_bar_menu" used with light definition). #### 👀 Visual learners - Present: strong — four before/after screenshot pairs (plain and with site icon set) directly show the UI change. - Improve: an annotated version of the same screenshots (labeled arrows pointing at "chevron = back," "site icon = site menu," "W logo = About") would make the "one icon, one meaning" claim even more immediately legible. #### 🔊 Aural learners - Present: none — text/image-only dev-note with no audio companion. - Improve: not a strong fit for this content type; a brief audio summary would be disproportionate effort for a short dev-note. #### 🗣️ Verbal learners - Present: the "each icon means one thing everywhere" framing is a clean, memorable verbal summary of the whole change. - Improve: a short glossary distinguishing "toolbar," "Omnibar" (used in the Beta 1 post but not here), and "admin bar" would help readers who encounter these terms as synonyms across different WordPress.org posts. #### 🧩 Kinesthetic learners - Present: the PHP filter snippet is a genuine copy-paste-able, testable artifact for plugin developers. - Improve: a companion "how to test your plugin's toolbar node in the Site Editor" step-by-step (enable Beta Tester plugin → open Site Editor → check your node) would convert the snippet into a guided exercise. #### 🧠 Logical learners - Present: the "before: overloaded icon / after: one icon, one meaning" structure is a clear before/after logical mapping. - Improve: a simple table (Icon | Meaning before 7.1 | Meaning after 7.1) would let logical learners audit the change at a glance instead of reading prose. #### 🧑‍🤝‍🧑 Social learners - Present: the comment thread itself is a live social artifact — real practitioner reactions, including disagreement, visible on the page. - Improve: none needed — the comments already provide this. #### 🧘‍♀️ Solitary learners - Present: the post is fully self-contained and actionable without needing discussion. - Improve: a self-check for plugin developers ("does your plugin add an admin bar node? have you tested it in the Site Editor under 7.1 Beta?") would prompt independent verification. #### 🌿 Naturalistic learners - Present: not applicable — no ecosystem/sustainability framing; this is a UI/UX dev-note. - Improve: not applicable to this source. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: not independently verifiable from the post text alone — the post doesn't state whether the new chevron and relocated site-icon button have appropriate `aria-label`s distinguishing them from the "W" logo button. - Improve: this needs direct testing against the shipped beta build rather than being inferred from the announcement; flagged as an open question above. #### Keyboard navigation - Present: not addressed in the post. - Improve: verify tab order through the three-icon cluster (W logo → site icon → chevron, or whatever the shipped order is) is logical and that each is independently focusable/activatable via keyboard. #### Contrast and readability - Present: not addressed in the post text; the before/after screenshots would need direct visual review to assess icon contrast against the toolbar background. - Improve: a direct contrast check of the chevron icon against toolbar backgrounds in both light and dark admin color schemes. #### Text resizing and reflow - Present: not addressed in the post. - Improve: verify the toolbar (now persistent in more contexts) reflows correctly at 200% zoom without icon overlap, especially with a site icon added to the existing "W" logo and chevron. #### Media and captions - Present: screenshots are provided but no alt text is visible in the scraped content for the four before/after image pairs (alt attributes render empty in the fetched markdown). - Improve: add descriptive alt text to each before/after screenshot pair (e.g., "Before: W logo doubles as back button and brand mark. After: dedicated chevron back button, W logo now only opens About page") so screen reader users get the same information sighted users get from the images. #### Forms and interactions - Not applicable to this source — no forms; the PHP code snippet is a developer artifact, not a user-facing form. #### Standards reference - The missing alt text on the four screenshot pairs is a direct WCAG 2.2 AA gap (Success Criterion 1.1.1, Non-text Content) on the dev-note page itself — the single most concrete, checkable accessibility finding from this source. ### 🌍 DEIB Assessment #### Cultural breadth - Not applicable to this source — a technical UI/UX dev-note with no cultural/regional framing to assess. #### Inclusive language - Present: plain, jargon-light technical language; gender-neutral throughout. - Improve: none needed. #### Neurodiversity support - Present: the "one icon, one meaning everywhere" design principle itself is a neurodiversity-friendly UX improvement — consistent, predictable icon semantics reduce cognitive load for users who rely on stable visual patterns. - Improve: none needed; this is a strength worth naming explicitly, since the post doesn't frame it in accessibility/neurodiversity terms even though that's effectively what it delivers. #### Representation - Present: six named reviewers credited by WordPress.org username; typical Core dev-note attribution practice. - Improve: not applicable — standard practice for this content type. #### Psychological safety - Present: the post's tone is calm and procedural; the comment thread includes some pointed criticism (the "nine years," "don't be like vim" comment) but it's aimed at the design decision/product, not at named individuals. - Improve: none needed. ### ✅ Logical Validity #### Strong reasoning - The core argument — that a logo icon doesn't semantically communicate "go back," so overloading it with that function causes confusion — is a well-established, uncontroversial UX principle (icons should map to consistent, learnable meanings), and the post's fix directly targets that root cause rather than a symptom. - The "one icon means one thing everywhere" design goal is internally consistent with the three specific changes described — each change maps cleanly onto restoring exactly one semantic meaning to exactly one icon, which is good design-to-implementation traceability. #### Fallacies - No significant fallacies identified in the dev-note's own text — this is a factual, procedural announcement, not an argumentative piece. The comment thread contains a few reader-side rhetorical moves (e.g., "don't be like vim" is more a stylistic jab than an argument) but these are audience reactions, not part of the source's own reasoning, and don't need correction from this analysis. #### Tone of voice - Neutral, procedural, standard Make WordPress Core dev-note register — states the problem, states the fix, documents the developer-facing implications, provides tracking links. No persuasive or promotional language. ### 🛡️ DARVO Analysis - Not applicable to this source — this is a routine technical dev-note with no accusation, conflict, or defensive framing present. The comment thread includes criticism of a past design decision, but the post itself doesn't respond defensively to it (the post predates the comments) and no denial/attack/reversal pattern is present anywhere in the source. ## 🎯 Conclusion - WordPress 7.1 fixes a specific, well-understood navigation confusion (the "W" logo/site icon doubling as an unclear back button) with a structural three-part change: a persistent toolbar in the editor (except Distraction Free mode), a dedicated chevron back button, and the site icon relocated into the toolbar. The result restores a consistent "one icon, one meaning" model across all of wp-admin, including the editor for the first time. - Practical next steps for readers: (1) plugin/theme developers who add nodes to `$wp_admin_bar` should test their nodes in the Site Editor under 7.1 Beta specifically, since it never had a persistent toolbar before; (2) use the provided PHP filter snippet (`$screen->is_block_editor()` check) if a toolbar node should be hidden on block-editor screens; (3) verify accessible names/labels on the three-icon cluster once the beta build is available for direct testing, since this analysis could not confirm that from the announcement text alone; (4) track the linked Trac tickets for any follow-up changes responding to the site-icon brand-consistency feedback in comments. ## 🔄 Refactor Appendix — Consistent navigation in WordPress 7.1 with persistent toolbar ### 📚 Literature Atoms (H3) #### [H1] Each toolbar icon now means exactly one thing everywhere > [!quote] ID:rw_wp71_toolbar_h1 > "The result is a navigation model where each icon means one thing everywhere: the 'W' logo always opens the About page, the site icon (when set) always opens the site menu in the toolbar, and the chevron always goes back to the previous screen." **Context & use**: - Core statement of the design goal and its resolution — the single sentence that best summarizes the entire fix. - Directly quotable as the thesis of the whole dev-note. **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H2] Plugin developers should verify toolbar nodes in the Site Editor > [!quote] ID:rw_wp71_toolbar_h2 > "The Site Editor has no such mode, so a persistent toolbar in the Site Editor is a new behavior. If your plugin adds a node in the toolbar, it's worth double-checking if it still works correctly in the Site Editor." **Context & use**: - The explicit, actionable compatibility warning for plugin/theme developers. - Directly relevant to any Outpost & Co. or Post Kinds/IndieWeb companion-plugin admin-bar integrations that should be audited before 7.1 ships. **Tags**: #xref #addendum **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Fix icon-overload confusion by giving every icon exactly one meaning **Claim** (one sentence, Courtney's voice): When a UI icon is overloaded to serve two purposes (e.g., a brand logo doubling as a navigation control), the durable fix is structural — give each icon exactly one consistent meaning across every screen — rather than a tooltip or documentation patch. **Evidence pointer**: [[#H1]] **Scope & conditions**: Holds for any UI system with reused icons across multiple contexts (admin panels, multi-screen apps); breaks down when the audience is small/expert enough that icon ambiguity genuinely doesn't cause confusion in practice. **Links**: - [[Ollie design system]] — because applies-in (same "one visual element, one meaning" principle used for design-token consistency) <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Audit Outpost & Co. and Post Kinds/IndieWeb companion plugins for any `admin_bar_menu` hooks — confirm rendering in the Site Editor under 7.1 Beta before general release. #xref - [F2] Check whether the four before/after screenshots on this dev-note have alt text on the live page (the scraped markdown showed empty alt attributes) — worth a direct visual/accessibility check rather than relying on the scrape. #articleseed ### → Things 3 (max 2 actions) - [ ] Test any admin-bar-integrating plugin work (Outpost & Co., Post Kinds/IndieWeb) against WordPress 7.1 Beta's Site Editor toolbar — WordPress 7.1 compatibility #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Consistent Navigation in WordPress 7.1 With Persistent Toolbar.md|Consistent Navigation in WordPress 7.1 With Persistent Toolbar by make.wordpress.org]] ## Highlights - The result is a navigation model where each icon means one thing everywhere: the “W” logo always opens the About page, the site icon (when set) always opens the site menu in the toolbar, and the chevron always goes back to the previous screen. The site title also stays visible throughout the editor, including on the editing canvas. See the following images: ([View Highlight](https://read.readwise.io/read/01kxnsc8da3hynx0xeepd06set)) - Note: Thesis of the whole dev-note: each toolbar icon now means exactly one thing everywhere. - Tags: atom/literature/h1 - Before WordPress 7.1, the toolbar could already appear in the Post Editor when the fullscreen mode is turned off. The Site Editor has no such mode, so a persistent toolbar in the Site Editor is a new behavior. If your plugin adds a node in the toolbar, it’s worth double-checking if it still works correctly in the Site Editor. ([View Highlight](https://read.readwise.io/read/01kxnsca62xjvxw9z0g2jdk115)) - Note: Explicit compatibility warning for plugin developers — Site Editor toolbar is new surface area. - Tags: atom/literature/h2, addendum