You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 23, 2024. It is now read-only.
Despite the growing popularity, it has many issues that have been ignored for far too long.
We're changing that.
WPGraphQL for ACF is getting some new life breathed into it.
Over the coming weeks and months, we'll be working through some major changes and refactors on the path to a formal v1.0 of WPGraphQL for ACF.
Breaking Changes
Before getting into the details of the release, I want to be clear up front that there will be many breaking changes coming in order to get to the v1.0.
We'll be making many breaking releases to this plugin on the path to v1.0, so pay close attention to the Release Notes of each release as you upgrade.
Sometimes, a breaking change for one user might not be a breaking change for another user. Make sure to follow the releases closely, and we recommend testing updates in staging environments before you upgrade.
The Path to 1.0
Below are some of the high-level areas we will be addressing on the road to a 1.0 release:
Significant updates to Location Rules
Better support for re-usable fragments
Better DataLoader Support
Better Connection Support
Better support for ACF Field settings
Significant Updates to Location Rules
Location Rules in this plugin are simply broken.
Advanced Custom Fields provides location rules that allow you to configure where in the WordPress admin content creators can interact with ACF Field Groups.
These location rules were designed with the context of administration screens in mind, not a GraphQL Schema.
A GraphQL Schema needs to know what's possible for a Type of content, where the location rules apply to a specific piece of content.
For example, the Location Rules above state that the field group should show on a specific taxonomy, for a specific user role.
A GraphQL Schema doesn't know who the user is until the query is executed. So the GraphQL Schema needs to show that the field group is possible to be asked for, but depending on your user role you may or may not get data in response.
Currently the WPGraphQL for ACF location rules attempt to translate the location rules and apply them to the Schema, and in many cases this leads to cases where the field group simply doesn't show in the Schema at all, or you have to add ACF Field groups to locations that don't make sense for the content creators.
Now, instead of WPGraphQL for ACF attempting to infer the ACF Location rules and apply them to the GraphQL Schema, there will be a new UI where the ACF Field Group can be added to specific GraphQL Types in the Schema.
The ACF Location rules for where the field group should show in the Admin will remain the same, but a new setting will be exposed to configure where in the GraphQL Schema your field group should show.
Here's a taste of what this new setting field looks like:
And thanks to @drewbaker and @rsm0128, this is already getting close to complete in #135. 👏
This will be a breaking change. We're working to make sure the friction is reduced to a minimum, but most sites will need to re-configure their ACF Field groups when this is released. But we think you'll enjoy this quite a bit.
Better Support for Re-Usable Fragments
Currently the WPGraphQL Schema adds nested Types to field Groups with a prefix of the Root Type the field group belongs to.
This makes it impossible to re-use fragments across Types.
If you've ever tried to query Flex Fields across different Post Types, you know the pain I'm speaking of.
This is changing!
This too, will be a breaking change (that we can all rejoice about) but breaking nonetheless. So, when this rolls out, it will require changes to your client applications.
So be sure to plan time for this release when it comes.
Better DataLoader Support
There are various places in this plugin that make direct queries for related objects, and do not make use of the WPGraphQL DataLoader pattern.
We'll be updating various fields to make use of the DataLoader pattern to load data more efficiently, and ensure data is properly passed through the WPGraphQL Model Layer and exposed only to users that have permission to view the data being requested.
This will also reduce the number of errors related to orphaned IDs that cannot be resolved.
Better Connection Support
WPGraphQL has seen a lot of improvements to internal APIs for Connections.
We will be taking advantage of these improvements in WPGraphQL for ACF.
Again, this will cause some breaking changes to some fields.
Any Field type, such as the Post Object or Relationship field that creates a relationship with another "node" will be treated as a proper Connection.
This will change the shape of the Schema in most cases to support things like "Edges" which allow for relational data between objects to be exposed in the Graph.
Better Support for ACF Field Settings
It's technically possible to use ACF Options pages with WPGraphQL, but it's well under-documented and some bugs make it hard to work with sub-pages.
We'll be improving the support for ACF Options pages!
The text was updated successfully, but these errors were encountered:
It solves a LOT of problems listed above, such as better support for re-usable Fragments, better connection support, better DataLoader support, better integration with WPGraphQL for WooCommerce, better support for WPGraphQL Smart Cache, better support for clone fields, etc.
We are still working on documentation and an upgrade guide, but we would LOVE for folks to start using the new version and providing feedback / report bugs in the other repo.
That's the version we'll be supporting going forward and will be releasing on WordPress.org.
At this point, there might still be minor changes as we work toward that stable release, but we highly recommend making the switch sooner than later as the new plugin is what we're going to support long term and this repo will be archived in the not-too-distant future.
This plugin is valuable for many users. Packagist reports more than 47,000 installs!
Despite the growing popularity, it has many issues that have been ignored for far too long.
We're changing that.
WPGraphQL for ACF is getting some new life breathed into it.
Over the coming weeks and months, we'll be working through some major changes and refactors on the path to a formal v1.0 of WPGraphQL for ACF.
Breaking Changes
Before getting into the details of the release, I want to be clear up front that there will be many breaking changes coming in order to get to the v1.0.
We'll be making many breaking releases to this plugin on the path to v1.0, so pay close attention to the Release Notes of each release as you upgrade.
Sometimes, a breaking change for one user might not be a breaking change for another user. Make sure to follow the releases closely, and we recommend testing updates in staging environments before you upgrade.
The Path to 1.0
Below are some of the high-level areas we will be addressing on the road to a 1.0 release:
Significant Updates to Location Rules
Location Rules in this plugin are simply broken.
Advanced Custom Fields provides location rules that allow you to configure where in the WordPress admin content creators can interact with ACF Field Groups.
These location rules were designed with the context of administration screens in mind, not a GraphQL Schema.
A GraphQL Schema needs to know what's possible for a Type of content, where the location rules apply to a specific piece of content.
For example, the Location Rules above state that the field group should show on a specific taxonomy, for a specific user role.
A GraphQL Schema doesn't know who the user is until the query is executed. So the GraphQL Schema needs to show that the field group is possible to be asked for, but depending on your user role you may or may not get data in response.
Currently the WPGraphQL for ACF location rules attempt to translate the location rules and apply them to the Schema, and in many cases this leads to cases where the field group simply doesn't show in the Schema at all, or you have to add ACF Field groups to locations that don't make sense for the content creators.
Now, instead of WPGraphQL for ACF attempting to infer the ACF Location rules and apply them to the GraphQL Schema, there will be a new UI where the ACF Field Group can be added to specific GraphQL Types in the Schema.
The ACF Location rules for where the field group should show in the Admin will remain the same, but a new setting will be exposed to configure where in the GraphQL Schema your field group should show.
Here's a taste of what this new setting field looks like:
And thanks to @drewbaker and @rsm0128, this is already getting close to complete in #135. 👏
This will be a breaking change. We're working to make sure the friction is reduced to a minimum, but most sites will need to re-configure their ACF Field groups when this is released. But we think you'll enjoy this quite a bit.
Better Support for Re-Usable Fragments
Currently the WPGraphQL Schema adds nested Types to field Groups with a prefix of the Root Type the field group belongs to.
This makes it impossible to re-use fragments across Types.
If you've ever tried to query Flex Fields across different Post Types, you know the pain I'm speaking of.
This is changing!
This too, will be a breaking change (that we can all rejoice about) but breaking nonetheless. So, when this rolls out, it will require changes to your client applications.
So be sure to plan time for this release when it comes.
Better DataLoader Support
There are various places in this plugin that make direct queries for related objects, and do not make use of the WPGraphQL DataLoader pattern.
We'll be updating various fields to make use of the DataLoader pattern to load data more efficiently, and ensure data is properly passed through the WPGraphQL Model Layer and exposed only to users that have permission to view the data being requested.
This will also reduce the number of errors related to orphaned IDs that cannot be resolved.
Better Connection Support
WPGraphQL has seen a lot of improvements to internal APIs for Connections.
We will be taking advantage of these improvements in WPGraphQL for ACF.
Again, this will cause some breaking changes to some fields.
Any Field type, such as the
Post Object
orRelationship
field that creates a relationship with another "node" will be treated as a proper Connection.This will change the shape of the Schema in most cases to support things like "Edges" which allow for relational data between objects to be exposed in the Graph.
Better Support for ACF Field Settings
It's technically possible to use ACF Options pages with WPGraphQL, but it's well under-documented and some bugs make it hard to work with sub-pages.
We'll be improving the support for ACF Options pages!
The text was updated successfully, but these errors were encountered: