Site Health: Error icon missing due to missing dashicons class

[valani9099]

Tested on WordPress 7.0-RC2, the error icon is not displayed in:

Tools → Site Health → Status

Issue

The error indicator span is missing the required dashicons class.

Current markup:
<span class="error"></span>

Expected markup:
<span class="error dashicons"></span>

Because of the missing dashicons class, the icon is not rendered.

Steps to Reproduce

1. Install WordPress 7.0-RC2
2. Go to Tools → Site Health → Status
3. Trigger an error (e.g., block external requests or simulate failure)
4. Observe missing icon next to the error message

Expected Behavior

The error icon (dashicon) should be visible.

Actual Behavior

No icon is displayed.

Proposed Fix

Add the dashicons class to the error span element.

Additional Notes

I have verified that adding the dashicons class fixes the issue.

Screenshots attached:

• Before fix (icon missing)
• After fix (icon visible)

[valani9099]

Before fix – Site Health error icon missing in WordPress 7.0-RC2 admin panel

[valani9099]

After fix – Site Health error icon visible after adding dashicons class

[wildworks]

Thanks for the report.

Please note that this issue did not newly arise in 7.0.

Also, if someone wishes to test this problem, you can intentionally cause an error with code like the following:

add_filter( 'pre_http_request', function( $response, $parsed_args, $url ) {
	if ( false !== strpos( $url, 'api.wordpress.org' ) ) {
		return new WP_Error( 'http_request_failed', 'Intentional failure for testing.' );
	}
	return $response;
}, 10, 3 );

[sabernhardt]

[45309] removed lines of CSS in favor of adding the dashicons class, and it missed at least this one message.

[valani9099]

Attaching patch for missing dashicons class on error span in Site Health status screen. Verified fix manually. Consistent with changes from #45309.

## Problem
Error icon not showing in Tools → Site Health → Status
because dashicons class is missing from error span.

## Fix
Added missing dashicons class to the error span element.
Missed during cleanup in #45309.

## Testing
add_filter( 'pre_http_request', function( $response, $parsed_args, $url ) {

if ( false !== strpos( $url, 'api.wordpress.org' ) ) {

return new WP_Error( 'http_request_failed', 'Intentional failure.' );

}
return $response;

}, 10, 3 );

Then go to Tools → Site Health → Status and verify icon is visible.

Trac ticket: [](https://core.trac.wordpress.org/ticket/65014)

## Use of AI Tools

[valani9099]

​https://github.com/WordPress/wordpress-develop/pull/11440

Patch attached and PR created for review.

This restores the missing dashicons class for the error icon in the Site Health screen.

As noted in changeset [45309], CSS was removed in favor of dashicons, but this instance was missed.

Tested using the pre_http_request filter method to simulate failure, and confirmed the icon now displays correctly.

[wildworks]

​https://github.com/WordPress/wordpress-develop/pull/11440 looks good to me.

However, due to the coordination with the 7.0 release, it would be best not to commit to trunk yet.

​https://make.wordpress.org/core/2026/04/02/the-path-forward-for-wordpress-7-0/#:~:text=trunk%20is%20closed%20to%20commits%20for%20the%207.1%20release%20until%20further%20notice.

[valani9099]

Thank you @wildworks for reviewing!
I understand the timing with the 7.0 release coordination. I'll wait for trunk to reopen and am happy to assist with any further testing needed.

Thanks @sabernhardt! Updated the class order to put dashicons first for consistency as suggested.

[valani9099]

Updated patch v2 — moved dashicons class before error class for consistency per @sabernhardt suggestion.

[wildworks]

@valani9099 Thanks for the update.

P.S. If you have already submitted a pull request, you do not need to submit a separate patch.

[valani9099]

Thank you for the clarification @wildworks! Sorry for the extra patch — I wasn't aware the PR was sufficient on its own. I've re-requested reviews on the PR from @sabernhardt and @t-hamano. I'll keep this in mind for future contributions and rely only on the PR going forward!

@Webizito, As mentioned in ​this comment, it is not necessary to regularly merge trnk into this PR.

[valani9099]

Thank you for the guidance @wildworks! Understood — I will stop merging trunk into the PR and leave it as is.

Just curious — since WordPress 7.0 release seems to be delayed, is there any chance this fix could still be included in 7.0, or will it be targeted for 7.1 once trunk reopens? Happy to wait and assist with any further testing if needed!

[wildworks]

Replying to valani9099:

Just curious — since WordPress 7.0 release seems to be delayed, is there any chance this fix could still be included in 7.0, or will it be targeted for 7.1 once trunk reopens? Happy to wait and assist with any further testing if needed!

This bug is not new to 7.0, so it probably doesn't need to be included.

[valani9099]

Thank you for the clarification @wildworks!