WordPress.org

Make WordPress Core

Opened 18 months ago

Closed 18 months ago

Last modified 4 months ago

#46647 closed defect (bug) (fixed)

Site Health: Improve the "Copy to Clipboard" button

Reported by: pento Owned by: pento
Milestone: 5.2 Priority: normal
Severity: normal Version:
Component: Administration Keywords: has-screenshots
Focuses: javascript Cc:

Description

Splitting this off from #46573.

The current method for copying the debug report to the clipboard involves having a hidden <textarea>, but this shows up in screen readers (ref) and can't be reliably hidden (ref).

Per design review from @hedgefield:

To the point of being able to review your copied text - is that really necessary? All the info is technically present on the page, and after copying you can paste it somewhere and then review if you want to remove something from it. I don't think many people scroll through the whole thing to see what all is in there before they copy it, but then again that's only my assumption. I just feel like we are making it harder than it needs to be. The main usecase in my mind is a support engineer asks you to copy that infodump, you want to give someone the quickest way to do so. Feel free to correct me if I'm wrong in that though.

I agree with this assessment. The person using this tool has the ability to review the content being copied in the report itself. The formatting of what's copied is not really relevant, as the copy event can include multiple data types. We're currently only including plain text, but this could also include HTML, Markdown, or even blocks.

Attachments (2)

46647.diff (8.6 KB) - added by pento 18 months ago.
copy-button.png (243.9 KB) - added by pento 18 months ago.

Download all attachments as: .zip

Change History (12)

@pento
18 months ago

@pento
18 months ago

#1 @pento
18 months ago

  • Keywords has-patch has-screenshots needs-design-feedback added

In 46647.diff:

  • Introduce clipboard.js, which the block editor also uses for managing cross-browser clipboard handling.
  • Remove the hidden <textarea> elements.
  • Change the copy button label to "Copy report to clipboard".
  • Rename WP_Debug_Data::textarea_format() to WP_Debug_Data::format(), and make it return the formatted data, instead of printing it.
  • Cleaned up the class names in the copy button section.

@hedgefield: Just looking at the clipboard button section, what are your thoughts on how it's implemented? In particular, one of the concerns is that it isn't clear what's being copied: does the button label help with that, or can we point it out in a clearer way?

#2 @afercia
18 months ago

In the screenshot above, I see when "Hello Dolly" is active, the main heading is misplaced. Will create a ticket...

#3 @hedgefield
18 months ago

  • Keywords needs-design-feedback removed

@pento This implementation looks great, thanks for spearheading.

I think we can improve the button UX by tweaking the label and also the copy above it. The copy now refers to the export function, but not what the page is for. Here's my suggestion:

This page can show you every detail about the configuration of your WordPress website. If we see anything here that could be improved, we will let you know on the Site Status page.

If you want to export a handy list of all the information on this page, you can use the button below to copy it to the clipboard. You can then paste it in a text file and save it to your harddrive, or paste it in an email exchange with a support engineer or theme/plugin developer for example.

[Copy site info to clipboard]

#4 @pento
18 months ago

Copy looks good, thank you for the review, @hedgefield!

#5 @pento
18 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 45044:

Site Health: Improve the "Copy to clipboard" button.

The previous method for copying the debug report to the clipboard involved having a hidden <textarea>, but this shows up in screen readers and can't be reliably hidden.

To work around this, the button now uses the clipboard.js library, which automatically handles browser differences in the Clipboard API, and can load the text to copy from a data- attribute on the button.

Props pento, hedgefield, afercia.
Fixes #46647.

#6 @afercia
18 months ago

  • Keywords needs-patch added; has-patch removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

Just noticed grunt jshint:core fails (at least for me) because ClipboardJS is undefined:

Running "jshint:core" (jshint) task

   src/js/_enqueues/admin/site-health.js
     13 |    var clipboard = new ClipboardJS( '.site-health-copy-buttons .copy-button' );
                                 ^ 'ClipboardJS' is not defined.

#7 @afercia
18 months ago

  • Focuses javascript added; accessibility removed

#8 @SergeyBiryukov
18 months ago

In 45055:

Site Health: Declare ClipboardJS global to fix JSHint issue.

See #46647.

#9 @SergeyBiryukov
18 months ago

  • Keywords needs-patch removed
  • Resolution set to fixed
  • Status changed from reopened to closed

#10 @afercia
4 months ago

For history: worth noting that also ClipboardJS uses a hidden textarea. The textarea is injected in the DOM on the first Copy action and then it stays there in the DOM, producing this issue again. The textarea can be removed on the Copy success callback but it requires some work. See #50322.

Note: See TracTickets for help on using tickets.