[wp-trac] [WordPress Trac] #57347: Site health reporting issues that aren't actually problems.

[WordPress Trac]

#57347: Site health reporting issues that aren't actually problems.
-------------------------+---------------------
 Reporter:  tcarmen      |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:
Component:  Site Health  |     Version:  5.3
 Severity:  normal       |  Resolution:
 Keywords:  close        |     Focuses:
-------------------------+---------------------
Changes (by Clorith):

 * keywords:   => close
 * version:   => 5.3
 * type:  defect (bug) => enhancement
 * milestone:  Awaiting Review =>


Comment:

 Hi there, and welcome to the WordPress bug and enhancement tracker; trac.

 It sounds like you have some feedback about various tests performed by the
 Site Health component, I would suggest making separate tickets for each
 issue, and marking them as enhancements, as they stand they behave as
 intended, and are not causing any bug-like behavior.

 There are various plugins that will allow you to control what tests run
 and are displayed (or, if you like to do things on your own, filters in
 place to let you control which tests run as well), but there are no
 immediate plans for WordPress core to include such a functionality, as it
 would be too easy to just turn off everything, when the intent is the
 better good of all.

 Since this is not truly a bug, but multiple feedbacks in one, I've gone
 and changed it's status to an enhancement, but I've also added the `close`
 keyword, as there are not (at this time) any clear reason to change any of
 the fields mentioned. This is just a keyword though, and does not actually
 close the ticket (even though discussion can continue even in a closed
 ticket).

 To keep the ball rolling, I'll give some feedback on the tests you did
 mention:

 **Having a default theme available**
 I guess "security" is a bit of an obscure label here, but it prevents your
 sites back-end form becoming inaccessible. If a fatal error should be
 introduced from your theme, and you use the built in fatal error handler
 in WordPress, a default theme is required to be able to load up wp-admin
 and perform actions to remedy the situation for non-technical users, as
 WordPress core will fall back to a default theme if a valid theme is not
 used.

 **You should use a persistent object cache**
 Generally good advice in the first place, as it reduces the need for
 repeated traffic to databases, and database processing. This can be seen
 in relation to both sustainability and performance, so it is a good
 recommendation in general.

 This is also a conditional check, so your site need to meet certain
 criteria before the impact is noticeable enough to receive this
 recommendation.

 **Page cache is not detected but the server response time is OK**
 This is another one that is good advice, although your page may load
 quickly, there is still processing done for every request. A static cache,
 or leaning on a browsers ability to keep a local copy of a page to reduce
 the request load on a website will speed up the navigation of your site,
 and again falls within both the performance and sustainability focuses, as
 the less processing needed, the better it is for the general environment.


 Perhaps the actual outcome of this ticket should be to introduce a
 `sustainability` classification for the built in checks that some of these
 fall under?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/57347#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform