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
- Install Otter Pro 3.2.3 with the Modal block registered.
- Make the mapped Modal renderer file unavailable or unreadable in the deployed plugin files.
- 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)
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
Failed opening required .../class-modal-block.phpReproduction notes
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
requirecall 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 derivesinc/render/class-modal-block.phpfromThemeIsle\OtterPro\Render\Modal_Blockand delegates torequire_file().plugins/otter-pro/autoloader.php—Autoloader::require_file()lines 147-150 executes an unconditionalrequire, matching the production crash location at line 148.plugins/otter-pro/inc/class-main.php—Main::register_dynamic_blocks()lines 125-148 mapsmodaltoThemeIsle\OtterPro\Render\Modal_Blockat line 143.inc/class-registration.php—Registration::register_blocks()lines 855-971 applies the Pro dynamic-block mapping and callsclass_exists()at line 971, which reaches the registered Pro autoloader.plugins/otter-pro/inc/render/class-modal-block.php—Modal_Blocklines 8-17 exists in the inspectedv3.2.3source tree. The mapping and renderer were introduced together ince610a5fe(2024-07-23); no changes to the affected paths were found betweenv3.2.2andv3.2.3.Engineering notes
require.v3.2.3contains 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.Test coverage status
tests/test-registration.phpcontainstest_register_blocks_survives_dynamic_renderer_class_with_no_autoload_entry()at lines 177-180 andtest_register_blocks_survives_dynamic_renderer_class_whose_file_is_missing()at lines 203-215.Registration_Test::register_composer_like_loader()at lines 146-155, usesincluderather than the Pro autoloader's unconditionalrequire. It does not exerciseplugins/otter-pro/autoloader.phpor the Modal mapping.What to verify or explore next
plugins/otter-pro/inc/render/class-modal-block.php.Unknowns / follow-up
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
product:autoloader.php:148Source: automated crash report — otter-pro, fingerprint
1b008f8ddcd75d2bf0bc5b46dae1ae9bGenerated by bug-report-triage (ID: bug-report-triage_6a87e98e2308b7.23267161)