include style editor schemas in the GQL response

[dario-daza]

Proposed Changes

• change 1
• change 2

Checklist

• Tests
• Translations
• Security Implications Contemplated (add notes if applicable)

Additional Info

** any additional useful context or info **

Screenshots

Original	Updated
** original screenshot **	** updated screenshot **

This PR fixes: #35454

[claude]

Claude finished @dario-daza's task in 2m 41s —— View job

---

Rollback Safety Analysis

• Read rollback-unsafe categories reference
• Get full PR diff
• Analyze diff against all categories
• Post result and apply label

---

Pull Request Unsafe to Rollback!!!

• Category: M-3 — REST / GraphQL / Headless API Contract Change
• Risk Level: 🟡 MEDIUM

Why it's unsafe:

This PR makes two API contract changes that are tightly coupled, creating a rollback hazard:

1. GQL field added + SDK updated in the same PR. styleEditorSchemas is registered as a new field on the GraphQL Page type (backend). At the same time, the TypeScript SDK's buildPageQuery is updated to include styleEditorSchemas in every single page query it emits. After rolling back the dotCMS server from N to N-1, the styleEditorSchemas field no longer exists in the GQL schema. Any headless client running N's SDK will send queries containing styleEditorSchemas — N-1 rejects them with a GraphQL validation error: "Cannot query field 'styleEditorSchemas' on type 'Page'".

2. REST endpoint removed. GET /api/v1/page/{pageId}/contenttype-schema exists in origin/main and is deleted by this PR. Rollback restores the endpoint (safe for the server), but during the N deployment window any caller of that endpoint gets a 404. Since the SDK no longer calls this endpoint in N, SDK-based clients are unaffected — but direct REST API consumers are broken during the deployment window.

Code that makes it unsafe:

• dotCMS/src/main/java/com/dotcms/graphql/business/PageAPIGraphQLTypesProvider.java lines 246–247 — registers styleEditorSchemas as a new GQL field on Page
• core-web/libs/sdk/client/src/lib/client/page/utils.ts line 199 — adds styleEditorSchemas to the query string emitted by buildPageQuery; every SDK page request now includes this field, which does not exist on N-1
• dotCMS/src/main/java/com/dotcms/rest/api/v1/page/PageResource.java lines 1909–1966 (deleted) — removes the /{pageId}/contenttype-schema REST endpoint that exists in origin/main

Alternative (if possible):

Decouple the backend and client changes across two releases:

• Release N: Register styleEditorSchemas in the GQL schema only (backend change). Do not update the SDK to query it yet. N-1 is unaffected because no client is requesting the new field.
• Release N+1 (once N-1 is outside the rollback window): Update the SDK's buildPageQuery to include styleEditorSchemas. All in-flight queries from the old SDK will still work against both N+1 and N.

[claude]

Pull Request Unsafe to Rollback!!!

• Category: M-3 — REST / GraphQL / Headless API Contract Change
• Risk Level: 🟡 MEDIUM
• Why it's unsafe: N adds a new styleEditorSchemas field to the GraphQL Page schema AND updates the TypeScript SDK in the same PR to include styleEditorSchemas in every page query (via buildPageQuery). After rolling back to N-1, the field no longer exists in the GQL schema. Any client running N's SDK will send queries containing styleEditorSchemas, and the N-1 server will reject them with a GraphQL validation error: "Cannot query field 'styleEditorSchemas' on type 'Page'".
• Code that makes it unsafe:
  • dotCMS/src/main/java/com/dotcms/graphql/business/PageAPIGraphQLTypesProvider.java lines 172-173 — registers the new field in the GQL schema
  • core-web/libs/sdk/client/src/lib/client/page/utils.ts line 115 — adds styleEditorSchemas to the query string emitted by buildPageQuery, meaning every SDK page query will include this field
• Alternative (if possible): Ship the backend GQL field registration in Release N without updating the SDK query. In Release N+1 (once N-1 is outside the rollback window), update the SDK to query styleEditorSchemas. This decouples the schema addition from the client consumption, leaving N-1 able to serve all in-flight queries unmodified.