Site Health: Add ability to ignore issues and place in a ignored issues list hidden like passed tests

[garrett-eclipse]

Hello,

The 'Background updates are not working as expected' flags on the development environment as it uses .svn and gives the;
The folder ... was detected as being under version control (.svn).

It would be nice if these and possibly the recommended improvements could be 'ignored' in that they're removed from the issues and improvements lists and placed in a Ignored tests section hidden away like the Passed tests.

This would allow admins who've consciously made a decision such as using a version control system to downgrade them so when other admins or their client view the status they're not alarmed and questioning.

I also feel if the test produces a different result I would think the issue could resurface and become unignored.

This would also allow admins to keep the Site Health clean and when they return make it easier to identify new issues. When admins have mentally chosen to ignore some tests and they come back it's easy to overlook changes or new issues.

Thank you for the consideration.

[garrett-eclipse]

Example of an issue an admin/dev would want to ignore

[Clorith]

Site owners already have the ability to modify which tests are run for scenarios like this using the test filters, so I'm not sure how viable this would be.

You also run the risk of users, agencies, and so on just hitting "ignore" on everything to give an impression of a good setup (yeah, they can also filter it, but that's a bit more of an aggressive step than just hitting a button).

[garrett-eclipse]

Thanks Clorith:

Site owners already have the ability to modify which tests are run for scenarios like this using the test filters, so I'm not sure how viable this would be.

You also run the risk of users, agencies, and so on just hitting "ignore" on everything to give an impression of a good setup (yeah, they can also filter it, but that's a bit more of an aggressive step than just hitting a button).

I appreciate the feedback @Clorith. I definitely agree the filters are a very aggressive step and I would like to avoid them.

I would feel I'd be doing my client(s) a disservice if I were to completely disable tests. With sites evolving, redesigning and changing hands, hosts and locations their environments often change drastically. With the ignore option I'm proposing when a test failure changes it would resurface from it's ignored status. This is a little less aggressive than fully disabling the tests.

For example; Disabling the background updates test because we're managing client updates, and then have them move away to an unmanaged setup. If they are no longer maintained via .svn but their issue changes to files aren't writable they would be oblivious of this issue if the test is filtered.

IMHO using the filter can be a bit dishonest while an ignore still provides exposure to the test and indicates a conscious choice was made there.

Another approach over would be have the ignore be a user_meta flag to avoid any concern of hiding tests from other users. This cleans up the individuals' view which was my original concern of losing 'new' issues among all the old tests you've mentally ignored. While still presenting all evidence to any other admin/client.

Let me know what you think,
Cheers

[Clorith]

You have some good points, but I'm still not convinced about the need, or of its suitability, for what is currently in scope here.

I would recommend creating a ticket on the ​Health Check GitHub repository for this for further discussion/experimentation at this time, as it will require a fair bit of considerations before it should be considered.

[garrett-eclipse]

Thanks @Clorith I appreciate the pointer there, I've had a chance to move this into 'health-check' here;
​https://github.com/WordPress/health-check/issues/326

[garrett-eclipse]

Related: #47982

[Clorith]

I've been thinking about this, and I don't think that hiding tests is in scope for core.

That said, with the introduction of the filters in #47864 a plugin could implement something along these lines, as well as the various plugins already out there for hiding tests.

[garrett-eclipse]

Thanks for revisiting @Clorith that makes sense and sounds about right with this being more plugin territory than core. Cheers