Jason Bahl

@priteshsaxena31 you shared 2 queries and indicated that one is the french query and one is the english query. Neither of them indicate the language.

Out of the box, WPGraphQL doesn’t work with WPML so you need an extension such as:

– https://github.com/rburgst/wp-graphql-wpml
or
– https://wpml.org/documentation/related-projects/wpml-graphql/

Both of these plugins add “language” arguments to the fields in GraphQL so you can query for fields in a specific language.

For example, the WPML-GraphQL extension on wpml.org shows a query like so:

{
  posts( where: { language: all } ) {
    nodes { ... }
  }
}

In order to get content of a specific language, you will need to specify what language you are asking for content in.

I would refer to the relevant extension(s) documentation to understand how to accomplish what you’re after.

@vivekkotadiya Yes, you can use the queryId along with variables.

For example, I have the following query saved as a persisted query:

query GetPosts($first:Int) {
  posts(first:$first) {
    pageInfo {
      startCursor
      endCursor
      hasNextPage
      hasPreviousPage
    }
    nodes {
     id
     title
    }
  }
}

And I can query this via a GET request and queryId and pass variables like so:

@semiherdogan I regularly use WPGraphQL with several versions of PHP and our tests also run on several versions of PHP including PHP 8.1

I would recommend following the debugging guide to help you get more information: https://www.wpgraphql.com/docs/debugging

What is the query you are trying to execute? Based on the error message it looks like you are trying to query something like the following:

{
  blogs {
    nodes {
      featuredImage {
        node {
          sourceUrl       
        }
      }
    }
  }
}

Out of the box, this is not a valid query because there is no field “blogs” in the Schema. If you’re expecting to be able to query this, then something (a plugin or custom code) has extended the Schema and that code _might_ be causing issues.

If you’re not able to pinpoint the issue following the Debug guide linked above, I would recommend de-activating any plugins or custom code and then activating things one at a time until you are able to identify the source of the bug.

@mashrurrahman are you using the Gutenberg Block Editor or the “Classic Editor”?

If you are using the block editor, there’s a known core WordPress issue that prevents meta from being previewed (not just ACF meta, but any meta). You can read more about it in the original Github Pull Request that added preview support for WPGraphQL for ACF:

NOTE ABOUT GUTENBERG: Because of a core bug with Gutenberg, meta (including ACF fields) are not persisted to the database for previews, so the fields cannot be exposed by WPGraphQL for previews when using ACF and Gutenberg together. Previewing ACF fields with the classic editor works fine.. This is not an ACF bug, this is a core Gutenberg bug.

SEE:?WordPress/gutenberg#16006. I commented details about the issue here as well:?WordPress/gutenberg#16006 (comment)

– https://github.com/wp-graphql/wp-graphql-acf/pull/153

If you are NOT using the block editor, and are still experiencing issues, we’ll need more information to understand what you’re expecting vs. what’s actually happening. We’ll need proper steps to reproduce including an ACF Field Group export and additional “steps to reproduce”. You can provide that information by opening a new issue on the WPGraphQL for ACF Github repository: https://github.com/wp-graphql/wpgraphql-acf/issues/new/choose

@highfxmedia Hey Kurt!

Thanks for your interest in Subscriptions. I agree that it would be a fantastic feature, and we hope to support it one day, but we don’t have an ETA and it’s not currently being actively pursued.

One of the challenges to formally supporting it in core WPGraphQL is the transport. PHP environments typically are not ideal for handling open sockets and a lot of WordPress hosts wouldn’t support it, so there’s a good chance a service would be needed to handle the persistent open connection to transport the real-time events.

Possibly a service like Pusher or Ably could serve as the transport layer.

I’ll see if I can track down some old experiments I’ve done in the space and publish them on Github to see if they could maybe inspire someone to get something working.

Going to close this due to inactivity.

I’m going to close this based on inactivity

@rajeshgrgdesign Thanks for using WPGraphQL for ACF and reporting this bug.

In order to reproduce I think we’ll need to understand a bit more about your setup.

Can you please open a Github issue and follow the Issue template to provide us with enough information to reproduce that would be great.

Also, be sure to check these guides:

• https://acf.wpgraphql.com/debugging/
• https://acf.wpgraphql.com/upgrade-guide/
  
  I’m going to close this and mark it as resolved, and we can track it over on the Github repo.
  
  Thanks!

