[SPIKE] Graphql: Redundant `_row` data for Block Editor fields in URL Content Map

Research Question

• Is it possible to prevent the GraphQL _map wildcard from returning internal _row fields (e.g., blogContent_row) specifically for Block Editor properties?
• Why are these internal fields being exposed to the final user?
• Why is the exposed blogContent_row data incomplete compared to the parsed blogContent? (It appears to be missing properties for dotContent blocks data).

Timebox

4h

Acceptance Criteria

• Identification of the code responsible for injecting _row fields into the GraphQL _map response.
• Verification that hiding/removing the _row field will not negatively impact the Block Editor's functionality or the standard blogContent field.
• A technical proposal to filter out _row properties from the response to clean up the API payload.

Context

We have identified an issue specifically affecting URL Content Maps that contain a Block Editor field.

When a user performs a GraphQL query using the _map wildcard to retrieve page content, the API returns the Block Editor data twice:

1. blogContent: The correctly parsed and formatted JSON object (Expected).
2. blogContent_row: A raw, internal version of the field (Unexpected).

The Problem: The _row field is likely internal and should not be exposed to the final user. Furthermore, the data in blogContent_row appears to be "out of sync" or incomplete; specifically, it fails to return all properties for dotContent blocks, whereas the standard blogContent field works correctly.

Example Query:

query Page {
  page(url: "/blog/post/ecotourism-in-costa-rica") {
    urlContentMap {
      _map
    }
  }
}

Goal: We want to clean up the API response. Clients consuming this API rely on the processed blogContent. If they need a stringified version, they can handle that client-side. The current behavior pollutes the response with incomplete, redundant data.

Links

• Issue Video