🐛 Problem

When plugins call wp_print_inline_script_tag() or similar output functions during the wp_enqueue_scripts action, it causes HTML to be output directly into the response stream. This breaks GraphQL JSON responses because HTML markup gets mixed with JSON, causing parsing errors on the client side.

Root Cause

WPGraphQL calls do_action( 'wp_enqueue_scripts' ) in multiple places to determine which scripts/styles are enqueued for specific nodes:

• When querying enqueuedScripts or enqueuedStylesheets fields on posts, pages, terms, users, etc.
• When querying registeredScripts or registeredStylesheets from the root query

If any plugin outputs HTML during this action (which is not uncommon), it corrupts the JSON response.

Example Error

{
  "errors": [
    {
      "message": "Unexpected token '<', \"\t<script>\nw\"... is not valid JSON",
      "stack": "SyntaxError: Unexpected token '<', \"\t<script>\nw\"... is not valid JSON"
    }
  ]
}

🔧 Solution

This PR implements Router-level output buffering during GraphQL HTTP request execution.

✅ Advantages of Router-Level Fix

• Single Point of Control: All GraphQL HTTP requests are protected with one fix
• Comprehensive Coverage: Catches output from ANY source during GraphQL execution
• Future-Proof: Automatically handles new sources of unwanted output
• Clean Architecture: Router is responsible for HTTP response integrity
• Better Performance: Single output buffer vs. multiple nested buffers

🔧 Implementation Details

The fix wraps the entire GraphQL execution in output buffering:

try {
    // Start output buffering to prevent unwanted output from breaking JSON response
    ob_start();
    
    $response = self::$request->execute_http();
    
    // Discard any captured output that could break the JSON response
    ob_end_clean();
    
    // ... continue processing
} catch ( \Throwable $error ) {
    // Ensure cleanup even on exceptions
    if ( ob_get_level() > 0 ) {
        ob_end_clean();
    }
    // ... existing error handling
}

🧪 Testing

Test Case Added

• testPrintInlineScriptDoesNotBreakEnqueuedScriptsWithFix() verifies that calling wp_print_inline_script_tag() during wp_enqueue_scripts don't break GraphQL responses

Test Results

• ✅ HTML output is captured and discarded
• ✅ GraphQL response remains valid JSON
• ✅ Enqueued scripts are properly returned
• ✅ No errors in GraphQL response

Manual Testing

The fix was tested with the exact scenario from the issue:

add_action( 'wp_enqueue_scripts', function () {
    wp_print_inline_script_tag( 'window.Whoops = 1;' );
} );

Before fix: GraphQL response broken with HTML mixed in JSON
After fix: Clean JSON response with proper enqueued scripts data

📁 Files Changed

• src/Router.php - Added comprehensive output buffering around GraphQL execution
• tests/wpunit/EnqueuedScriptsTest.php - Added regression test

🔄 Backward Compatibility

This change is fully backward compatible:

• No breaking changes to existing APIs
• No changes to GraphQL schema
• Only affects HTTP GraphQL requests (not internal graphql() calls)
• Transparent to end users and developers

🎯 Impact

This fix protects against:

• ✅ wp_print_inline_script_tag() calls during wp_enqueue_scripts (original issue)
• ✅ Any other unwanted output during GraphQL execution
• ✅ Future plugins that might output HTML during GraphQL processing
• ✅ Debug output, warning messages, or other unintended output
• ✅ closes Including enqueuedScripts field can lead to broken output if scripts are printed in this action #3397

NOTE: I can't point to specific issues, but I've helped folks debug issues in the past where responses to certain queries would break the response in the IDE and we were never able to holistically determine a solution. I have a hunch that this will solve a lot of edge cases that were previously difficult to reproduce consistently.

🚀 Alternative Approaches Considered

1. Resolver/Model level fixes - Would require adding output buffering to multiple individual resolvers

I initially explored adding output buffering to the Post, Term, User, etc Model where they call the wp_enqueue_scripts action. However, this would lead to:

• ❌ Incomplete coverage
• ❌ Higher maintenance burden
• ❌ Easy to miss new cases

2. Router-level fix (chosen approach)

Instead of duplicating the model-level output buffering effort, I implemented it in the Router which covers these cases and likely other misc edge cases as noted above.

• ✅ Comprehensive coverage
• ✅ Single point of control
• ✅ Future-proof
• ✅ Clean architecture