@psulkava Hey! I’m sorry you’re running into issues using SVGs and querying their data via WPGraphQL.

WordPress doesn’t natively support SVG uploads. I assume another plugin is also active to allow SVG uploads?

Anyway, because SVGs are not supported as uploads in core the expectation is that mediaDetails.height and mediaDetails.width will be integers and not floats.

Since your WordPress install has been modified to support SVG uploads, you will want to modify your WPGraphQL Schema to support this change.

I have 2 suggestions that might work:

1. Filter the MediaDetails.height and MediaDetails.width fields to return a Float instead of Int
2. Register new fields to the schema such as MediaDetails.heightAsFloat and MediaDetails.widthAsFloat

1. Filter the Field Types

This snippet shows how to filter the height and width fields to be represented in the GraphQL Schema as “Float” (untested, but I believe it should work)

<?php
add_filter( 'graphql_MediaDetails_fields', function( $fields ) {

    // First, make sure there's actually a "height" field registered to the MediaDetails Type
    if ( isset( $fields['height'] ) ) {

      // Override the resolve function completely
      $fields['height']['type'] = 'Float';
    }

    // First, make sure there's actually a "width" field registered to the MediaDetails Type
    if ( isset( $fields['width'] ) ) {

      // Override the resolve function completely
      $fields['width']['type'] = 'Float';
    }

    return $fields;

}, 10, 1 );

2. Register new Fields

This snippet shows how to register new fields to the MediaItem type:

<?php
add_action( 'graphql_register_types', function() {

  register_graphql_fields( 'MediaDetails', [
    'heightAsFloat' => [
       'type' => 'Float',
       'description' => __( 'Height of the MediaItem returned as a Float', 'your-textdomain' ),
       'resolve' => function( $media_details, $args, $context, $info ) {
          return ! empty( $media_details['height'] ) ? $media_details['height'] : null;
        } 
    ],
    'widthAsFloat' => [
       'type' => 'Float',
       'description' => __( 'Width of the MediaItem returned as a Float', 'your-textdomain' ),
       'resolve' => function( $media_details, $args, $context, $info ) {
          return ! empty( $media_details['height'] ) ? $media_details['height'] : null;
        } 
    ]
  ] );

} );

If you’re trying to use the REST API, the WPGraphQL support thread is not the right place to seek help.

For WPGraphQL, I was able to use your code and query the post type in GraphQL.

I made the following changes:

– commented out the line: 'show_in_menu' => 'hr_wallet'
– commented out the capabilities => array( 'create_posts' => 'do_not_allow' )

With these changes I was able to see the post type in the dashboard and create an entry of that post type:

Then I was able to use the GraphiQL IDE to query the wallets:

{
  hrwwalletts {
    nodes {
      id
      uri
    }
  }
}

And I got the “test” wallet that I had created:

@rmehi I believe the issue might be with using first/before together.

When paginating in WPGraphQL you want to use the following arguments together:

– forward pagination: first/after
– backward pagination: last/before

You can read more about pagination with WPGraphQL here: https://www.wpgraphql.com/2020/03/26/forward-and-backward-pagination-with-wpgraphql

@suthar05?WPGraphQL doesn’t have an “integrationImage” field out of the box.

How did you add that field to the Schema? If the query works without that field, but fails with that field, perhaps the code that adds that field to the Schema needs to be updated?

The more info you can provide, the better. What WPGraphQL extensions are you using? How are you modifying the GraphQL Schema? What steps have you taken to debug already?

Marking resolved as there’s been no response. My thought is that this is related to being logged in as a user role that doesn’t have proper capabilities.

If you believe there’s a bug that can be consistently reproduced, please open an issue on the GitHub repo: https://github.com/wp-graphql/wp-graphql/issues/new

@isaacmtait I’m not sure why the code isn’t working for you.

I pasted the code in my browser console and I was able to execute and get results back.

see: https://cloudup.com/cGL2sdtWC-b

Maybe double check your API_URL?

I’m going to mark this as resolved as I don’t believe this appears to be an issue with the WPGraphQL plugin.

For general questions and discussions like this, I recommend checking out the WPGraphQL Slack (join here)

@seanhalley I’m marking this issue as resolved here as there’s now a GitHub Issue (https://github.com/wp-graphql/wp-graphql/issues/2981) opened. We will track this in GitHub. Thanks!