Allow html on site health titles and description

[juliobox]

Hello there,

In /wp-admin/site-health-info.php#L115 we have this:

<?php echo esc_html( $details['label'] ); ?>

So we don't allow HTML content ? why!?
I propose the usage of wp_kses_* to allow clean html content.

Also line#141 we have this:

printf( '<p>%s</p>', $details['description'] );

We clearly allow any html, so I propose to sanitize using wp_kses_* too, we don't want embed/iframe/script here right?

Thank you for your feedback.

[audrasjb]

Related: #46878

[azaozz]

Couple of things:

• KSES is not intended (not a good way) to sanitize things on displaying. It is a heavy/slow filtering of HTML tags and attributes best suited for saving to the DB.
• What are the "user cases" for allowing HTML in item titles and collected data? I.e. how would that improve the user experience? :)

As far as I see it may be helpful to add a link to the "explanations" of some of the results, however keep in mind these will have to be translated and the link would (ideally) point to a "get more info" web page in the same language.

Seems displaying only "basic" info there and leaving it to the user to decide if they want to know more, and providing them with enough to "get them started" is a pretty good UX/workflow. There is a lot of (new/unfamiliar) info on that screen, we don't want to overwhelm them right from the start :)

Also, no HTML tags should be in the info that is for copying.

[juliobox]

Hey @azaozz !
Thanks for your interest and point of view :bow:, to answer to "how would that improve the user experience? :)"
Well, as a user I would rather prefer to have a quick view of all this stuff without having to (1) click on each to get more info, and (2) click on a link get … more info!
I agree to stay basic, however, too basic means I'll force the user to open the scan to really know what is the real issue.
For my case, nothing will be translated since all is already done, I'm just placing my security scan in this page, with is design to receive this kind of info.
Some examples of what I actually have:
​https://www.dropbox.com/s/2uglxr7yiis1e5l/Capture%20d%27%C3%A9cran%202019-05-11%2000.13.51.png?dl=0
And what I would like to have:
​https://www.dropbox.com/s/0w4mrvryzpmlk37/Capture%20d%27%C3%A9cran%202019-05-11%2000.24.33.png?dl=0
Also a screenshot when open:
​https://www.dropbox.com/s/dvm2gfnbfivm2z8/Capture%20d%27%C3%A9cran%202019-05-11%2000.25.30.png?dl=0
I explain what is this scan, then explain more deeply + 1 link to the plugin page related to this scan + 1 link to my external documentation on that scan.

edit: quick test with switching infos:
​https://www.dropbox.com/s/5y7to6hzf0teiyh/Capture%20d%27%C3%A9cran%202019-05-11%2000.29.51.png?dl=0
Is this what you think is the best ux practice?

voilà !

[palmiak]

I fully understand @juliobox point of view. Using some html tags can improve the readability of the titles and his screenshots has shown it.

I see three ways to go:

• we leave as it is
• we remove the esc_html just as it's made in with $details['description']
• we remove the esc_html and use strip_tags with a list of tags we can use (everything but not style or script tags. Also we can use it for $details['description'] to keep it the same as the title.

I would go with the third version - it's adds some sanitation, but also gives a chance to use extra tags.

[desrosj]

Moving Site Health tickets into their lovely new home, the Site Health component.

[Clorith]

I'm not sure if allowing markup in the title section is a good solution here, I'm not seeing any good explanation of what problem it solves, if anything it enables overly complex titles that (in my opinion) defeat the purpose of an overview screen.

A title should be short, concise and entice the user to look further for more details (again, my opinion).

[audrasjb]

While I agree that titles should be short and concise, I can see a couple edge cases where allowing some HTML tags would prove to be useful:

• Using <code> tags could be useful for function names and other technical stuff.
• Potential language changes could use a <span lang="en"> tag for better accessibility.

However, I'm frankly not sure such edge cases are the main reason why people want to use html markup in Site Health titles, and I honestly feel a bit concerned about plugin authors using any type of html markup and styles here :)