Release Notes

Breaking Changes

Impact: low

This release includes a few breaking changes. The impact should be pretty low and if affected should require minimal updates to get caught up.

• (#1550) Changed filter name 'wsa_form_top_' . $form['id'] to graphql_settings_form_top
• (#1550) Changed filter name 'wsa_form_bottom_' . $id to graphql_settings_form_bottom
• (#1550) The following fields are no longer passed through html_entity_decode() by default (but can be re-enabled via filter): post.content, post.excerpt, comment.content and term.description
• (#1550) Changed filter name graphql_{$config['name']}_possible_types to graphql_union_possible_types
• (#1555) Removed ContentTemplate.templateFile field from the Schema
• (#1555) Page Templates that start with a number or do not include the word Template in them will be prefixed with Template_

New Features

• (#1555) Add new NodeWithTemplate interface
• (#1555) Add NodeWithTemplate Interface to all Post types
• (#1555) Add template field to ContentNode interface so all Post Types can query for template.
• (#1556) Add new graphql_insert_term action. Thanks @smthomas!

Bugfixes

• (#1550) Update dealerdirect/phpcodesniffer-composer-installer composer dependency so automated tests can work again
• (#1551) Fix bug where querying comment.databaseId was throwing errors
• (#1555) Fix bug where post.template was returning null when querying Posts in a preview state
• (#1555) Fixes bug where Page Template starting with a number would break the Schema
• (#1542) Fixes bug with ContentTypeEnum not allowing external Types to easily be added to the Enum. Thanks @kidunot89!

Release Notes

Breaking Changes

This release includes 2 breaking changes: #1490 and #1496.

New Features

• (#1533) BREAKING: Update GraphQL-PHP to v0.14.3. Impact: minor
• (#1490) BREAKING: Introspection Queries are now disabled by default for production environments. They can be enabled from the GraphQL Settings page. External tooling such as GraphiQL, GraphQL Playground, Gatsby, etc that rely on Schema Introspection will need Introspection to be manually enabled. If you're using WPGatsby, you will want to update to v0.5.4
• (#1529): Add initial support for Application Passwords (coming soon to WordPress core!)
• (#1409): New Debug Log functionality added. graphql_debug() function can be used to output debug messages in the GraphQL responses.
• (#1495): Adds isSticky field to the Post type in the Schema. Thanks @smthomas!
• (#1516 & #1518): Adjust behavior of is_graphql_http_request() to have a pre filter to bypass logic early

Bugfixes

• (#1496) BREAKING: UniformResourceIdentifiable Interface is now applied only to public post types and taxonomies instead of all post types and taxonomies, as only public ones have a URI.
• (#1493): Prevent contributors from being able to publish posts, just submit them as pending
• (#1507): Prevent contributors from being able to edit others posts
• (#1510): Prevent comments associated with private posts from being publicly visible. Thanks @smthomas!
• (#1503): Update nodeResolver to target all public custom post types. Thanks @kidunot89!
• (#1502): Update Dockerfile for test environment to reduce errors. Thanks @duffn!
• (#1500): createComment mutation no longer allows userId to be set as an input
• (#1531): Fix how globals are being reset after GraphQL requests. Allows GraphQL to play nicer when used within PHP templates. Thanks @saulirajala!

Release Notes

Bugfix

• (#1488) Fixes bug in PostObjectConnectionResolver where empty array for post__in argument is not properly handled. Thanks @jonshipman!

Release Notes

New

• Adds a setting to the settings page to disable the "Admin Bar" menu item for the GraphiQL IDE (see #1481)
• Adds graphql_interface_resolve_type filter to allow 3rd party plugins the ability to override the ResolveType for an interface. See: #1483. Thanks @kidunot89!

Bugfixes

• Fixes a bug where cursors were not working properly when using post__in args on custom connections. Closes #1477
• Fixes bug where post mutations couldn't remove term connections from the post. See: #1484. Thanks @tpszhao!

Release Notes

Fixes a mistake from the v0.13.0 release where the built GraphiQL app files had been gitignored and left out of the release 🤦‍♂️

Before

There's a blank page with a loading message

After

The GraphiQL App loads into the WP Dashboard page

Release Notes

This release accomplishes the following:

• Adds GraphiQL IDE to the main WPGraphQL plugin (deprecates the need for separate WPGraphiQL plugin)
• Adds GraphQL Settings Page with API to register more fields and field sections
• Adds Query Logs and Tracing to the main WPGraphQL plugin (deprecates the need for separate WPGraphQL Insights plugin)

GraphiQL IDE

WPGraphQL now has GraphiQL IDE built in to WPGraphQL!

GraphiQL IDE is an incredibly useful tool for working with GraphQL APIs, and now it's available to all users of WPGraphQL without needing to find and install a separate plugin.

With WPGraphQL Active, there is now an Admin Menu for GraphQL, and within that menu is "GraphiQL IDE" link

There's also an Admin Bar short-link for GraphiQL IDE:

Clicking either link will open GraphiQL in the WP Admin:

You can now browse the WPGraphQL Schema and test Queries and Mutations all from within the WordPress Dashboard.

Settings Page (and API)

WPGraphQL now has a settings page where some common configurations can be set, without needing to touch code.

In the Admin Menu, there's now a "GraphQL > Settings" link

Clicking that will take you to a Settings Page:

Settings Overview

These settings can be used to accomplish some common tasks with WPGraphQL that previously required code (filters/constants) to accomplish.

• GraphQL Endpoint: You can now change the endpoint to be something other than /graphql.
• Enable GraphiQL IDE: You can enable/disable GraphiQL IDE in the Admin. Now that GraphiQL is bundled, you can turn it off if you prefer not to have it.
• Delete Data on Deactivation: You can opt in or out of having any data WPGraphQL stores be deleted when WPGraphQL is de-activated. Things like the settings for this settings page get stored in the database. You can choose to keep data (for example temporary de-activations) or delete all data on de-activation to keep your data clean.
• Enable GraphQL Debug Mode: When errors occur in GraphQL requests, the default message is "Internal Server Error" to ensure implementation details are not leaked to the public. Enabling GraphQL Debug Mode shows more detailed messages, allowing developers to identify issues more quickly.
• Enable GraphQL Tracing: Enabling tracing will track performance of the entire request and each field within the request. The trace data will be returned as part of the "extensions" portion of the GraphQL response, alongside the data. This feature was previously part of WPGraphQL Insights, but can now be enabled by checking this setting. Trace data can be helpful for identifying bottlenecks (slow resolvers)
• Tracing Role: With Tracing Enabled, it can be limited to a certain roles. Only the selected role (or all) will see the trace data in results of GraphQL requests
• Enable Query Logs: Enabling Query Logs will return MySQL Query logs in the "extensions" portion of the GraphQL response. This is essentially like Query Monitor for WPGraphQL. You can see the specific MySQL queries being executed to resolve GraphQL requests.
• Query Log Role: If Query Logs are enabled, they will execute, but the results can be limited to a specific user role, or all user roles (public requests allowed).

Settings API

Along with the Settings Page, there are some basic APIs to allow 3rd party plugins to easily add GraphQL Settings.

register_graphql_settings_section

This function should be used within the graphql_register_settings action, and allows new Settings Sections to be registered to the Settings Page.

usage:

add_action( 'graphql_register_settings', function() {
	register_graphql_settings_section( 'graphql_my_section', [
		'title' => __( 'My Section', 'your-textdomain' ),
	]);
});

This will add a new section to the settings page like so:

register_graphql_settings_field

This function will register a new settings field to the specified settings section:

usage:

add_action( 'graphql_register_settings', function() {
	register_graphql_settings_field( 'graphql_my_section', [
		'name'    => 'my_field',
		'label'   => __( 'My Field', 'your-textdomain' ),
		'desc'    => __( 'Your field description...', 'your-textdomain' ),
		'type'    => 'text',
		'default' => "my default value...",
	]);
});

This registers a text field named with the "My Field" label to the "graphql_my_section" section.

register_graphql_settings_fields

This allows multiple settings fields to be registered to a section.

usage:

add_action( 'graphql_register_settings', function() {
	register_graphql_settings_section( 'graphql_new_section', [
		'title' => __( 'New Section', 'your-textdomain' ),
	] );
	register_graphql_settings_fields( 'graphql_new_section', [
		[
			'name'    => 'text',
			'label'   => __( 'Text Input', 'wp-graphql' ),
			'desc'    => __( 'Text input description', 'wp-graphql' ),
			'type'    => 'text',
			'default' => 'Title'
		],
		[
			'name'  => 'textarea',
			'label' => __( 'Textarea Input', 'wp-graphql' ),
			'desc'  => __( 'Textarea description', 'wp-graphql' ),
			'type'  => 'textarea'
		],
		[
			'name'  => 'checkbox',
			'label' => __( 'Checkbox', 'wp-graphql' ),
			'desc'  => __( 'Checkbox Label', 'wp-graphql' ),
			'type'  => 'checkbox'
		],
		[
			'name'    => 'radio',
			'label'   => __( 'Radio Button', 'wp-graphql' ),
			'desc'    => __( 'A radio button', 'wp-graphql' ),
			'type'    => 'radio',
			'options' => [
				'yes' => 'Yes',
				'no'  => 'No'
			]
		],
		[
			'name'    => 'multicheck',
			'label'   => __( 'Multile checkbox', 'wp-graphql' ),
			'desc'    => __( 'Multi checkbox description', 'wp-graphql' ),
			'type'    => 'multicheck',
			'options' => [
				'one'   => 'One',
				'two'   => 'Two',
				'three' => 'Three',
				'four'  => 'Four'
			]
		],
		[
			'name'    => 'selectbox',
			'label'   => __( 'A Dropdown', 'wp-graphql' ),
			'desc'    => __( 'Dropdown description', 'wp-graphql' ),
			'type'    => 'select',
			'default' => 'no',
			'options' => [
				'yes' => 'Yes',
				'no'  => 'No'
			]
		],
		[
			'name'    => 'password',
			'label'   => __( 'Password', 'wp-graphql' ),
			'desc'    => __( 'Password description', 'wp-graphql' ),
			'type'    => 'password',
			'default' => ''
		],
		[
			'name'    => 'file',
			'label'   => __( 'File', 'wp-graphql' ),
			'desc'    => __( 'File description', 'wp-graphql' ),
			'type'    => 'file',
			'default' => ''
		],
		[
			'name'    => 'color',
			'label'   => __( 'Color', 'wp-graphql' ),
			'desc'    => __( 'Color description', 'wp-graphql' ),
			'type'    => 'color',
			'default' => ''
		],
		[
			'name'    => 'user_role',
			'label'   => __( 'User Role', 'wp-graphql' ),
			'desc'    => __( 'Description for selecting a User Role.', 'wp-graphql' ),
			'type'    => 'user_role_select',
			'default' => "administrator",
		],
	] );
} );

get_graphql_setting

This function should be used to get settings values from GraphQL Settings pages. Each settings section is stored in a serialized array in the options table. This function will properly get the value and return it.

usage:

If you wanted to get the "color" setting from the "graphql_new_section" section, and have it default to "blue" if no value is set, you would do so like:

$option_name = 'color';
$default_value = 'blue';
$section = 'graphql_new_section';
$value = get_graphql_setting( $option_name, $default_value, $section );

Tracing

We saw that there are settings for Tracing, but what exactly is Tracing?

Tracing is performance tracking for the entire GraphQL request and each field of the request. This data can be helpful when debugging bottlenecks.

With Tracing enabled from the Settings Page, executing a GraphQL Query will show the trace data in the "extensions" portion of the request:

There is data for the entire request:

• startTime
• endTime
• duration

And data for each field within the request:

• path
• parentType
• fieldName
• returnType
• startOffset
• duration

This data can be very helpful when debugging bottlenecks.

Let's take a look at an example.

Executing the following query:

{
  posts {
    nodes {
      id
      title
    }
  }
}

We would see the following Trace data for the request:

  ...
  "tracing": {
  "version": 1,
  "startTime": "1600294443.335",
  "endTime": "1600294443.381",
  "duration": 45998,
  "execution": {
      ...

The request duration is 45998 microseconds (0.045998 seconds).

And if we scrolled down, we'd see the following trace data for the id field of the first post:

...,
{
  "path": [
    "posts",
    "nodes",
    0,
    "title"
  ],
  "parentType": "Post",
  "fieldName": "title",
  "returnType": "String",
  "startOffset": 27518,
  "duration": 797
},
...

Here, we can see that the duration was 797 microseconds (0.000797 seconds)

Let's override this field resolver like so:

add_filter( 'graphql_Post_fields', function( $fields ) {

	$fields['title']['resolve'] = function( \WPGraphQL\Model\Post $post ) {

		// Sleep for 1 second to simulate something taking a long time
		sleep(1);
		return $post->titleRendered;
	};

	return $fields;

});

Now, if we look at the trace data, we can see:

"tracing": {
 "version": 1,
 "startTime": "1600294618.1841",
 "endTime": "1600294628.2435",
 "duration": 10059434,

The entire request duration is now 10059434 microseconds ( 10.059434 seconds).

Something is clearly wrong! This request used to take well under 1 second, and now it's taking more than 10 seconds! 😱

If we scroll down we will see that the duration of each title field is looking quite long:

```json
...
{
  "path": [
    "posts",
    "nodes",
    0,
    "title"
  ],
  "parentType": "Post",
  "fieldName": "title",
  "returnType": "String",
  "startOffset": 27518,
  "duration": 1000964
},
...

The duration for the title field is now 1000964 microseconds (1.000964 seconds).

Now, we as developers know what field to start troubleshooting.

In our case we know that the title field had a sleep(1) in the resolver, so we can remove that and we're back to super speedy execution!

Query Logs

Query Logs are a super helpful debugging tool. A lot of things happen under the hood to resolve a GraphQL Query, and sometimes it can be a mystery.

Enabling Query Logs can give insight into what SQL Queries are being executed, how long they're taking, the raw SQL that is executed and the stacktrace to where in the codebase the query is being executed from.

This can be super helpful when things don't seem to be behaving as you'd expect. Sometimes you get results that you don't expect, and analyzing the raw SQL queries can help identify why things are misbehaving. Sometimes it's a rogue plugin that's filtering WP_Query args too aggressively, or perhaps a GraphQL input argument isn't properly mapping to WP_Query.

In any case, seeing the raw SQL queries and the path to the code that called it can be a huge time saver when debugging.

Release Notes

New

• Adds WPGraphQL WPML plugin to the docs. Thanks @rburgst!

Bugfixes

• This fixes more bugs with querying custom post types from URI. See #1451

Release Notes

New

• Adds "WPGraphQL for Posts 2 Posts" extension to the documentation (#1442). Thanks @kellenmace!

Bugfixes

• fixes bug where custom post types weren't queryable by slug (#1397). Thanks @chrisAlwinYS!
• Changes ContentTemplateUnion to an Interface (#1432)
• Adds action to CommentMutations (#1436). Thanks @paulisloud!

Release Notes

Bugfixes

• Fixes PHP warning in Model/Post.php. Ensures graphql_single_name property exists before using it. Closes #1256.
• Remove exception from RootQuery.viewer field and instead let the Model handle things. Return null for public requests instead. Closes #1419
• Fixes bug with Previews not working in WordPress installs where revisions are disabled (WordPress still saves the preview revision even when revisions are otherwise disabled). Closes #1426

Release Notes

Overview

This fixes a bug in the v0.11.0 release by moving the databaseId field out of the UniformResourceIdentifiable Interface and into its own DatabaseIdentifier Interface. This also fixes a case of databaseId being nullable in one case and causing an invalid Schema error. This PR adds a test to avoid invalid Schema errors in the future.

Breaking Change

In many cases, consumer applications won't be affected by this breaking change, but it's a breaking change nonetheless.

The field databaseId is no longer on the UniformResourceIdentifiable Interface. This will break any queries that were asking for the databaseId on the UniformResourceIdentifiable Interface, like so: ...on UniformResourceIdentifiable { databaseId }. Instead, these queries should ask for ...on DatabaseIdentifier { databaseId }.

New Features

• Added WPGraphQL Send Email extension to the docs. Thanks @ashhitch!
• Added test to validate Schema

Release Notes

Breaking Changes

uri field changed to nullable

The uri field on the UniformResourceIdentifiable Interface has been changed from a NonNull field to nullable.

This will likely not affect many consumers, but it is a breaking change to the Schema and might cause issues for some consumers.

The reason for the change is because not everything that can have a URI in WordPress is guaranteed to have one. For example Post Types and Taxonomies can have a URI (archive page), but sometimes they don't and we need to provide for that flexibility in the Schema.

New Features

• exposes new fileSize field on MediaItem and MediaSize types (#1350, #1389)
• Allow Models returned by Loaders to be filterable (#1391, #1388)
• Expose archive urls for ContentType and fix resolution for querying node by uri for homepage (#1365, #1401, #1390, #937)

Bugfixes

• Fixes bug where location argument on MenuItems connection queries was not being respected. (#1402, #1396)
• Fixes bug where where arguments had been removed from HierarchicalContentNode.children connections (#1405, #1406)
• Fixes bug where child nodes of hierarchical post types couldn't be queried by uri. (#1400, #1403)
• Update anchor styling for docs site, Update examples for set_query_arg() in the docs, remove double background in <pre> blocks and add pair-programming sessions to connections guide. Thanks @jacobarriola!
• Remove deprecated pageBy example from the docs. Thanks @MarcelloTheArcane!
• Update docs to use get_allowed_post_types() instead of $allowed_post_types. Thanks @sboerrigter!

Release Notes

New Features

• Pass results of $resolver to the graphql_after_resolve_field hook (#1153 #1369)
• Adds isPostsPage field to the Page type (#1370)
• Adds extensions to docs.wpgraphql.com (#1165 #1375)

Bugfixes

• Fixes bug with password protected posts causing errors in queries (#1376 #1374)
• Fixes circular connections with MenuItems (#1219 #1363)
• Fixes bug when querying pages with / as the path not returning the homepage (#1352 #1366)
• Fixes type issues for loginIn and loginNotIn argument fields for user connections (#1174 #1368)

Release Notes

Bugfix

• Fixes a bug where connections from terms->posts weren't properly setting the TaxQuery array so all posts were being returned, not just posts connected to the term. Closes #1360 & #1359

Release Notes

Bugfix

• Update how the generalSettings.url field is registered to the Schema
• Update documentation to better reflect current state of the plugin and update example queries to reflect v0.10.0 Schema changes

Release Notes

This is quite possibly the most substantial release since the plugins inception.

Below is a break down of everything that's happening in this release i hopefully make it easier to update from previous versions if you come across anything that's breaking your applications.

• Breaking Changes
• New Features
• Bugfixes

Breaking Changes

• Fields returning PostObjectUnion changed to ContentNodeInterface.
  • closes #1292 (see details)
• Children of hierarchical post types changed field name to children instead of child{$postType}.
  • closes #1078 (see details)
• Hierarchical content such as Terms of hierarchical Taxonomies, Posts of Hierarchical Post Types and Menu Items are now returned in a flat list by default.
  • closes #928 (see details)
  • closes #887 (see details)
  • Removes shouldOnlyIncludeConnectedItems and shouldOutputInFlatList arguments for hierarchical term queries. The default now is a flat list and that can be overridden by passing an explicit parent in the where args.
  • Menu Items should be returned in a flat (non-hierarchical) list by default (read more)
• One to One relationships are now nested. For example post.author and post.featuredImage now return an edge/node instead of the node directly.
  • closes #347 (see details)
  • Comment.author and Comment.parent now return an edge/node, instead of the node directly. Comment.author nods is of type Commenter Interface instead of CommentAuthorUnion
  • NodeWithFeaturedImage->MediaItem fields are now one-to-one connections returning an edge with the node
  • Comment.commentedOn field is now a formal one-to-one connection returning an edge/node where the node is a ContentNode Interface
  • ContentNode.revisionOf is now a formal one-to-one connection returning an edge/node where the node is a ContentNode interface
  • HierarchicalContentNode.parent is now a formal one-to-one connection returning an edge/node where the node is of ContentNode Interface
  • PostObject.author field is now formal one-to-one connection between a Post and the Author, returning an edge/node where the Node is of type User.
• ContentNode.terms field a formal connection to the TermNode type. Previously was a listOf.
• Comment.children field was changed to Comment.replies
• Changes PostObject.editLock field to ContentNode.editingLockedBy and is a one-to-one connection which returns an edge/node. The node is of type User, and there's an edge field lockTimestamp
  • Remove EditLock Type from the Schema
• Changes PostObject.editLast field to ContentNode.lastEditedBy and is a one-to-one connection retuning an edge/node where the Node is of type User.
• Removed PostObject.terms, PostObject.termNames, PostObject.termSlugs fields in favor of formal connections
• Removed Taxonomy.connectedPostTypeNames in favor of Taxonomy.connectedPostTypes connection.
• Converted Taxonomy.connectedPostTypes to formal connection instead of listOf.
• Changed authorId on Post model to return global ID. (Adds new authorDatabaseId field to get the Integer ID of the author.)
• Change Post.featuredImageId on Post Model to Global Relay ID (add Post.featuredImageDatabaseId field to get the Integer ID of the featured image)
• Remove default parent=>0 logic from connections. For the cases where top-level items should be queried, parent=>0 can be used as an argument, but the default will be a flat-list of connected items
• Update Term Objects parent and ancestor fields to be proper connections. There's currently a TermObject.parentNode field that wasn't fully moved to TermObject.parent (fixed here: https://github.com/wp-graphql/wp-graphql/pull/1348/commits/9fb5e94cf184087a0ccf0b31cad08c2989fce75b)

New Features

• Preview Support
  • closes #1312 (see details)
  • closes #1162 (see details)
  • closes #1106 (see details)
  • Supports resolution of PostObject->Comments connections when queried from revision nodes (will resolve using the
    parent node's connections)
  • Adds asPreview argument to singular RootQuery entry points for Post objects. This allows for the Preview node to be returned instead of the published/draft node.
  • Adds a PostObject.preview field as a one-to-one connection returning the Preview node for the Post
  • Filter revisions to use meta from parent node by default.
  • Add filter graphql_resolve_revision_meta_from_parent to allow certain meta fields (ACF, for example) to bypass using the parent node meta for resolution and use the revision node's meta
  • Various fields in the Post model now resolve differently to accommodate previews/revisions.
  • Add asPreview argument to single post nodes.
  • Add Post.isRevision field to Post model
  • Add Post.previewRevisionDatabaseId as field to Post model
  • Add Post.PreviewRevisionId as field to Post model
  • Add Post.isPreview field to Post model
  • Add Post.PreviewDatabaseId to Post model
  • Add ContentNode.isPreview, ContentNode.previewRevisionDatabaseId and ContentNode.previewRevisionId fields to ContentNode interface
• Decode entities for content and titles.
  • Pass Post.titleRendered through html_entity_decode before returning
  • Pass Post.excerptRendered through html_entity_decode before returning
  • Pass Term.description and Term.name through html_entity_decode before returning
  • closes #1169 (see details)
  • closes #1035 (see details)
  • closes #410 (see details)
• When a Custom Post Type registers support for authors, the User Type gets a connection registered to it automatically.
  • closes #1041 (see details)
• AbstractConnectionResolver adds formal support for one-to-one connections
  • Can declare oneToOne => true when registering a connection
  • OneToOne connections can now be resolved like so: $resolver->oneToOne()->get_connection()
• Introduce Commenter Interface. An Interface shared by Commenters (CommentAuthor and User) when querying for the author of a Comment
• Adds Taxonomy.connectedContentTypes field as a formal connection from Taxonomy->ContentType
• Adds ContentType.contentNodes field that returns a connection of content nodes of that post type
• Deprecate AbstractConnectionResolver->setQueryArg for ->set_query_arg. And set_query_arg() now returns instance of the resolver to allow for chaining.
• Added databaseId field to Comment type
• Adds new authorDatabaseId field to get the Integer ID of the author.
• Add Post.featuredImageDatabaseId field to get the Integer ID of the featured image
• Introduced HierarchicalTermNode Interface
• Apply HierarchicalTermNode to Terms of hierarchical taxonomies (Categories, custom hierarchical taxonomy types)
• Apply Commenter Interface to the User Type
• Deprecate User.userId in favor of user.databaseId
• Add location field to menuItems as listOf MenuItemLocation (read more)
• Add location field to menus as listOf MenuItemLocation? (read more)
• Menus and Menu Items should be queryable by global ID and database ID (read more)
• Add databaseId to Menu and MenuItem, deprecating menuItemId and menuId (read more)
• Get Menu by name: (read more)
• Add path field to MenuItems (read more)

Bugfixes

• CommentAuthor email field restricted to requests from users with moderate_comments capability. closes #1287 (see details)
• Remove default parent=>0 logic from connections. For the cases where top-level items should be queried, parent=>0 can be used as an argument, but the default will be a flat-list of connected items
• Fix how the parent ID is resolved in MediaItem mutations
• Remove query args based on source from connection resolvers. These were causing issues. Instead, each connection that needs specific args set now uses set_query_args in the resolve function.
• Pass comment content through html_entity_decode() before returning
• Updated instances of deprecated Types::prepare_date_response to use Utils::prepare_date_response
• Add wp_check_post_lock() before returning editLock data
• Menu id's have reverted from term:$id to nav_menu:$id, need to switch it back
• List all MenuItems if no input location is set on the RootQuery.menuItems field. (read more)
• Fix generalSettings.url on Multisite endpoints (see: #1334)
• Fix bug with menu pagination (read more)
• Menus not associated with a location are now private (read more)
• Menu Items not associated with a public menu are now private (read more)

Release Notes

Bugfixes

• Fixes #1319 by reverting to using $_SERVER['HTTP_HOST'] but providing a filter graphql_is_graphql_http_request filter so servers with unique setups can define their own way to determine if a request is indeed a GraphQL request.
• Fixes #1321 by updating the node resolver to properly return Menus, and defining a loader for menus in AppContext.

Release Notes

BREAKING CHANGES

I'm listing breaking changes under "Consumer" and "Server" breaking changes.

Consumer Breaking Changes

These are changes to the Schema or how GraphQL acts for consumers that may break consuming applications, depending on how the consuming application interacts with WPGraphQL.

• Global IDs have been changed to be a hash of the loader name and the database ID. If you had taken a Global ID from a WPGraphQL node and persisted it as a reference, or added as a hard coded reference, you might need to update that persisted reference as the IDs of nodes have changed.
• changed ContentType.connectedTaxonomies field from a list to a formal connection
• removed ContentType.connectedTaxonomyNames field
• Now that all connections use the AbstractConnectionResolver, when nodes don't have permission to be loaded, instead of getting errors there will be null responses or the node will simply not be returned. Not having access to a node is not an error.

Server Breaking Changes

These changes are to internals of the codebase that might affect plugins that extend WPGraphQL on the server.

• Bumped min PHP requirement to PHP 7.1+
• Updated GraphQL-PHP from v0.12.6 to v0.13.8
• Changed signature of register_graphql_scalar() to be more consistent with other register_graphql_* methods. Before: register_graphql_scalar( $config ), Now: register_graphql_scalar( $type_name, $config ); (@pristas-peter, I know you're using this method)
• All connections now extend AbstractConnectionResolver. In the unlikely event any plugin were extending a connection not already based on the AbstractConnectionResolver, the class signature has now changed.
• Post.parentId in the Post Model is now the global ID and Post.parentDatabaseId is now the database ID of the parent
• Term.parentId in the Term Model is now the global ID and Term.parentDatabaseId is now the database ID of the parent
• graphql_register_types hook moved higher in the init_type_registry() method. Unlikely to affect extensions, but possible thing to debug if you run into issues.
• Updated use of $_SERVER['HTTP_HOST'] to $_SERVER['SERVER_NAME'] to allow the server to define the server name instead of the client. Thanks @WybrenKoelmans!
• Changed Theme.version field from type Float to String

New Features

• Re-organized the main README.md and moved things into appropriate subdirectories cleaning up the root of the repo. Thanks @CodeProKid!
• new graphql_format_type_name() access function
• new register_graphql_interfaces_to_types() method, allowing interfaces to be registered by extensions and applied to existing registered types
• Added phpstan to package.json (nothing runs yet, but developers can use it locally)
• WPGraphQL for WooCommerce Documentation changes. Thanks @jacobarriola!
• Query enqueued scripts and stylesheets as connections to nodes they're enqueued to (See: #1313)
• Throw exception if external plugins are suppressing filters on WP_Query as it can break WPGraphQL behavior
• Added a "path" field to the Plugin Model
• Updated how Models are Setup and Torn down to allow for globals to be properly set when models are being resolved.
• Added Post.enqueuedScriptsQueue and Post.enqueuedStylesheetsQueue fields to the Post Model
• Added Term.enqueuedScriptsQueue and Term.enqueuedStylesheetsQueue fields to the Post Model
• Added User.enqueuedScriptsQueue and User.enqueuedStylesheetsQueue fields to the Post Model
• Added EnqueuedScript and EnqueuedStylesheet type and EnqueuedAsset Interface

Release Notes

Breaking Changes

n/a. Please open an issue if you discover otherwise.

New Features

• Introduce register_graphql_scalar API (see: #1271)
• DRY up the DataSource.php and mark several methods as deprecated. (See: #1275)
• Add graphql_connection_amount_requested filter. Thanks @esamattis!
• Misc docs cleanup. Thanks @moonmeister, @CHEWX!
• Cleanup to the root of the repo. Thanks @CodeProKid!
• Cleanup to the .gitattributes. Thanks @bahiirwa!
• Cleanup to PHPCS. Thanks @CodeProKid!

Release Notes

Bugfix

• The WPGraphQL v0.8.0 release changed some methods in the AbstractConnectionResolver from public to protected, breaking plugins that had been using filters that returned an instance of a ConnectionResolver and were using public methods from the Class.
  • See: https://github.com/valu-digital/wp-graphql-offset-pagination/issues/3

Release Notes

Breaking Changes

Possible Breaking Change: Fields returning a uri have been adjusted to include a leading slash. Depending on your use case, this might cause unexpected behavior.

For example, if you queried:

{
  post(id: "hello-world", idType: URI) {
    id
    title
    uri
  }
}

OLD RESPONSE:

{
  "data": {
    "post": {
      "id": "cG9zdDox",
      "title": "Hello world!",
      "uri": "hello-world/" # note the missing leading slash
    }
  }
}

NEW RESPONSE:

{
  "data": {
    "post": {
      "id": "cG9zdDox",
      "title": "Hello world!",
      "uri": "/hello-world/" # note the leading slash
    }
  }
}

New Features

• Update tests to test with WordPress 5.4 #1217
• Update PHPCS rules to more clearly define rules for the project. #1235 (Thanks @CodeProKid, @kidunot89 and @renatonascalves!)
• Pass ID to cap check in deleteUser mutation: #1231 (thanks @renatonascalves!)
• Adds Postman to the list of clients in GraphQL IDE Tool docs (thanks @ch264!)

Bugfixes

• Fix deleteUser mutation for multisite #1229 (Thanks @kellenmace!)
• Fix url in WPGraphQL Insights doc (Thanks @shawncarr!)
• Update Typos in Relay Spec docs (Thanks @davidshq!)
• Fix description for Post Types in the Schema (Thanks @bahiirwa!)
• Updates the shape of leading slashes