Compatibility issue with WPGraphQL v2.3.0

[jan-clockworkwp]

Description

Currently there is a compatibility issue between latest versions of WPGraphQL and Faust packages. More info and details #2117 (comment)

Steps to reproduce

1. Updated to latest Faust packages
2. Update to latest WPGraphQL packages
3. Run dev or build the FE app

Additional context

No response

@faustwp/core Version

3.2.3

@faustwp/cli Version

3.2.3

FaustWP Plugin Version

1.8.0

WordPress Version

6.8.1

Additional environment details

No response

Please confirm that you have searched existing issues in the repo.

• Yes

[colinmurphy]

Thanks @jan-clockworkwp

We will look into this and get back to you. Thanks for creating this issue ❤

[colinmurphy]

@jan-clockworkwp

I tested this with our updated Faust Scaffold TS project (including adding blocks and blocks-editor-utils and downgrading React and React Dom to version 18) and I couldn't replicate the issue.

Currently if I run npm run codegen I get the following

colin.murphy@colin-murphy faust-scaffold-ts % npm run codegen

> codegen
> graphql-codegen

✔ Parse Configuration
✔ Generate outputs

Also same for npm run build

colin.murphy@colin-murphy faust-scaffold-ts % npm run build  

> build
> faust build

info - Faust.js v3.2.3
info - Faust.js CLI v3.2.3
   ▲ Next.js 15.3.1
   - Environments: .env.local

 ✓ Linting and checking validity of types    
   Creating an optimized production build ...
 ✓ Compiled successfully in 0ms
 ✓ Collecting page data    
info - Possible templates for resolved url: "/": [ 'front-page', 'home', 'index' ]
 ✓ Generating static pages (5/5)
 ✓ Collecting build traces    
 ✓ Finalizing page optimization    

Route (pages)                                 Size  First Load JS  Revalidate  Expire
┌ ● / (1118 ms)                              275 B         201 kB         15m      1y
├   /_app                                      0 B         201 kB
├ ● /[...wordpressNode]                      287 B         201 kB
├ ○ /404                                     190 B         201 kB
├ ƒ /api/faust/[[...route]]                    0 B         201 kB
├ ● /example (933 ms)                        654 B         201 kB         15m      1y
└ ○ /preview                                 268 B         201 kB
+ First Load JS shared by all               202 kB
  ├ chunks/framework-f75312fc4004b783.js   44.8 kB
  ├ chunks/main-172105e0c5e80bb0.js        33.9 kB
  ├ chunks/pages/_app-b966588dc127b2a1.js   121 kB
  └ other shared chunks (total)            2.43 kB

○  (Static)   prerendered as static content
●  (SSG)      prerendered as static HTML (uses getStaticProps)
ƒ  (Dynamic)  server-rendered on demand

Currently have the following plugins installed:

• ACF - 6.4.2
• Faust.js - 1.8.4
• WP Engine Atlas Extension - 0.1.1
• WPGraphQL - 2.3.0
• WPGraphQL for ACF - 2.4.1

Have you tried locally and seen if you disabled some other plugins did that have any impact?

Also I noticed in the last line of your log

error - Make sure the FAUST_SECRET_KEY value in your environment matches the value in the Faust WordPress plugin settings, or that you have "Enable Public Introspection" checked in WPGraphQL if not using FAUST_SECRET_KEY: https://gadoe.test/wp-admin/admin.php?page=graphql-settings

Can you double check your Faust Secret Key is set?

If you can send on any other logs that would be really helpful too.

[jan-clockworkwp]

Hi @colinmurphy, thank you for looking into this. Here are my thoughts:

• All errors occur only when the WPGraphQL plugin is updated to version 2.3.0.
• The generatePossibleTypes function fails, and the catch block logs two errors: one related to FAUST_SECRET_KEY, which is obviously set as it was with WPGraphQL plugin version 2.1.1. I wouldn't rely on the content of these messages; it seems that this piece of code fails due to some GraphQL changes in the plugin between versions 2.1.1 and 2.3.0.

const response = await fetch(graphqlEndpoint, {
    method: 'POST',
    headers: {
        'Content-Type': 'application/json',
        'x-faust-secret': getWpSecret() || '',
    },
    body: JSON.stringify({
        variables: {},
        query: `
        {
            __schema {
                types {
                    kind
                    name
                    possibleTypes {
                       name
                    }
                }
            }
        }
        `,
    }),
});

