Gutenberg 23.8 adds shareable URLs for visual revisions. A revision parameter can open the editor at a specific change, and the address bar follows navigation through revision history. This makes editorial review easier, but teams must verify that copied URLs still enforce post, revision, and editor permissions after sign-out, session expiry, role changes, private status, autosaves, and content deletion.
Use this for publishers, agencies, membership sites, newsrooms, and regulated teams that discuss drafts and revisions through tickets, chat, email, or project-management links.
Quick answer
Create synthetic public, private, pending, and draft posts with two revisions and an autosave. Copy each revision URL as an editor, then open it in an authorized second user, a lower-role user, an expired session, and a signed-out browser. Record the final URL, status, editor state, visible title and content, network responses, and audit trail. The link may identify a revision, but authorization must still come from the current user session and current post capabilities.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Authorized editor | Draft revision URL | Specific revision opens |
| Subscriber | Same copied URL | No editor or revision content |
| Expired session | URL after cookie expiry | Login flow, then permission check |
| Role removed | Previously authorized user | Access denied immediately |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Build a synthetic role and status matrix before using revision URLs in real editorial work. | Record the exact post, revision, autosave, author, status, and user role for each synthetic fixture. | Every authorized role reaches the expected revision and editor context. |
| Confirm current WordPress capability checks cover parent posts, revisions, autosaves, and changed roles. | Open a copied revision URL as administrator, editor, author, subscriber, signed-out user, and a user whose role was just removed. | Denied roles receive no revision body in HTML, script state, or API output. |
| Exclude editor routes and revision parameters from shared caches and analytics where appropriate. | Test private, password-protected, scheduled, trashed, and deleted-parent states without using customer content. | Role removal and session expiry take effect without a stale-cache window. |
| Teach reviewers to share only inside approved systems with suitable retention. | Inspect browser history, referrer behavior, server logs, and collaboration tools for revision identifiers that exceed retention policy. | Ticket, chat, analytics, and log retention match the editorial policy. |
What to check first
- Record the exact post, revision, autosave, author, status, and user role for each synthetic fixture.
- Open a copied revision URL as administrator, editor, author, subscriber, signed-out user, and a user whose role was just removed.
- Test private, password-protected, scheduled, trashed, and deleted-parent states without using customer content.
- Inspect browser history, referrer behavior, server logs, and collaboration tools for revision identifiers that exceed retention policy.
- Verify every denied path shows a safe login or permission response without exposing revision text in HTML, script state, or API responses.
Field notes
- Use synthetic IDs and examples that can be traced from the first request or interaction to the final record.
- Keep a before and after result for every changed setting, package, selector, route, or deployed version.
- Separate user-visible success from internal success so a green interface cannot hide a failed request or inaccessible control.
- Review the evidence after caches, queues, browser history, and scheduled work have had time to settle.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
fixture_id: revision-share-01
post_status: private
revision_ids: [8841, 8842]
roles: [editor, author, subscriber, signed_out]
expected_denied: [subscriber, signed_out]
record: status + final_url + visible_content + api_calls
Why this usually happens
- A team mistakes a shareable identifier for a public sharing feature.
- A plugin checks access to the parent post but not the requested revision or current role.
- Cached editor bootstrap data leaks a previous authorized response.
- Tickets and analytics retain full editor URLs longer than the editorial record requires.
Decision rule
Adopt revision URLs when they reliably open the intended change for authorized users, reveal no revision content to denied users, and fit the organization's link-retention and audit policy.
Production verification checklist
- Every authorized role reaches the expected revision and editor context.
- Denied roles receive no revision body in HTML, script state, or API output.
- Role removal and session expiry take effect without a stale-cache window.
- Ticket, chat, analytics, and log retention match the editorial policy.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Build a synthetic role and status matrix before using revision URLs in real editorial work.
- Confirm current WordPress capability checks cover parent posts, revisions, autosaves, and changed roles.
- Exclude editor routes and revision parameters from shared caches and analytics where appropriate.
- Teach reviewers to share only inside approved systems with suitable retention.
- Monitor denied requests and retest after role, SSO, cache, and collaboration-plugin changes.
Mistakes to avoid
- Changing production before recording exact versions, UTC timestamps, settings, stable fixture IDs, and a reproducible baseline.
- Treating one successful screen as proof that keyboard access, APIs, caches, jobs, reports, analytics, and downstream records agree.
- Testing only an administrator session instead of the devices, roles, networks, locales, and failure branches customers use.
- Closing the work without a named owner, rollback point, observation window, and contextual incoming link from an established guide.
Questions teams ask during testing
Can this be tested on production?
Use production for read-only checks and one narrow synthetic fixture that cannot charge a card, send customer email, expose personal data, or change inventory. Run upgrades, package changes, cache changes, and destructive repairs on staging first.
What evidence should the test report keep?
Keep exact versions, UTC timestamps, stable synthetic IDs, expected and actual results, screenshots or response excerpts, the decision owner, rollback point, and final verification. Redact credentials, tokens, customer data, private addresses, and infrastructure details.
How long should the observation window stay open?
Keep it open long enough to include at least one cache cycle, scheduled job cycle, and representative traffic period. For release changes, include logged-in and logged-out use plus the first real operational handoff.
When is the task complete?
Complete it when the primary user path passes, downstream records reconcile, failure branches are understood, monitoring is active, and an established owner page links to this guide in context.
What to tell the client or owner
Give the site owner the affected versions, exact synthetic fixture, UTC timeline, before and after evidence, cause class, decision, rollback point, unresolved risks, and next review date. State which measurements prove success and which observation window remains open.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, audit a WordPress editorial workflow.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references