Add plugin debug information to the Site Health screen

[johnwatkins0]

This resolves #83, which describes a need to display plugin debug information on the new Site Health screen introduced to core in 5.2.

Description of the Change

It adds a new accordion drawer to the Site Health info screen that looks like this:

We do this by hooking into the new debug_information filter provided by core, adding a key for classifai, and providing a set of plugin details that would be useful for debugging purposes. This is done via a classifai_debug_information filter that can be hooked into throughout the plugin.

Alternate Designs

• The DebugInfo class provides the classifai_debug_information filter and delegates the adding of debug information to the individual features in the plugin via the filter. Alternatively, we could do all the work needed to retrieve debug information in the DebugInfo class. This might be simpler, but I liked the extensibility the filter provides.
• Currently the IBM Watson features display as a JSON encoded string. These could be broken out into their own lines. I just didn't see a clean way to do it within the limited structure of the Site Health drawer.

Benefits

Plugin users have a concrete, nontechnical step to share information needed for debugging.

Possible Drawbacks

Expecting debug information to be provided with all plugin features adds a small amount of overhead.

Verification Process

Using an up-to-date Version of WP:

1. In the admin, navigate to Tools/Site Health and switch to the "Info" tab.
2. Find and open the "ClassifAI" accordion drawer.
3. Verify that the information shown matches your environment.
4. Verify the same in a different environment with different settings, or modify your settings and re-check.

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

#83

[johnwatkins0]

Putting non-service-related classes in $this->services doesn't seem quite right, but I followed what was already there.

[ryanwelcher]

@johnwatkins0 this was a side-effect of the refactor work done to allow the plugin to support multiple services. At the time, there wasn't a need to handle non-services differently. This can probably be added now as we have both notices and debug information .

[ryanwelcher]

@johnwatkins0 as this class is abstract, it can never be instantiated directly so this stub is never called. It may make sense to mark this method as abstract as well to enforce that any providers implement this.

[ryanwelcher]

@johnwatkins0 thanks for submitting this! I've added a couple of items to the PR. I think we had an issue using the null coalescing operator at one point but we should confirm that with @helen or @jeffpaul before making any changes.

[johnwatkins0]

Thanks, @ryanwelcher ! I've pushed the following updates:

From CR

• Made the get_provider_debug_information method abstract, forcing child classes to implement it.
• In the Plugin class, we now register admin helper class instances separately from the services

Not from CR

Made booleans that show in the debug information more human-friendly -- "yes"/"no" instead of "1"/empty.

Let me know if you have questions or more suggestions.

[helen]

I think what I'd like to see added here is the results of the most recent request, maybe to each provider. Could help a lot with troubleshooting. So store those (request response I guess?) in options somewhere and translate them into human-ish terms maybe.

[jeffpaul]

I'll add a separate issue to include the details on services within Site Health, that way this PR can land in 1.4 and we can enhance it in 1.5

[helen]

I made a couple output formatting tweaks but otherwise looks good to me. I didn't look too closely at the internationalization aspect, though given lack of actual localizations at the moment I will worry about that later.

@johnwatkins0 Next considerations for Site Health: storing and displaying debug info for the last request (or requests?) for each provider, and considering whether it makes sense to make the setup status of the plugin a part of the health tests. It may not, but we should at least consider it.