Phase 1: Add Edit / Suggest / View intent mode scaffolding#77403
Phase 1: Add Edit / Suggest / View intent mode scaffolding#77403adamsilverstein wants to merge 6 commits intotrunkfrom
Conversation
f78a787 to
3ca48fe
Compare
Introduce an `editorIntent` preference orthogonal to the visual/code `editorMode`. The intent captures the user's editing purpose: direct editing (`edit`, default), proposing changes for the author to apply or reject (`suggest`), or a read-only preview (`view`). This is Phase 1 of the Suggest mode effort in #73411. It adds the `setEditorIntent` action, `getEditorIntent` selector, and an Intent switcher menu gated on `editor.notes` post type support. The `view` intent reuses the existing block-editor `isPreviewMode` plumbing to disable editing. Follow-up phases wire capture, diff preview, and apply / reject for the `suggest` intent. Refs #73411
3ca48fe to
4bdfdda
Compare
|
Size Change: +550 B (+0.01%) Total Size: 7.91 MB 📦 View Changed
ℹ️ View Unchanged
|
|
Flaky tests detected in d45e494. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/25348357203
|
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: +554 B (+0.01%) Total Size: 7.91 MB 📦 View Changed
ℹ️ View Unchanged
|
Document the storage location (preferences store), per-app defaults, and multi-file mirroring requirement so reviewers can trace the intent state without cross-referencing five files. Also explain why unknown intents are silently rejected by setEditorIntent.
d45e494 to
89c12b6
Compare
Overview
This is one of 5 stacked PRs implementing Suggestion mode for the WordPress editor - a Google Docs–style workflow where reviewers can propose changes that the post author can Accept or Reject. Tracked in #73411, with design direction from #73410 and jasmussen's mockups.
Part of #73410
Testing this feature
To test the complete feature, use
gh repo set-default WordPress/gutenberg && gh pr checkout 77407to fetch the code of all 5 stacked PRs together
or if you don't have the gh cli use:
git fetch upstream pull/77407/head:pr-77407 && git checkout pr-7740Screencasts
Here is the current feature captured 5/4/26. In this view I have two side by side windows open with two separate users editing the same post. The feature works with or without real time collaboration, but I wanted to capture the fully collaborative suggestion experience:
Accepting addition
suggest.add.mp4
Accepting style change
apply.bold.suggestio.mp4
Accepting deletion
suggest.delete.mp4
Rejecting suggested deletion
reject.delete.mp4
Reviewing the code
The code for this feature is split into 5 separate phases to make the reviews smaller. Each PR should be reviewed separately.
Architecture & Yjs readiness
The eventual long-term storage primitive for suggestions is the Yjs
AttributionManagerarriving in Yjs v14 (PR #77005), which attributes CRDT document changes to specific clients - exactly what suggested edits need. However, Yjs v14 is pre-release with an unstable API, and even with Yjs, server-side persistence is still needed for non-RTC users.Rather than block on Yjs, this series builds the full feature now with a comment-meta backend behind a swappable
SuggestionsProviderinterface shaped to match Yjs attribution semantics:attribute-set) - not HTML diffs - so they map directly to whatAttributionManagerwould emit.createSuggestion,updateSuggestion,deleteSuggestion,applySuggestion,rejectSuggestion. Today's implementation reads/writes comment meta; a futureyjs-provider.jscan drop in with the same methods.When #77005 stabilizes, the migration is: implement
yjs-provider.jsagainst the same interface, useAttributionManagerfor live-session attribution, and keep comment-meta as the fallback for users without RTC.The 5 phases
editorIntentpreference (edit/suggest/view), a mode selector in the Options kebab, read-only gating for View intent, keyboard shortcuts, and a "You're suggesting/editing/viewing" snackbar on mode change.editor.BlockEditfilter divertssetAttributesinto a React context so the user sees their edit live but the block-editor store stays at the baseline. The HOC is split so non-Suggest intents only run a singleuseSelect._wp_suggestioncomment meta, theSuggestionsProviderinterface (create/update/delete/apply/reject), and the accept/reject icon buttons in the notes sidebar.This PR (Phase 1)
editorIntentpreference (edit,suggest,view) orthogonal to the existing visual/codeeditorModesetEditorIntentaction +getEditorIntentselector in the editor store<IntentSwitcher>component: Edit / Suggest / View menu in the Options kebab, gated oneditor.notespost type support⌥⇧⌘Z/X/C, orCtrl+Alt+Shift+…on Windows/Linux)viewintent reuses the existingisPreviewModeblock-editor setting for read-only rendering - no new machineryWhat's NOT in this PR
_wp_suggestioncomment meta and accept/reject provider (Phase 3)Phase 1 test plan
contenteditable="false")npm run test:unit -- packages/editor/src/store/test/actions.js --testNamePattern=setEditorIntentnpm run test:e2e -- test/e2e/specs/editor/various/editor-intent-switcher.spec.js📋 Tracking issue: #73411
AI Use
I prompted Claude to write this code and reviewed and tested it manually.