Add a copy-to-clipboard action to error messages

[JeffPaul]

Background

Concept originally from @matt's ​Defensive Data Design post:

Error messages should be how you'd describe it to a friend. And have a copy-to-clipboard next to it, so people can put into search/AI/whatever.

Problem

When users encounter an error, their next step is often to search for the message or share it with someone who can help. Today, this usually requires manually selecting the text, which can be difficult in notices, dialogs, mobile interfaces, or messages containing multiple lines.

A consistent copy action would reduce friction without requiring WordPress to prescribe what the user does with the information afterward.

Proposed behavior

Relevant error messages would display a copy icon (e.g. ​https://wphelpers.dev/icons/copy) adjacent to the message.

Selecting the icon would:

• Copy the complete error message to the clipboard.
• Briefly change the accessible label or status to confirm that the message was copied.
• Preserve error codes and other details that may help diagnose the issue.
• Exclude credentials, tokens, personal information, and other sensitive data.

The visible message and copied text could be identical in most cases. Where additional diagnostic context is useful, WordPress could copy a structured version containing the message, error code, failed action, and relevant non-sensitive environment details.

Accessibility

The control should:

• Be keyboard accessible.
• Include an accessible label such as “Copy error message.”
• Provide a non-visual confirmation when copying succeeds.
• Not rely on the icon alone to communicate its purpose.

[bejignesh]

Core already does this in five places, with the accessible confirmation this ticket asks for: Site Health, application passwords, media URLs, the privacy policy text and the post permalink copy all pair ClipboardJS with wp.a11y.speak(). clipboard is registered in script-loader.php:836.

What is missing is a shared control. Each of the five hand builds its own button and its own success feedback, so a copy action on errors would be the sixth. Extracting that looks like the real work here, and #65009 is a sample of what the duplication costs.

Scope is the other open question. "Error messages" covers three separate paths: wp_admin_notice() at 174 call sites, 41 of them errors, roughly 23 places that build error markup directly, and wp_die() at 593. Which one is in scope changes the patch completely. I would start with the notice API, since it is the only single point of control.

Happy to take that on if the scope sounds right.

[jorbin]

I think both wp_admin_notice and wp_die (via ‎_default_wp_die_handler ) should be in scope for this.

Adding needs_design since I think we will want this to have a small icon.

[JeffPaul]

@jorbin do you think we can skip the needs_design bit and make use of the copy icon (​https://wphelpers.dev/icons/copy)?

[audrasjb]

That's a very nice idea.
I think we should handle this in wp_admin_notice() with a new parameter, maybe something like allow_copy? This way, the copy button would be generated automatically in the notice, and extenders could also use it if they want.

[sukhendu2002]

I checked current trunk (e5f081183d) and confirmed that the copy action is currently absent from both wp_admin_notice() and _default_wp_die_handler().

A shared control still looks like the best approach. My suggested API would be an opt-in allow_copy argument, defaulting to false, for both paths. An optional copy_text argument could provide a deliberately sanitized or structured value; otherwise, Core could copy a plain-text version of the visible message. This avoids automatically exposing tokens, personal data, WP_Error data, or environment details.

The JavaScript should also be shared, following the existing ClipboardJS plus wp.a11y.speak() pattern and handling both success and failure. One implementation detail to resolve is that standalone wp_die() pages do not necessarily load the normal admin script stack, so the shared runtime must be conditionally available there without loading the entire admin footer.

Before preparing a patch, I think we need agreement on:

• The final argument names and copied-text contract.
• Whether error codes are included automatically.
• The bundled icon and its layout alongside dismissible controls.

[micahele]

Patch: opt-in copy-to-clipboard button for wp_admin_notice() and wp_die() error messages.

[micahele]

After: admin error notice with the copy button.

[micahele]

Before: admin error notice without a copy button.

[micahele]

A standalone wp_die() error page with the copy button.

[micahele]

I gave this a first pass. The patch adds an optional copy button to both places discussed above, admin notices and wp_die() pages.

How it works:

• The button is opt in via a new allow_copy argument, so nothing changes unless a developer asks for it.
• By default it copies the plain text of the message, so no markup ends up in the clipboard. A custom string can be passed instead.
• On wp_die() pages the error code is copied along with the message when there is one.
• Copying is confirmed for screen readers on all pages, including standalone error pages that do not load the usual scripts.

Screenshots show the notice before and after, plus a standalone error page with the button. Unit tests are included.

Feedback welcome on the wording of the button and whether the copied text should also carry the error code on admin notices.