Otter Pro fatals when the Modal renderer file is absent from the deployed artifact

Summary

Otter Pro can terminate frontend block registration when the Modal block's renderer file is unavailable.

Expected behavior: If a dynamic block renderer cannot be loaded from a deployed artifact, block registration continues through its metadata-only path.

Actual behavior: Loading the Modal renderer triggers a fatal "Failed opening required .../class-modal-block.php" error.

Impact: Affected sites return a frontend fatal during WordPress initialization instead of completing block registration.

Customer context

• Product / area: Otter Pro dynamic Modal block registration
• Version: 3.2.3
• Environment: Frontend requests; PHP 8.1.34 and 8.3.33; WordPress 6.9.7 and 7.1
• Reported error / symptom: Failed opening required .../class-modal-block.php
• Impact: 2 telemetry occurrences across 2 distinct sites in the observed window.

Reproduction notes

1. Install Otter Pro 3.2.3 with the Modal block registered.
2. Make the mapped Modal renderer file unavailable or unreadable in the deployed plugin files.
3. Trigger WordPress block registration during a frontend request.

Reported result: the autoloader fatals while opening class-modal-block.php.

Reproduction status: confirmed from production stack telemetry and the inspected autoloader path; the artifact condition that made the file unavailable has not been reproduced locally.

Diagnosis

Conclusion

Telemetry records a fatal at the Otter Pro autoloader's require call while WordPress registers blocks and attempts to load the Modal renderer. The inspected autoloader directly requires its calculated path without first establishing that the file is available. The repository's registration tests define an unavailable deployed renderer as a case that degrades to metadata-only registration, but that test uses a different autoloader behavior. This confirms the fatal failure path when the renderer file is absent or inaccessible; the reason it was unavailable on the two reported deployments remains unverified.

Where this likely occurs

• plugins/otter-pro/autoloader.php — Autoloader::load_mapped_file() lines 108-134 derives inc/render/class-modal-block.php from ThemeIsle\OtterPro\Render\Modal_Block and delegates to require_file().
• plugins/otter-pro/autoloader.php — Autoloader::require_file() lines 147-150 executes an unconditional require, matching the production crash location at line 148.
• plugins/otter-pro/inc/class-main.php — Main::register_dynamic_blocks() lines 125-148 maps modal to ThemeIsle\OtterPro\Render\Modal_Block at line 143.
• inc/class-registration.php — Registration::register_blocks() lines 855-971 applies the Pro dynamic-block mapping and calls class_exists() at line 971, which reaches the registered Pro autoloader.
• plugins/otter-pro/inc/render/class-modal-block.php — Modal_Block lines 8-17 exists in the inspected v3.2.3 source tree. The mapping and renderer were introduced together in ce610a5fe (2024-07-23); no changes to the affected paths were found between v3.2.2 and v3.2.3.

Engineering notes

• The telemetry stack is a frontend initialization path, not an editor-only invocation.
• The autoloader's docblock states it requires a file "if a file exists," but the inspected implementation has no availability check before require.
• v3.2.3 contains the renderer at the expected lowercase repository path. The observed missing or inaccessible runtime file therefore suggests a deployed-artifact, filesystem, or installation-state condition that is not established by the available evidence.
• The product code path is in the bundled Pro plugin, not the Themeisle SDK; telemetry also marks the crash as outside SDK code.

Test coverage status

• tests/test-registration.php contains test_register_blocks_survives_dynamic_renderer_class_with_no_autoload_entry() at lines 177-180 and test_register_blocks_survives_dynamic_renderer_class_whose_file_is_missing() at lines 203-215.
• The missing-file test's helper, Registration_Test::register_composer_like_loader() at lines 146-155, uses include rather than the Pro autoloader's unconditional require. It does not exercise plugins/otter-pro/autoloader.php or the Modal mapping.

What to verify or explore next

• Reproduce registration with the Pro Modal renderer mapped but absent or unreadable, using the production Pro autoloader.
• Inspect the generated 3.2.3 distribution artifact and installation/update flow for the presence and readability of plugins/otter-pro/inc/render/class-modal-block.php.
• Run the relevant PHP registration tests and add a runtime reproduction that reaches the Pro autoloader path.

Unknowns / follow-up

• The available telemetry redacts the full filesystem path and does not establish why the file was unavailable on the affected sites.
• No release artifact from either affected deployment was available for comparison.

Confidence

Confidence: 92/100

Production telemetry from two sites records a frontend fatal in Otter Pro 3.2.3 when the modal renderer file cannot be opened. The inspected production autoloader unconditionally requires that mapped file, while the registration test suite explicitly defines missing renderer files as a non-fatal fallback case; this is strong evidence of a product defect.

Crash telemetry

Occurrences	2
Distinct sites	2
First seen	2026-08-20 16:16 UTC
Last seen	2026-08-20 21:08 UTC
Crash location	product:autoloader.php:148
Request context	frontend
Inside Themeisle SDK	no
Product versions	3.2.3
WP versions	6.9.7, 7.1
PHP versions	8.1.34, 8.3.33
SDK versions	3.3.59

---

Source: automated crash report — otter-pro, fingerprint 1b008f8ddcd75d2bf0bc5b46dae1ae9b
Generated by bug-report-triage (ID: bug-report-triage_6a87e98e2308b7.23267161)

Start with plugins/otter-pro/autoloader.php, especially Autoloader::load_mapped_file() and require_file(), then trace the Modal mapping in plugins/otter-pro/inc/class-main.php and registration through inc/class-registration.php. Run the relevant cases in tests/test-registration.php and add coverage that reaches the Pro autoloader when class-modal-block.php is unavailable. Done means frontend block registration falls back without a fatal.