[wp-trac] [WordPress Trac] #46707: Site health: notify the user while gathering site data

[WordPress Trac]

#46707: Site health: notify the user while gathering site data
-------------------------------------------------+-------------------------
 Reporter:  azaozz                               |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  5.2
Component:  Administration                       |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  site-health has-patch needs-testing  |     Focuses:  ui,
                                                 |  performance
-------------------------------------------------+-------------------------

Comment (by afercia):

 From an UI perspective, [attachment:"46707.1.diff"] looks good to me.
 However, as @xkon noticed, I get the same wrong total size:
 plugins+themes+uploads are added to the WP size (which already includes
 them). [attachment:"46707.2.diff"] seems to fix it but I'm not sure about
 the original intent of the `$is_subdir` check.

 In a conversation with @xkon we've also explored a couple more things:

 1
 If `recurse_dirsize()` was able to accept ''multiple'' directories to
 exclude, performance could be improved. Right now, the size calculation on
 the plugins, themes, and uploads directories runs twice:
 - as part of the WP size calculation
 - as individual size calculation for each of them
 The former is unnecessary because there's already the need to run the
 calculation on plugins, themes, and uploads individually. So it could be:
 - run the individual plugins, themes, and uploads calculations
 - run the WP size calculation excluding plugins, themes, and uploads (so
 this would be much faster)
 - just sum 1 to 2 to get the actual WP size

 2
 WordPress uses some constants to define KB, MB, GB, etc. and they're based
 on the `1024` binary value. Worth noting `size_format()` uses these
 constants. This used to be the industry standard. However, in recent years
 a new IEC-SI standard has been adopted by various operating systems and
 it's based on a value of `1000`. As far as I know, Mac OS starting from
 version 10.6 and Ubuntu starting from version 10.10 switched to `1000`. I
 think Windows still uses `1024`.

 This doesn't matter so much when testing locally: in this case we should
 just be aware the values reported by Site Health won't match the ones
 reported by macOS and various Linux distros. However, it does matter when
 it comes to hosting.

 WordPress sites are hosted somewhere and it's very likely the vast
 majority of the hosting companies use some flavours of Linux. I guess this
 should be verified on a per-hosting company basis, but it's very likely
 their OSes use the new `1000` value. Site Health is primarily meant to
 collect data for debugging and the sizes data will very likely mismatch
 with the sizes data on the hosting side.

 To give you an idea, here's what I get testing on macOS (reduced example
 for brevity): the data in the third column is the size reported by the
 macOS Finder:
 {{{
 Default:

 Uploads Directory Size    96.22 MB     100.889.632 bytes
 Themes Directory Size     9.00 MB      9.442.020 bytes
 Plugins Directory Size    36.29 MB     38.054.335 bytes

 Changing the WP constants to `1000`:

 Uploads Directory Size    100.89 MB    100.889.632 bytes
 Themes Directory Size     9.44 MB      9.442.020 bytes
 Plugins Directory Size    38.05 MB     38.054.335 bytes
 }}}

 As you can see, they match only after changing the related WP constants to
 `1000`. At this point, I'm not sure what is the future of these constants
 defined in `wp_initial_constants()` :) That's probably something that
 should be discussed and addressed separately.

 For now, one possible option would be to report these sizes data in
 `bytes`: after all these are technical data meant to be reported to a
 support service or tech-savvy team and don't necessarily need to be in a
 "human readable" format.

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