[wp-trac] [WordPress Trac] #47295: Site-Health - initial experience

WordPress Trac noreply at wordpress.org
Thu May 16 17:42:29 UTC 2019


#47295: Site-Health - initial experience
----------------------------+-----------------------------------
 Reporter:  rrrrobb         |      Owner:  (none)
     Type:  enhancement     |     Status:  new
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  Administration  |    Version:  5.2
 Severity:  normal          |   Keywords:  needs-design-feedback
  Focuses:                  |
----------------------------+-----------------------------------
 Before I get into the core purpose of this Ticket I want to first commend
 the group involved with the Site-Health project. I can understand the
 concept and its need. I also can understand the amount of work involved to
 make something like this happen. I in no way want to cast negative light
 on the work you have all put into this so far and hope for your great
 success in this endeavor. I also do not mean to come off negative, nasty,
 mean, challenging, etc, so you have no need to be defensive. This is
 totally meant to shine a light on how the current implementation can be
 interpreted.

 However I have just waisted the better part of 3 days tracking down
 answers to results in the "Critical issues" and "Recommended improvements"
 sections of the "Site-Health" area.

 I upgraded my development site to v5.2 and had no previous experience with
 the Site-Health option, plug-in, whatever.

 I made the assumption that the criteria to acquire these results was more
 advanced than it currently is. I am getting things marked as, broad term
 errors, for "Critical issues" and "Recommended improvements", which in
 fact were not errors at all.

 If you tell me that I have a "Critical issue" I assume I have an issue
 that is critical to the health and wellbeing of my installation. Why else
 would it be notated as a "Critical issue". Furthermore if you tell me that
 you have "Recommended improvements" I assume that they actually are
 improvements.

 Once again this in't meant negatively - simply the thought process as it
 was happening.

 The "errors"
 Critical issues
 The REST API encountered an error - Performance
 Your site could not complete a loopback request - Performance

 Recommended improvements
 One or more recommended modules are missing - Performance
 A scheduled event has failed - Performance
 Background updates may not be working properly - Security

 Remember I had assumed that the criteria for these "errors" was more
 advanced than it is, so I was approaching these as if I actually had a
 real issue with my settings. I was searching and researching, reading all
 sorts of bad advice and incorrect information all over the net until I
 stumbled on a post in here about this very subject. Then the light went
 on. There was nothing wrong with my install. The problem was with the
 criteria used to display the "error" messages to me. The way they were
 being displayed caused me to assume that I had some really serious issues
 going on.

 Background updates may not be working properly - Security
 there is nothing wrong, I consciously choose to update when I am ready. I
 prefer it that way. I have the ability to do so, and should. It is a
 supported and accepted practice and should not be displayed as if there is
 something wrong with doing so. If you feel it necessary to place a message
 about it then simply say "are you aware that you have auto update turned
 of? if you would like to activate it then click here and follow the
 provided instructions. Otherwise ignore this message and have a nice day.
 And don't calculate the state of this in the % of health indicator, or at
 least place a check mark box to indicate that I am aware that it is off
 and if I indicate that I am aware then it doesn't count toward the %
 indicator. Frankly I do not care one way or another about the indicator
 but it seems pointless to have it there if it isn't going to be accurate.

 A scheduled event has failed - Performance
 Yea, no kidding, I am running a development server and have something shut
 off that isn't necessary at this time. Again an are you aware of this
 message with a yes I am aware check box, and again once checked no further
 calculation to the % would be nice.

 One or more recommended modules are missing - Performance
 imagick, I am not going to say anything about this because I feel there
 has been enough discussion elsewhere on the subject. Again an are you
 aware of this message with a yes I am aware check box, and again once
 checked no further calculation to the % would be nice.

 Finally, these two
 Critical issues
 The REST API encountered an error - Performance
 Your site could not complete a loopback request - Performance
 These are the ones that caused my entire issue, ate up my time, and I
 can't wrap my mind around why they are the way they currently are.

 The information I have gathered on this states that a separate call is
 being made to check the validity of the site install.... really, on a
 development server. I get it on a live install, but on a development
 server I can't figure out why this would even be considered. There are
 many ways to know if it is development even without asking. Private
 network address assigned to protected name reservations comes to mind, or
 simply asking and another check mark, % removal, etc as before.

 I really like the concept, I hope for great things to come from it, and I
 appreciate all the time and hard work put into it. However I fear a "boy
 crying wolf" perspective may happen if it isn't managed carefully. I can
 also see the validity for the ability to turn this feature off and on as
 needed, not having it running all the time. Maybe make it a plug-in. ;)
 JK-humor, lighten up.

 Again - I mean no disrespect - there is no need to be defensive or even
 respond. After reading the message I stumbled upon I felt it necessary to
 state my experience. I am sure I am not alone, however I believe the vast
 majority will not take the time to come here and tell their story. The
 comment I read basically stated that if nothing was mentioned about this
 subject then the individual was going to assume there was no issue and
 that all further information should be placed in their own tickets. Thus I
 felt compelled to write this, because there is an issue.

 Again please do not bother to respond, I will not be checking for
 responses nor will I be making any further comment. This was simply to
 respond to the before mentioned remark.

 by the way, what % of installs is manual update? How long does it take to
 achieve enough installs to actually know how something like this is being
 received? and how often do sites skip entire versions due to frequency of
 the manual install? just pointing out reasons why in 3+ weeks ya might not
 have enough installs to make a broad sweeping assumption that there is
 nothing to see here.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/47295>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list