Add: Debug info to Site Health Info screen

[dinhtungdu]

Description of the Change

Add debug information of Distributor to Site Health Info screen.

Alternate Designs

n/a

Benefits

Adding Distributor-specific debug info there can help solve issues that come to us from support forums, GitHub, email, etc. as users can copy this info and send to us for faster assistance with issues.

Possible Drawbacks

n/a

Verification Process

Go to Tools > Site Health > Info and check the Distributor section.

Checklist:

• I have read the CONTRIBUTING document.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my change.
• All new and existing tests passed.

Applicable Issues

Relates to #407

Changelog Entry

Added: Site Health debug information.

[dinhtungdu]

We have duplicated code here (and the next function) and in the pull-ui.php. I'm considering splitting it and move the logic to utils.php.

[jeffpaul]

@dinhtungdu some feedback/question from my testing:

1. Change Valid license to Valid registration.
2. Change Email to Registration email.
3. Ensure Settings notes details for Override Author Byline and Media Handling.
4. Is there any better formatting we can apply to the Internal Connections and External Connections sections besides the current blob of data?

[dinhtungdu]

@jeffpaul I fixed 1 and 2, 4.
For 3, do you mean the field title and description?

[jeffpaul]

@dinhtungdu yes, we'll want to log how users have those settings configured.

[dinhtungdu]

@jeffpaul thanks for the head up, this PR is ready for review again

[jeffpaul]

@dinhtungdu 1-3 look good. For 4, can we call out the Title, URL, Status, Auth method, Username, Roles Allowed to Push labels and their associated value for each External Connection plus the additional data you're capturing? I still need to test on a multisite to see how things compare for Internal Connections.

[dinhtungdu]

@jeffpaul, Thanks for the feedback, I updated both internal and external connections data, see https://prnt.sc/rkhnbq.

Please note that you need to run npm run build to build the new stylesheet for Site info screen.

[johnwatkins0]

A few very minor comments, but otherwise code looks good and it's working well locally.

[johnwatkins0]

Looks great!

[jeffpaul]

@dinhtungdu are we able to detect the Distributor version for the External Connections and report that for those in the respective section?

[dinhtungdu]

@jeffpaul With current codebase, no, but we can with a custom public REST API endpoint.

[jeffpaul]

While it would be nice to be able to confirm all Distributor versions are current/equal, I'm not sure whether the value there is high enough to warrant a public API... @dkotter what's your take?

[dinhtungdu]

@jeffpaul That's my concern, too.

[dkotter]

@jeffpaul @dinhtungdu This is something that was added as part of the Auth Setup Wizard PR (see https://github.com/10up/distributor/pull/368/files#diff-923616c19cf0f150ddc8b464ca53da19R257). So if that stays in (and we get that merged at some point) we will be able to utilize that here as well.

[jeffpaul]

@dinhtungdu let's wait on this PR until #368 gets merged and you can build on top of the API then.

[dinhtungdu]

Added version to debug info. But the current solution may not scale if the site has many connections.

I thought about caching or saving version info to dt_external_connections meta as well, but if we do so, we can't ensure that the versions in debug info are up-to-date.

What do you think @dkotter ?

[jeffpaul]

Unless we have alternatives that clearly scale better, I'd say we get this merged in to benefit anyone triaging Distributor setups and then work to also include the Distributor version as a column in the External Connections list table (as previously suggested by @dinhtungdu).

[dkotter]

@dinhtungdu @jeffpaul Yeah, not sure there's a great answer here. Ideally, this health info screen isn't accessed very often, so not sure how much of a concern this will be in reality. But for sites that have hundreds of external connections, this will add a significant overhead to that page.

We could take the same approach we did for the Push UI, where we don't load anything on page load, only when the menu is hovered into. So instead of querying for the version information when the health info screen is loaded, we do it after page load, so it doesn't hurt performance.

Not sure if that's worth the effort here or not but caching won't help a ton, as the data won't be cached until the page is visited (and again, hopefully this page isn't visited often) and as mentioned, saving to meta can become out-of-date.

[dinhtungdu]

@jeffpaul After considering some options, I incline to merge this PR. I added a filter to disable the debug info as well.