-
Notifications
You must be signed in to change notification settings - Fork 122
Fix #135. Add Explicit options for adding ACF Field Groups to the Schema #229
Conversation
…lowed WP convention for new code
@jasonbahl |
When I active this plugin which download from your github repo, I got this warning? Is there some problem? @rsm0128
|
@supriome You need to run |
@rsm0128 For the "GraphQL Types to show the field group on" option, I think we also need to consider interfaces. Specifically the For example, if I want a field group, maybe something like SEO Fields, to be available on all Post Types, I could apply the field group to a the ContentNode interface and would be able to query like so: {
contentNodes {
nodes {
__typename
id
acfFieldGroup {
textField
textAreaField
}
}
}
} If I were to chose an Interface, possibly the Types that implement that interface would become checked and disabled in the checkboxes: |
src/class-config.php
Outdated
'taxonomy' => $taxonomy, | ||
] | ||
); | ||
$key_prefix = 'post_type__'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a specific reason you prefixed these values?
I think it makes more sense to used the Type name from the schema directly.
[
'graphql_types_on' => [
'Post',
'Page',
'Tag',
'Category',
'User',
'Comment',
],
]
etc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Users can create custom post type or custom taxonomy with the reserved names. For example, users can't use "User" custom post type if we don't use prefix.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Types are unique in the GraphQL Schema. You cannot create a User
Post Type without giving it a unique GraphQL name.
For example, if I add the following code to register a post type with the user
GraphQL type, it won't work and there will be a debug message output:
add_action( 'init', function() {
register_post_type( 'user', [
'show_in_graphql' => true,
'graphql_single_name' => 'user',
'graphql_plural_name' => 'users',
] );
} );
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK. I'll remove the prefixes. Thanks for your detailed explanation!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any progress? Can this fix be merged into the master branch yet?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be able to group by Interface, I imagine? 🤔
I'll think on it a bit too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also grouping in the UI doesn't have to be defined by the values passed to the field group definition.
For registering ACF field groups via Code, it would be cleaner for to pass the GraphQL Types directly without having to know about extra prefixes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I used input[value^="post_type__"]
and input[value^="taxonomy__"]
selector to select all the post types and taxonomies, but if we don't use prefix, it's a bit hard to select.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rsm0128 👋
I pushed a commit with some re-factoring to the checkboxes.
This removes the need for prefixing with post_type__
and taxonomy__
and uses the GraphQL Type names directly.
I adjusted the markup to be re-usable for many interfaces, and the jQuery to also be re-usable.
Right now we have the 2 interfaces (ContentNode
and TermNode
), but we'll have at least one more, the ContentTemplate
Interface, so that ACF field groups can be assigned to Templates in the Schema as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rsm0128 I pushed one more commit with the ContentTemplate
interface added.
Now it works like so (you can see the ContentTemplate interface included now):
And I think |
@jasonbahl I added ContentNode and TermNode support for explicit options. |
@rsm0128 the screenshot for how you implemented the Interface checkbox looks nice! I like it better then the disabled idea I suggested. Good work! |
- update Docker entrypoint to download wp-graphql from WordPress.org - update test for custom fields
@jasonbahl lets get this bad boy merged! Such a big upgrade to the plugin. |
This comment has been minimized.
This comment has been minimized.
…ues instead of prefixing with `post_type__`, `taxonomy__`, etc - Update to use `graphql_types` instead of `graphql_types_on` setting name - Update Checkbox markup to be re-usable for multiple interfaces and their possible types - Update jQuery for checkbox state management to be re-usable for any Interface checkbox set
@rsm0128 @drewbaker we're getting close for sure! I pushed some commits refactoring some things with the checkboxes. I'll follow-up with more tomorrow. (I broke the tests 🤦♂️ , so I'll fix them) We're getting close to a spot where I'll be comfortable supporting this! Stoked to get this out! |
…g as context - Add ACF Options Pages to the WPGraphQL when the Schema is loading - Update code to use `graphql_types` instead of `graphql_types_on` - Update tests to use `graphql_types` instead of `graphql_types_on` - run `composer install --no-dev`
- Update default `required` value for the `graphql_field_name` rule - Updates docblocks in class-config - Updates class-config to get location rules from the location rules class - Adds new LegacyLocationRules class to help support legacy location rules (before GraphQL Schema Types were explicitly set for each field group) - Adds JS to handle required field logic for graphql_field_name - Adds tests for CommentLocation, LegacyRules, MenuItemLocation, MenuLocation, TemplateLocation and TermLocation - updates composer autoloader map
…ing field group location rules - Move GraphQL Settings into their own meta box - Register an `AcfFieldGroup` Interface - Revamp location-rules. They will now be treated as more of a first-class citizen than a legacy thing. Field Groups will still use ACF Location Rules as the first attempt to map field groups to the Schema, but still allow users to override if they choose to. - Work on JS for conditional visibility of GraphQL Settings fields - Update LocationRulesTest (instead of LegacyLocationRulesTest)
# Conflicts: # docker/app.entrypoint.sh
…ld Group page - Add Ajax callback for determining rules - Update Location Rules to check for rule conflicts, and support many edge cases, such as assigning a Field Group to a post_status - Update JS helpers for the GraphQL Field Group settings. Add conditional logic to the field that allows users to manually chose GraphQL fields or map based on location rules - Reset location rules when manual graphql type mapping is unchecked.
- add support for new location rules to map to options pages - check to see if field group is set to be manually mapped to GraphQL Types, and if so, don't use get_location_rules() to automatically map when building the Schema - Add test for ACF settings pages and ACF sub settings pages
- back out the change to remove the prefix from field groups (will be addressed later)
This PR focuses on fixing the experience of mapping ACF Field Groups to the WPGraphQL Schema.
This video walks through the update:
https://youtu.be/VvrZGrcwv0Y
closes #135