Frontend fatal error when `Accordion_CSS` cannot be loaded

Summary

Otter Blocks can terminate frontend page rendering while generating global block styles when the Accordion CSS class is unavailable.

Expected behavior: Global styles are generated without causing a fatal page error when a registered block CSS class cannot be loaded.

Actual behavior: The request fails with Class ".../Accordion_CSS" not found during footer rendering.

Impact: Affected frontend requests render as an error page rather than completing normally.

Customer context

• Product / area: Otter Blocks global frontend CSS
• Version: 3.2.2
• Environment: WordPress 7.0.4; PHP 8.2.33, 8.3.30, and 8.4.20 in the reported occurrences
• Integration / third party: Themeisle SDK 3.3.58; crash location is not inside SDK code
• Reported error / symptom: Class ".../Accordion_CSS" not found at global-style generation
• Impact: 3 occurrences across 3 distinct production sites during frontend requests

Reproduction notes

Telemetry-confirmed production path:

1. Run Otter Blocks 3.2.2 on a frontend request that reaches wp_footer.
2. Have Accordion_CSS remain registered while the active autoloader cannot resolve it.
3. Global style generation reaches the Accordion entry and the request terminates with Class ".../Accordion_CSS" not found.

The unavailable-class condition has not been reproduced locally because the workspace has no generated vendor/ directory or distributed 3.2.2 package.

Diagnosis

Conclusion

Production telemetry confirms an uncaught Accordion_CSS class-not-found error in the frontend global-style path. The inspected code registers that class and then unconditionally instantiates every registered CSS class, including Accordion. When the active autoloader cannot resolve that registration, the request terminates before the global-style method can return.

Where this likely occurs

• Frontend footer output: inc/css/class-block-frontend.php lines 52-62, Block_Frontend::init() attaches enqueue_global_styles() to wp_footer; lines 656-667 invoke the global-style traversal and output the CSS.
• Failing traversal: inc/class-base-css.php lines 637-645, Base_CSS::cycle_through_global_styles() instantiates each self::$blocks_classes entry at line 640 without first establishing that the class can be loaded.
• Registration: inc/class-base-css.php lines 72-104, Base_CSS::autoload_block_classes() includes \ThemeIsle\GutenbergBlocks\CSS\Blocks\Accordion_CSS at line 74.
• Declared class: inc/css/blocks/class-accordion-css.php lines 8-17, ThemeIsle\GutenbergBlocks\CSS\Blocks\Accordion_CSS is declared with the matching namespace and name; its global-style method exists at lines 345-407.
• Autoload configuration: composer.json lines 61-65 declares a classmap for inc/; otter-blocks.php lines 35-42 loads vendor/autoload.php before starting the plugin when it is readable.
• Version evidence: the workspace HEAD equals tag v3.2.2 at 27858f6e61c49ce0c82de4ab1437effd67d952ac; the inspected source path did not differ between that tag and HEAD. 4b24cf680976c9334f8226129c7213d69bcabb36 introduced the global iteration path.

Engineering notes

• The source tree contains the matching Accordion CSS declaration and a classmap configuration, so the specific reason the class was unavailable in the affected production installations is not established from the available checkout.
• The failure is reachable from wp_footer regardless of whether the page contains an Accordion block, because the global traversal iterates the full registered CSS list before each class's own global-default checks run.
• A similar unconditional instantiation pattern appears in inc/class-base-css.php lines 338-350, Base_CSS::cycle_through_static_blocks(), but telemetry only confirms the global-style path.
• Base_CSS::autoload_block_classes() exposes the otter_blocks_register_css filter at inc/class-base-css.php line 104. The reported class is part of the core list, not an added Pro entry. Pro registers separate entries in plugins/otter-pro/inc/class-main.php lines 159-172.

Test coverage status

• src/blocks/test/e2e/blocks/accordion.spec.js lines 11-82 covers editor insertion and frontend accordion open/close behavior.
• tests/test-css.php lines 17-223 covers generic CSS_Utility output.
• No relevant coverage was found during inspection for classmap availability, Base_CSS::cycle_through_global_styles(), or the class-not-found failure path.

What to verify or explore next

• May be worth reproducing with the distributed 3.2.2 plugin package and checking whether its generated Composer classmap contains Accordion_CSS.
• May be worth checking update and deployment scenarios that leave the Accordion class file or generated autoload metadata unavailable while the 3.2.2 registry is active.
• If reproducible, checking the frontend wp_footer path with unavailable registered CSS classes would confirm the observed failure boundary.

Unknowns / follow-up

• The workspace does not include vendor/, so the generated production Composer classmap could not be inspected.
• No production package archive or affected-site filesystem state is available to distinguish a release-package issue from an incomplete installation or update state.

Confidence

Confidence: 86/100

Production telemetry records the same uncaught frontend error on three distinct sites running Otter Blocks 3.2.2. The reported call chain resolves directly to an unconditional instantiation of the registered Accordion_CSS class, so an unavailable class turns global-style output into a page-fatal error.

Crash telemetry

Occurrences	3
Distinct sites	3
First seen	2026-08-12 22:35 UTC
Last seen	2026-08-13 04:12 UTC
Crash location	product:inc/class-base-css.php:640
Request context	frontend
Inside Themeisle SDK	no
Product versions	3.2.2
WP versions	7.0.4
PHP versions	8.2.33, 8.3.30, 8.4.20
SDK versions	3.3.58

---

Source: automated crash report — otter-blocks, fingerprint 6d7f1473a1e0f42e6f05b8c439dea631
Generated by bug-report-triage (ID: bug-report-triage_6a7eaf03b07944.59187036)

Start with inc/class-base-css.php, especially cycle_through_global_styles() around line 640, then trace registration in autoload_block_classes() and the wp_footer path in inc/css/class-block-frontend.php. Review tests/test-css.php and the absence of coverage for this traversal. Done means a registered but unavailable Accordion_CSS class no longer causes a frontend fatal error during global-style generation.