Upgrading to v0.3.0
By Jason Bahl
April 5th, 2019
It’s best practice to test plugin updates in staging environment, but I want to re-iterate that again here. Make sure you thoroughly test things when you update this plugin to v0.3.0, especially if you have any custom code that extends the Schema in any way.
User Type in the Schema previously had a
roles field that returned a list of role names as strings.
Would return something like the following:
In v0.3.0, the roles field has changed to a Connection of roles. The query would change to something like the following:
This change was made largely because Roles aren’t _really_ properties of a user. Roles are defined as entities on their own, and Users have a connection to one or more roles.
If you were extending some of the core Types in the Schema by adding fields, the first argument passed to the resolver used to be an instance of a core
WP_* class. For instance, the
Post Type would pass an instance of
WP_Post down to field resolvers on that Type. Now, it will pass an instance of
Here’s an example of a Field that may have been registered to the “old” version of the Schema:
Here, we see the first argument passed down is a
\WP_Post. In v0.3.0, that would be a
\WPGraphQL\Model\Post like so:
The following resolvers changed:
The full list of Models now available, that replaced what was there previously, is:
Depending on how you were extending the Schema, this may or may not have any affect on you.
The signature of DataSource methods have changed. If you were calling any
DataSource methods in your extensions, you’ll likely need to refactor a bit. We recommend checking out the changes to that file so you understand all the changes for the methods you’re using, but here’s a quick example pointing out the difference:
The specific way in which the signature for the DataSource method changed may be different depending on the method. If you’re calling any of these methods, check how it changed to be sure you’re using it the new way.
If you were making use of the ConnectionResolver classes in anyway, they’ve been completely revamped. They’ve been moved into the
/Data/Connection directory, and are now stateful classes instead of classes with static methods. They are now much easier to digest and understand how to extend and create your own Connection Resolvers.
I won’t cover changes in detail here, but if you wrote any custom Connection Resolvers, and the new way of doing it doesn’t make sense after reading the new code, feel free to reach out and we can do our best to help you update.
With the introduction of the Model Layer, many fields and nodes that were previously accessible in public requests have now been restricted.
For example, our documentation previously mentioned that fields such as
User type was publicly exposed, and that if you wanted to hide it, you could do so via filter.
We’ve implemented a formal Model Layer that now handles restrictions like this out of the box, so fields that you may have been querying before, might not be returned anymore. Depending on your use case, this may be a break to application, so it’s something to get familiar with.
We’ve written some docs on the Model Layer, but the general idea is that if you download install WordPress with nothing active but a standard `twenty-*` theme, the data that is exposed to a user should be the same data that is exposed to a GraphQL request.
For example, a non-authenticated user cannot access draft Posts in a vanilla WP install, so WPGraphQL will not return Draft posts to non authenticated users. (There’s more logic than that, but that’s just an example).
There are dozens of conditions in place that help determine whether fields should or should not be returned to the consumer making the request.
There might be some other breaking changes that we didn’t cover here. If you read this guide and also get familiar with the latest info on https://docs.wpgraphql.com, but still run into issues that break your application after updating to v0.3.0, please reach out in Slack or Spectrum, or Open a Github Issue and we’ll do our best to help you get upgraded. We also highly recommend getting familiar with the source code of v0.3.0. We’ve commented the code very heavily to help provide an understanding of how everything is working and why it’s working that way.
If you find something you believe is a bug, as usual, please open an issue on Github