Frontend CSS generation fatals when `CSS_Utility` is unavailable

Summary

Frontend requests can terminate with a fatal error while Otter generates CSS for a Core Image block.

Expected behavior: if a CSS-generation dependency cannot be loaded, the request remains available and the affected generated styles can be omitted.

Actual behavior: the request throws Class "...CSS_Utility" not found during Core Image CSS rendering.

Impact: affected frontend pages can fail to render while widget CSS is generated.

Customer context

• Product / area: Otter Blocks frontend widget CSS generation
• Version: 3.2.3
• Environment: WordPress 7.0.4 and 7.1; PHP 8.2.33 and 8.5.6
• Integration / third party: Themeisle SDK 3.3.59 reported; crash location is not inside SDK code
• Reported error / symptom: Class "...CSS_Utility" not found
• Impact: 2 telemetry occurrences across 2 production sites between 2026-08-21 06:25 and 09:26 UTC.

Reproduction notes

1. Use Otter Blocks 3.2.3 with widget CSS generation reached from a frontend request.
2. Include a core/image block in the parsed widget content.
3. Make ThemeIsle\GutenbergBlocks\CSS\CSS_Utility unavailable to the active Composer autoloader while the handler source remains present.
4. Observed in production: Core_Image_Plugin_CSS::render_css() throws Class "...CSS_Utility" not found.

Exact condition that caused the unavailable classmap on the two reported sites is not available.

Diagnosis

Conclusion

Production telemetry identifies Core_Image_Plugin_CSS::render_css() as the throwing location in the 3.2.3 release. The class being constructed is present in the release source, but is only discoverable through Composer's generated classmap. The inspected call path instantiates it without a loadability check, so an unavailable mapping becomes an uncaught frontend exception. This is separate from the existing guard for top-level entries in Main::autoload_classes(), which does not cover this nested dependency.

Where this likely occurs

• inc/css/blocks/class-core-image-plugin-css.php — Core_Image_Plugin_CSS::render_css() lines 41-42 imports and directly constructs CSS_Utility; this matches the telemetry location.
• inc/css/class-css-utility.php — CSS_Utility line 62 defines the missing class, confirming the release source contains it.
• composer.json — autoload.classmap lines 61-65 maps the entire inc/ directory through Composer rather than explicitly loading this class.
• inc/class-base-css.php — Base_CSS::cycle_through_static_blocks() lines 338-359 invokes the matching CSS handler; the telemetry stack reaches this path through widget CSS generation.
• Tag v3.2.3 (0c6ff15e, 2026-08-20) contains byte-identical versions of both class-core-image-plugin-css.php and class-css-utility.php to the inspected source. Later commit 3ad45e18 adds a class_exists() guard only around top-level classes in Main::autoload_classes().

Engineering notes

The error occurs after Core_Image_Plugin_CSS itself has been loaded, during construction of its utility dependency. The available evidence is consistent with a stale, incomplete, or otherwise mismatched Composer classmap; telemetry alone does not establish which condition made that map unavailable on the affected sites. The product bootstrap loads vendor/autoload.php when readable in otter-blocks.php lines 35-42. The report is limited to the Core Image handler reached while saving widget styles on the frontend.

Test coverage status

tests/test-css.php lines 21-200 exercises CSS_Utility directly under a working test autoloader. tests/test-main-autoload.php lines 43-89 covers unavailable top-level entries and verifies top-level listed classes are loadable. No relevant coverage was found during inspection for an unavailable CSS_Utility during Core_Image_Plugin_CSS::render_css() or the widget CSS traversal path.

What to verify or explore next

• May be worth reproducing a frontend request containing a Core Image block in active widget content with the CSS_Utility classmap entry unavailable.
• If reproducible, run the widget CSS generation path on a package whose Composer classmap differs from its inc/ files.
• Check whether other CSS handlers that directly construct CSS_Utility exhibit the same failure condition.

Unknowns / follow-up

• The telemetry does not include the affected package's generated classmap or update state.
• No release artifact was available locally to verify whether the shipped 3.2.3 classmap lacked the entry versus the affected installations becoming mismatched after deployment.

Confidence

Confidence: 91/100

Production telemetry captures a repeatable uncaught frontend exception at the v3.2.3 CSS_Utility construction site. The class exists in the release source but depends exclusively on the generated Composer classmap; this traversal path does not verify that dependency is loadable before instantiation.

Crash telemetry

Occurrences	2
Distinct sites	2
First seen	2026-08-21 06:25 UTC
Last seen	2026-08-21 09:26 UTC
Crash location	product:inc/css/blocks/class-core-image-plugin-css.php:42
Request context	frontend
Inside Themeisle SDK	no
Product versions	3.2.3
WP versions	7.0.4, 7.1
PHP versions	8.2.33, 8.5.6
SDK versions	3.3.59

---

Source: automated crash report — otter-blocks, fingerprint fc34a6430cf025cd055962aad99a3af7
Generated by bug-report-triage (ID: bug-report-triage_6a893b0c2c6df7.50080523)

Start with inc/css/blocks/class-core-image-plugin-css.php and Core_Image_Plugin_CSS::render_css(), then inspect inc/css/class-css-utility.php and the Composer autoload configuration in composer.json. Reproduce the frontend widget CSS path with a core/image block while CSS_Utility is unavailable, and review tests/test-css.php and tests/test-main-autoload.php for existing patterns. Done means the affected request no longer fatals and coverage verifies the unavailable dependency case.