Block Editor field corruption causes entire page/contentlet to become inaccessible instead of degrading gracefully

Problem Statement

When a contentlet has a Block Editor (StoryBlock) field with corrupted or malformed JSON, some code paths in the platform throw an unhandled exception that makes the entire page or contentlet return null/404 — rather than isolating the failure to the corrupted field and continuing to serve the rest of the content.

This was observed in the April 7, 2026 incident (Freshdesk #36268) where ALL `/case-studies/*` pages returned 404 publicly and null in the Page API and GraphQL because a single contentlet had a corrupted Block Editor field. A single broken field took down every page that included that contentlet.

Steps to Reproduce

1. Create a contentlet with a Block Editor (StoryBlock) field
2. Corrupt the JSON value of that field directly in the database or via a failed save
3. Request any page that includes that contentlet via `/api/v1/page/json/{url}` or GraphQL
4. Observe the entire page returns null/404 instead of rendering with the field as null

Root Cause

The platform has inconsistent exception handling across code paths when processing Block Editor fields:

Protected (correct behavior)

Unprotected (exception propagates)

Relevant files:

• dotCMS/src/main/java/com/dotmarketing/portlets/contentlet/transform/strategy/StoryBlockViewStrategy.java — reference pattern, already correct
• dotCMS/src/main/java/com/dotcms/ai/util/ContentToStringUtil.java — parseBlockEditor() method, unprotected
• dotCMS/src/main/java/com/dotcms/rendering/velocity/viewtools/content/StoryBlockMap.java — constructors throw JSONException
• GraphQL contentlet resolvers — need audit

Acceptance Criteria

• ContentToStringUtil.parseBlockEditor() catches JSONException/Exception from StoryBlockMap construction and returns Optional.empty() instead of propagating the exception
• GraphQL contentlet resolvers are audited to confirm they either route through StoryBlockViewStrategy or have equivalent protection for Block Editor fields
• A page containing a contentlet with a corrupted Block Editor field returns the page with that field as null, not a 404 or null page
• Integration test added: contentlet with malformed Block Editor JSON → Page API returns contentlet with the field as null, rest of page unaffected

dotCMS Version

Observed on corpsites instance (cloud). Affects all versions where Block Editor fields are in use.

Severity

High - Major functionality broken

A single corrupted field in one contentlet can silently take down all pages that include that contentlet, with no warning in the CMS admin and no graceful degradation for end users.

Links

• Freshdesk #36994 — [INTERNAL] Pages Return 404 Publicly and Show as Missing in CMS — Recurring Pattern Across Content Types
• Freshdesk #36268 — CaseStudies Block Editor incident (April 7, 2026)

Begin with ContentToStringUtil.java and its parseBlockEditor() call, then compare its handling with StoryBlockViewStrategy.java and inspect StoryBlockMap.java constructors. Audit the GraphQL contentlet resolver entry points and existing Page API integration tests. Done means malformed Block Editor JSON leaves that field null while the contentlet and containing page remain available through Page API and GraphQL.