Skip to content

@jasonbahl jasonbahl released this Apr 6, 2019 · 84 commits to master since this release

🚀 Release Notes


These features required re-architecting quite a bit of the internals of the plugin. Some classes, functions and filters no longer exist, so if you had a codebase that extended WPGraphQL in any way, we recommend reading the upgrade guide.

🗒 Release Summary

This release had 2 primary focuses: Model Layer and DataLoader (Deferred Resolvers). These 2 features are critical to the performance and security of WPGraphQL. Below are some highlights of these features, but you can read more about them here as well.

There are also other new features and bugfixes listed below.


The role of DataLoader is to efficiently load data. It makes use of Deferred resolution of fields, allowing for the fetching of data to happen in batches. You can read more about it here and here:

🔐 Model Layer

The primary role of the Model Layer is to centralize access checks for objects. Some examples: a "draft" post should only be accessible to authenticated users with proper capabilities to edit posts. User email addresses should only be exposed to authenticated users with the "list_users" capability. Themes and plugins should only be accessible to authenticated users with proper capabilities as well.

Prior to this release, WPGraphQL helped expose various Types of data, but left the responsibility of controlling "Access" to the site owner by filtering field resolvers and handling Auth checks themselves.

This release puts much more responsibility on the core WPGraphQL plugin where it has a much more restrictive by default approach to exposing data. Data that a vanilla WordPress install doesn't publicly exposed is no longer publicly exposed by WPGraphQL.

Each field can be modified by filters, so if the restrictions WPGraphQL imposes are too restrictive, site owners can still adjust the restrictions to allow access to whatever they want users to have access to.

You can read a bit more about this here and here

💥 Breaking Changes

As mentioned above, there are many breaking changes, specifically to how internal data is resolved. Below we've listed some high level breaking changes to look out for, but we recommend reading the upgrade guide for more information.

  • Connection Resolvers have been completely revamped. If you've written your own ConnectionResolvers by extending any of the Connection classes, you will need to refactor your connection. The ConnectionResolvers were previously classes with static functions. They are no longer static, and maintain state of the connection. This allows for the connections to have proper context to pass through to pageInfo and the like. You can read about registering new connections here:
  • "roles" on users is now a Connection instead of a listOf strings. (ex: {user { id, roles { nodes { id, name } } } })
  • CommentMutation input changed the field postId to commentOn. The field is the ID of the Post Object that the comment should be connected to, but can be an ID of any Post Type.

Security Audit

We had a formal security audit performed on the plugin by Simone Quatrini of Pen Test Partners. Fortunately, most of the issues reported by the audit were already being resolved by the Model Layer we had in progress at the time we received the report. Some additional issues were brought to our attention that were not on our radar and were addressed in this release. We recommend updating to this latest version to benefit from all the new features as well as the security fixes. In a week or two, we will publish more information about the security audit, but want to give folks the chance to update the plugin to the latest version before disclosing the issues that were reported.

New Features

Some of these new features were also mentioned above in Breaking Changes.

  • Updated Docker config for Travis CI tests to run in PHP 7.3. Thanks @mngi-arogers!
  • New CursorBuilder class to provide more stability to cursor based pagination. Really great work here, @epeli!
  • Travis CI is now running PHP Code Sniffer checks on the codebase. Currently set to allow fail, but sets us up to get closer to fully adopting WordPress Core Code Standards. Although, they may be changing soon too. Thanks @renatonascalves for hooking up Travis to run the sniffs!
  • DataLoader / Deferred Resolvers: This release implements Deferred resolution throughout the entire codebase and provides a way for other datasources to take advantage of the same advantages. You can read more about Deferred resolution here:
  • Loaders added to AppContext: DataLoader classes are now registered within AppContext and passed down to all Resolvers to make use of already cached data and centralized fetching (instead of relying on Globals). As part of this we got things hooked things up to allow for additional third party loaders to be added to AppContext via filter. Thanks for your work on this, @kidunot89!
  • Revamped Connection Resolvers: Along with DataLoader, we revamped resolvers for Connections, making it much easier to create custom connection resolvers. You can read about registering connections here:
  • Model Layer: You can read more about the Model Layer here: Thanks for all your work on this feature, @CodeProKid!
  • Revisions Support: You can now query revisions of Posts (or post_types).
  • DataSource methods expect different arguments now. You must pass $context from resolvers to the DataSource methods now, to take advantage of Deferred resolution.
  • Resolvers now receive instances of a Model instead of instances of \WP_Post or \WP_User, etc. If you were registering fields to PostObject Types, or Term Types or User Types, or almost anything, if the object being passed as the first argument of the resolver was a core \WP_* class instance, it will now be a WPGraphQL Model instance. . .for example: \WP_Post is now \WPGraphQL\Model\Post being passed in.

🐛 Bugfixes

  • Adjustments to Cursor ordering / filters to support order by meta (or other values). Thanks @epeli!
  • All sorts of access control data leaks. The Model Layer now restricts data that should be restricted and exposes it only to those with proper capabilities to view it. Thanks again to Simone for working with us on the Security Audit and providing us with a detailed report, and verifying that the issues had been properly resolved in this release!
Assets 2
You can’t perform that action at this time.