Release v0.6.0

[jasonbahl]

WIP

This PR is a Work in Progress, but aims to solve quite a few issues with this plugin.

Breaking Changes

This PR includes many breaking changes, both to internal code APIs for users extending code via WordPress hooks/filters, etc and breaking changes to the shape of the Schema, so client applications will need to be adjusted to compensate for the changes.

Issues Addressed

This addresses the issues in the v0.6.0 milestone: https://github.com/wp-graphql/wp-graphql-acf/milestone/2

I'll be going through each issue and commenting/documenting how this PR resolves the issue.

• closes #173
• closes #167
• closes #243
• closes #247
• closes #237
• closes #164
• closes #16
• closes #85

[ardiewen]

Understanding that this is still very much WIP, the major question that still remains open for me is how do we address reusability of ACF Fields on both the content editor side, as well as the graphql schema.

The following simplified use case will hopefully illustrate the need and the current gap in functionality.

Context / Use Case

As a layout builder, we've found great utility in building standalone field groups that address certain functions, then cloning them as needed. Here's a simplified / contrived example:

I've created a custom field group called Background with a single button group field called "Kind" which has options ["color", "image", "video"].

We can then create our first section, called Banner and clone the entire field group using the All fields from... option.

When we create addition sections such as Accordion, Carousel, Columns, in the future, any upstream changes to the Background field group will automatically be available on these

Currently, this is what we're observing on this PR branch:

1. No prefixes are applied automatically to field groups when they're assigned using location rules.

   This is great! From our contrived example above, it means we can create a fragment like this:

   fragment BackgroundFields on Background {
     kind
   }
   

2. When field groups are cloned however, they automatically inherit the parent type

   This becomes a challenge, as you'll get fragments like this:

   

   Which means we cannot reuse our fragment above:

   fragment BannerFields on Banner {
     background {
       ...BackgroundFields
     }
   }
   

   Ideally, we'd have a scenario in which we can clone the Background field group into multiple layout field groups, while reusing the same fragment above, like so:

   fragment BannerFields on Banner {
     background {
       ...BackgroundFields
     }
   }
   fragment AccordionFields on Accordion {
     background {
       ...BackgroundFields
     }
   }
   fragment CarouselFields on Carousel {
     background {
       ...BackgroundFields
     }
   }
   ...
   

I'm not sure how much of this is by design vs due to WIP status, but I thought I'd report some initial findings.

There's also a lot of this that hinges upon the design / intent of the clone field, I suppose.

Anyway, if there's anything else you'd like me to test, happy to make some more examples.

[gavinhenderson]

Hey @jasonbahl @kidunot89 Is there any plan to release this new version?

If there is anything that I can contribute to help you be able to launch this let me know. I am very appreciative of all your work!

I am in need of some of the fixes in this new version to allow me to access relationship fields that is a list.

[jasonbahl]

@gavinhenderson I'm hoping to get back to it soon, but I can't promise an ETA as there's a lot of other in-flight work I'm doing.

[jasonbahl]

But feel free to use this branch in your environments if it works for you!