feat: support "Show Toolbar when viewing site" user setting

[blakewilson]

What does this implement/fix? Explain your changes.

This PR adds the ability to query for the "Show Toolbar when viewing site" user preference in WPGraphQL. This is particulary helpful if you have created an "admin bar" alternative on your Headless site and want it to be displayed based on this preference.

isToolbarVisible.mov

Does this close any currently open issues?

#2764

Any relevant logs, error output, GraphiQL screenshots, etc?

(If it’s long, please paste to https://ghostbin.com/ and insert the link here.)

Any other comments?

…

Where has this been tested?

Operating System: MacOS Ventura 13.1

WordPress Version: 6.1.1

Unit tests have been added.

[justlevine]

I agree this data should be exposed in core and the PR itself looks good to me (see feedback on field name).

I do worry that exposing a single user meta field without a greater strategy (e.g. #479) is going to lead to more code debt and schema breaks/deprecations, but I'm not anticipating anything specific, just recommending this be reviewed in the larger context.

[coveralls]

Coverage: 85.12% (+0.009%) from 85.112% when pulling 9835f7a on blakewilson:support-viewer-toolbar-visibility into 44fbc68 on wp-graphql:develop.

[blakewilson]

I agree this data should be exposed in core and the PR itself looks good to me (see feedback on field name).

I do worry that exposing a single user meta field without a greater strategy (e.g. #479) is going to lead to more code debt and schema breaks/deprecations, but I'm not anticipating anything specific, just recommending this be reviewed in the larger context.

I agree with you here. Is there anything you see in this PR that can address these worries?

[justlevine]

Is there anything you see in this PR that can address these worries?

@blakewilson the PR actually looks great to me, my comment was more a suggestion for @jasonbahl to do a basic gut-check before merging than anything else.

From memory (beyond skimming #479, I havnt looked through other tickets) the things I know we should keep in mind are:

• the auth layer (the field is private here ✔️)
• the field name makes semantic sense wherever it's exposed (✔️✔️)
• the default meta value ( that's good here too, but we should double check we don't need to loose-comparison to handle '0', 1 or other weird WP meta quirks around booleans)

[codeclimate]

Avoid too many return statements within this method.

[codeclimate]

Code Climate has analyzed commit 9835f7a and detected 1 issue on this pull request.

Here's the issue category breakdown:

Category	Count
Complexity	1

View more on Code Climate.

[blakewilson]

@justlevine Could you help initiate the other workflows? 🙏 Looks like linting is passing now.

[jasonbahl]

Ultimately, I'd like this to be resolved more centrally where register_user_meta could map to the WPGraphQL Schema.

That's a bigger initiative and since this has a test, we can ensure if we do tackle that initiative in the future, this continues to work as-is.