WPGraphQL

Tag: Extensions

  • Remove Extensions from GraphQL Response

    This snippet removes the “extensions” from the GraphQL response: 

    add_filter( 'graphql_request_results', function( $response ) {
	// If it's an ExecutionResult object, we need to handle it differently
	if ( $response instanceof \GraphQL\Executor\ExecutionResult ) {
		// Convert to array and remove extensions if they exist
		$array = $response->toArray();
		if ( isset( $array['extensions'] ) ) {
			unset( $array['extensions'] );
		}
		return $array;
	}

	// Handle array responses
	if ( is_array( $response ) && isset( $response['extensions'] ) ) {
		unset( $response['extensions'] );
	}

	// Handle object responses
	if ( is_object( $response ) && isset( $response->extensions ) ) {
		unset( $response->extensions );
	}

	return $response;
}, 99, 1 );

    Before

    After

  • Showing Post Type labels in public queries

    WPGraphQL respects WordPress core access control rights. This means that data that is only available to authenticated users in the WordPress admin is only available to authenticated users making GraphQL requests.

    Sometimes, you want to expose fields that are restricted by default.

    Take the Post Type Label field, for example.

    Querying for the label of a Post Type as a public user returns a null value by default:

    Screenshot of a query for ContentTypes and their label, showing null value for the label.

    With the following snippet, you can expose the label field to public users:

    add_filter( 'graphql_allowed_fields_on_restricted_type', function( $allowed_restricted_fields, $model_name, $data, $visibility, $owner, $current_user ) {

	if ( 'PostTypeObject' === $model_name ) {
		$allowed_restricted_fields[] = 'label';
	}

	return $allowed_restricted_fields;

}, 10, 6 );

    And below we can see the same query, showing the value of the labels to public users.

    Screenshot of a query for ContentTypes and their label, showing the label's value for the label.

  • Changing the Server Debug Flag

    The following snippets show how to change the Debug Flag for the GraphQL Server execution.

    By default, the function callstack trace is not included with errors data unless users are logged in.

    If you wanted to track this data on the server, for example, even for public requests, and send the data to a logging service, for example, you could enable the call stack with the following snippet. (Just make sure you _also_ cleanup the errors after the fact so you don’t expose too much data to public users.)

    add_action( 'graphql_server_config', function( \GraphQL\Server\ServerConfig $config ) {
	$config->setDebugFlag( 1 );
});

    Example of the Error Trace when the debug flag is set to 1

    There is no callstack trace with the error.

    Example of the Error Trace when the debug flag is set to 2

    add_action( 'graphql_server_config', function( \GraphQL\Server\ServerConfig $config ) {
	$config->setDebugFlag( 2 );
});

    There is a callstack trace included with the error.