Skip to content
This repository has been archived by the owner on Jul 23, 2024. It is now read-only.

Fix #135. Add Explicit options for adding ACF Field Groups to the Schema #229

Merged
merged 24 commits into from
Apr 20, 2021

Conversation

rsm0128
Copy link
Contributor

@rsm0128 rsm0128 commented Mar 15, 2021

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

@rsm0128
Copy link
Contributor Author

rsm0128 commented Mar 15, 2021

@jasonbahl
I added a unit test for the explicit options as we discussed

@supriome
Copy link

When I active this plugin which download from your github repo, I got this warning? Is there some problem? @rsm0128

Warning: require(/Users/suprio/react/gatsby-wordpress/src/wp-content/plugins/wp-graphql-acf-bugfix-135/vendor/composer/platform_check.php): failed to open stream: No such file or directory in /Users/suprio/react/gatsby-wordpress/src/wp-content/plugins/wp-graphql-acf-bugfix-135/vendor/composer/autoload_real.php on line 25

@rsm0128
Copy link
Contributor Author

rsm0128 commented Mar 19, 2021

@supriome You need to run composer install.

@jasonbahl
Copy link
Contributor

@rsm0128 For the "GraphQL Types to show the field group on" option, I think we also need to consider interfaces.

Specifically the ContentNode and TermNode interfaces.

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:

Screen Shot 2021-03-19 at 11 23 34 AM

'taxonomy' => $taxonomy,
]
);
$key_prefix = 'post_type__';
Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor

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',
	] );

} );

Screen Shot 2021-03-20 at 8 05 58 AM

Copy link
Contributor Author

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!

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?

Copy link
Contributor

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

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor

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):

acf-location-checkboxes

tests/wpunit/PostObjectFieldsTest.php Outdated Show resolved Hide resolved
@rsm0128
Copy link
Contributor Author

rsm0128 commented Mar 20, 2021

And I think \vendor\composer\platform_check.php should be git ignored or be added to the repo. If I run composer install the file marked as an untracked file.

@rsm0128
Copy link
Contributor Author

rsm0128 commented Mar 20, 2021

@jasonbahl I added ContentNode and TermNode support for explicit options.
Instead of disabling Post Type Checkboxes when ContentNode Checkbox is checked, I implemented it in the same way with Check All button. Please check below screenshot.
explicit-options

@jasonbahl
Copy link
Contributor

@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
@drewbaker
Copy link

@jasonbahl lets get this bad boy merged! Such a big upgrade to the plugin.

@supriome

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
@jasonbahl
Copy link
Contributor

@jasonbahl lets get this bad boy merged! Such a big upgrade to the plugin.

@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!

@jasonbahl jasonbahl self-assigned this Mar 31, 2021
…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`
src/class-config.php Outdated Show resolved Hide resolved
jasonbahl added 10 commits April 6, 2021 13:39
- 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)
…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)
@jasonbahl jasonbahl merged commit 3cb2244 into wp-graphql:develop Apr 20, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add Explicit options for adding ACF Field Groups to the Schema
4 participants