Consequently, it fails due to the same or a similar issue with the blockset command. It actually says that it fails on loading schema at https://gadoe.test/wp/graphql

• I have not observed any logs (warnings or errors) in the WP environment.
• I have tried the same configuration with React downgraded to version 18.
• I also ran the WPGraphQL plugin version 2.3.0 without any other WPGraphQL-related plugins in our Bedrock WP instance.

Here is the content of our Faust config file:

import { FaustConfig, setConfig } from '@faustwp/core';

import CustomToolbar from '@/plugins/CustomToolbarPlugin';
import { ExtendPossibleTemplateList } from '@/plugins/ExtendPossibleTemplateList';
import { RelayStylePaginationPlugin } from '@/plugins/RelayStylePaginationPlugin';
import possibleTypes from '@/possibleTypes.json';
import templates from '@/wp-templates';

/**
 * @todo: The experimentalToolbar feature is currently causing https://github.com/wpengine/faustjs/issues/1657 when enabled
 * and no user is logged in. This feature is disabled for the time being. https://github.com/wpengine/faustjs/issues/1924
 */

const faustConfig: FaustConfig = {
  templates,
  experimentalToolbar: true,
  usePersistedQueries: true,
  plugins: [
    new CustomToolbar(),
    new RelayStylePaginationPlugin(),
    new ExtendPossibleTemplateList(),
  ],
  possibleTypes,
};

export default setConfig(faustConfig);

And here is the content of our next config file:

import path from "node:path";
import { fileURLToPath } from "node:url";

import { getWpHostname, getWpUrl, withFaust } from '@faustwp/core';
import NextBundleAnalyzer from '@next/bundle-analyzer';

import { redirects } from "./constants/redirects.js";

// Define __dirname for ES module scope
const __filename = fileURLToPath(import.meta.url);
const __dirname = path.dirname(__filename);

// @see: https://nextjs.org/docs/14/pages/building-your-application/optimizing/bundle-analyzer
const withBundleAnalyzer = NextBundleAnalyzer({
  enabled: process.env.ANALYZE === 'true',
});

/**
 * @type {import('next').NextConfig}
 **/
const nextConfig = {
  reactStrictMode: true,
  sassOptions: {
    includePaths: [path.join(__dirname, `src/styles`)],
    quietDeps: true,
    silenceDeprecations: [`legacy-js-api`, `import`],
  },
  trailingSlash: true,
  images: {
    remotePatterns: [
      {
        protocol: getWpUrl().startsWith('https') ? 'https' : 'http',
        hostname: getWpHostname(),
        port: '',
      },
      {
        protocol: 'https',
        hostname: 'live.staticflickr.com',
        port: '',
      },
    ],
  },
  i18n: {
    locales: ['en'],
    defaultLocale: 'en',
  },
  pageExtensions: ['js', 'jsx', 'ts', 'tsx'],
  output: 'standalone',
  compress: process.env.APP_ENV !== 'production',
  assetPrefix: process.env.CDN_URL,
  async headers() {
    if (process.env.APP_ENV !== 'production') {
      return [];
    }

    return [
      {
        source: '/:all*(css|js|gif|svg|jpg|jpeg|png|woff|woff2)',
        locale: false,
        headers: [
          {
            key: 'Cache-Control',
            value: 'public, max-age=31536000',
          }
        ],
      }
    ];
  },
  redirects: () => redirects.map((redirect) => ({ ...redirect, permanent: true })),
};

export default withBundleAnalyzer(withFaust(nextConfig));

Our site has numerous customizations due to various Faust and Faust/Bedrock combination limitations. It would be naive to claim that everything is fine if it works with a vanilla project setup but fails in a real live production application. One thing I have found out though is that GraphQL WP IDE throws console log error (attached) when on version 2.3.0 about introspection failing. I would assume that this is the root cause but have not managed to figure out why it is happening. I have as well updated roots/acorn that is mentioned in the console log error to the latest version to rule it out from the possible reasons for failing introspection. And I wonder if any of two new features introduced in WPGraphQL version 2.3.0 could not be a reason to failing introspection query. Any ideas? Appreciate anyone looking into this. Meanwhile we are staying on v2.1.1.

gadoe.test-1749550680593.log