Allow nested arrays to be displayed in site health.

[spacedmonkey]

Site health info, if the value is an array, it formats this as a ul / li list. This is nice, but if in the array, are other nested arrays, these are not rendered as expects. This screen should be changed to check if the value is an array and to iterate through it.

[Clorith]

I agree, we need to have some better support here, I'm curious what would be the preferred way of doing that though.

What would make the most sense, there's two instant thoughts that come to mind, as I see it:

1. If it's non-scalar (a quick is_scalar check), "dump" it using JSON encoding, PHP serialization, or the "prettier" option of a pre wrapped print_r.
2. If it's an array, allow for nested loops.

Option 2 means we need to perhaps be a bit strict on what is allowed to be included, so you can only go X tiers deep at max, to keep it legible.

Option 1 is the one I'm leaning towards, although it may not _always_ look as pretty to the naked eye, it does mean those adding information to the debug section can include "anything" they feel is relevant. It would also allow for any non-scalar value to be output (for that weird edge case where someone has decided to make the data an object instead of an array, unlikely, but if they want to quickly push the data into some tool on their end from the debug output, that would likely make this easier if for example JSON encoding were used?)

[Clorith]

Been looking at this a bit.

The debug data is fine, we can throw on a maybe_serialize() on the value there, and that should take care of it self that way, I think that's a good approach for that particular bit of this. I know I mentioned JSON earlier, but if an object is passed I'm not confident converting it to JSON may not lose something in the process?

My main hangup right now is deciding on the best visual representation for the "human readable" form.

To provide max flexibility, it would need to be a <pre> print_r( $value ) </pre> (pseudo-code there), but this outputs things like "Array:", which may not mean much to end users.

On the other hand, we can't reasonably provide an infinitely looping set of nested arrays in my opinion. I do know that there are plugins that have voiced an interest in providing at least 2 levels deep though, would that be a reasonable limitation to upgrade to?