feat: add core user admin preferences fields to User type#3551
Conversation
This adds the following fields to the User type that were previously missing from the core WordPress user meta: - adminColor: The admin color scheme preference (fresh, midnight, etc.) - hasRichEditingEnabled: Whether the visual editor is enabled - hasSyntaxHighlightingEnabled: Whether code syntax highlighting is enabled - hasCommentShortcutsEnabled: Whether comment moderation shortcuts are enabled These fields follow the declarative naming convention suggested in wp-graphql#479. Closes wp-graphql#479
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #3551 +/- ##
=============================================
+ Coverage 83.63% 83.65% +0.02%
- Complexity 4209 4216 +7
=============================================
Files 217 217
Lines 18756 18802 +46
=============================================
+ Hits 15686 15729 +43
- Misses 3070 3073 +3
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
…port) - add more edge case tests
jasonbahl
left a comment
There was a problem hiding this comment.
Thanks for the PR!
It addresses the core issue described in #479 and adds the core user admin preference fields to the User type.
Similar to our discussion about options, I'd love at some point to have a more formal way to map registered user options to the schema more programmatically (i.e. when a plugin adds fields to the user profile, I'd love for those fields to automatically map to the schema), but until we spend the time to come up with a centralized registry/map, this is a good step.
I like that you followed the existing patterns using the Model layer and added tests! 🙌
I made a few changes, but wanted to see what you think:
-
Switched from
get_user_meta()toget_user_option()for all four fields:
Better alignment with WordPress core (especially multisite)
get_user_option()handles site-specific user options correctly -
Updated default handling since
get_user_option()returns false when not set -
Added edge case tests:
testUserAdminPreferencesExplicitFalseValues(): Verifies explicit 'false' string values are handled correctlytestUserAdminPreferencesFieldVisibility(): Tests visibility rules across different user roles (admin, subscriber, public)
-
Updated existing tests to use
update_user_option()for consistency with the new implementation
Note: Mutation support for these fields (mentioned in the original issue) can be tracked in a follow-up issue.
There was a problem hiding this comment.
Really appreicate the thorugh review and improvments, Jason — super helpful. The switch to get_user_option() totally makes sense, I def didnt think thru multisite behaviour properly there.
And the edge case tests around explicit 'false' strings + cross-role visibility are spot on — exactly the kinda coverage I should of had from the start. Good lesson learned.
I’ll open a follow up issue for mutation support. Also the idea of a centralized registry mapping user options to the schema is really intresting — feels like a nice clean way for plugins to expose user profile fields automatically. Happy to take a crack at an RFC for that if thats somthing you’d wanna see.
Addresses Issue #479