Editor: clarify save failure notices

[youknowriad]

What?

Updates editor save failure notices to use context-specific copy (e.g. autosave, publishing or scheduling request), explain local persistence and retry behavior, and avoid appending raw server error text.

Why?

Autosave failures currently fall back to the generic update failure notice, which is less clear in context and can append cryptic backend messages that are not actionable for most users.

How?

This passes save options into the save-failure notice builder so autosave requests can use dedicated notice strings for normal and offline failures, while preserving existing publish/update failure behavior. It also adds unit coverage for the autosave-specific notice path.

Testing Instructions

1. Open a post or page in the editor.
2. Trigger an autosave failure, for example by simulating a failed autosave request.
3. Confirm the notice says: Auto-save failed. Your changes will be persisted locally to avoid content loss. We’ll retry automatically, or you can save manually.
4. Confirm the notice does not append the raw server error text.
5. Run npm run test:unit -- packages/editor/src/store/utils/test/notice-builder.js --runInBand.

Testing Instructions for Keyboard

1. Open a post or page in the editor using keyboard navigation only.
2. Trigger an autosave failure.
3. Confirm the autosave failure notice content matches the expected text and is announced without any appended raw server error text.

Screenshots or screencast

[github-actions]

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 props-bot label.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @riad@Riads-MacBook-Air.local.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Unlinked contributors: riad@Riads-MacBook-Air.local.

Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: tyxla <tyxla@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: richtabor <richtabor@git.wordpress.org>
Co-authored-by: jasmussen <joen@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Size Change: +444 B (+0.01%)

Total Size: 7.81 MB

📦 View Changed

Filename	Size	Change
build/scripts/editor/index.min.js	508 kB	+245 B (+0.05%)
build/styles/editor/style-rtl.css	31.4 kB	+53 B (+0.17%)
build/styles/editor/style-rtl.min.css	26.7 kB	+48 B (+0.18%)
build/styles/editor/style.css	31.5 kB	+50 B (+0.16%)
build/styles/editor/style.min.css	26.7 kB	+48 B (+0.18%)

_{compressed-size-action}

[github-actions]

Flaky tests detected in fcb082c.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/30898208015
📝 Reported issues:

• [Flaky Test] Create a custom template #51883 in /test/e2e/specs/site-editor/templates.spec.js
• [Flaky Test] should cut and paste individual blocks with collapsed selection #80248 in /test/e2e/specs/editor/various/copy-cut-paste.spec.js

[richtabor]

Error messages should be plain language, reassure you, and help you recover from error.

I'd say this meets that criteria quite well.

[youknowriad]

The downside here is that we're losing the actual "raw message" from the server, which can be confusing but also helpful to debug. So I wonder how we can either incorporate it somehow, alternatively we could just dump it into the console but it will be more hidden.

[youknowriad]

Rich, what do you the messaging should be for publish/update errors.

[Mamaduka]

The downside here is that we're losing the actual "raw message" from the server, which can be confusing but also helpful to debug.

I tried to do that as part of #64158, but eventually closed my PR - #68360 (comment).

[richtabor]

Rich, what do you the messaging should be for publish/update errors.

What do you think of these:

Publishing failed. Your content will be persisted locally to avoid content loss. Please try publishing again.
Scheduling failed. Your content will be persisted locally to avoid content loss. Please try scheduling again.

[youknowriad]

They work for me, with the same caveat that they hide the actual error message that might help debugging.

[youknowriad]

I added a "show details" to show the raw error message in a modal to not lose the "debugging" possibilities.

WDYT?

I also updated all the messages. (save, publishing, scheduling and auto-save)

[tyxla]

We might want to rebase this one since there have been some changes to autosaving. Would be nice to have @Mamaduka's feedback here, since he's been working in this area.

[Mamaduka]

I was just reading #81143 from @jasmussen when I saw the notification and was wondering how much of these new guidelines we should apply to similar failure messages.

Not trying to block this, but we have new guidelines for similar notices; it's better to match them.

[jasmussen]

I'm for sustained iteration. Small improvements over time. That's why I added the docs, so that we are moving in the right direction. With that I'm not suggesting to not do small PRs to align, but also contextualising that the docs were not meant as urgent to address, but rather some institutional knowledge to catalogue.

[Mamaduka]

With that I'm not suggesting to not do small PRs to align, but also contextualising that the docs were not meant as urgent to address, but rather some institutional knowledge to catalogue.

Of course, but why not align before something ships, if that's possible?

[youknowriad]

@Mamaduka How would you improve this. This is specifically a way to apply these guidelines (with the information that we dispose)

[Mamaduka]

Here are screenshots of offline failures: save post and autosave failures. It seems that "Show details" just repeats the same info as the main notice content.

I'll try to brainstorm further. Again, not trying to block this, feel free to merge, and we can iterate later.

Screenshot

[youknowriad]

Agreed, seems there are cases where the "show details" don't bring value. I'll remove the redundancy there and keep it for the cases where it matters (server errors mostly)