Summary
Otter Blocks can terminate a frontend request while registering dynamic blocks when the Posts Grid renderer class cannot be loaded.
Expected behavior: Block registration continues and the affected block is registered without a server-side renderer when its renderer class is unavailable.
Actual behavior: Registration throws an uncaught Class ".../Posts_Grid_Block" not found error.
Impact: Affected requests fail before page rendering completes.
Customer context
- Product / area: Otter Blocks dynamic block registration
- Version: 3.2.1
- Environment: WordPress 7.0.2 and 7.0.3; PHP 8.3.32 and 8.4.23
- Request context: Frontend
- Reported error / symptom: Uncaught
Class ".../Posts_Grid_Block" not found at block registration
- Impact: 2 occurrences across 2 production sites between 2026-08-01 and 2026-08-07.
Reproduction notes
- Use Otter Blocks 3.2.1.
- During
init, register dynamic blocks with the Posts Grid renderer mapping present while the renderer class cannot be resolved by the active autoloader.
- Load a frontend request.
Observed in production: registration reaches the mapped class instantiation and throws Class ".../Posts_Grid_Block" not found.
Repository reproduction status: The later focused tests model the same unavailable-class condition; the original affected production artifact was not available.
Diagnosis
Conclusion
The telemetry location maps directly to unconditional instantiation of the configured Posts Grid renderer. In v3.2.1, the registration flow reaches new $classname() after identifying posts-grid as dynamic, with no check that the class was loaded. Commit 476104b7 (2026-08-06) explicitly changes this condition to handle unavailable dynamic renderer classes and adds focused tests for absent or unreadable renderer files. This confirms the reported crash is a product defect in the 3.2.1 registration path.
Where this likely occurs
inc/class-registration.php — Registration::register_blocks() lines 856-864 maps posts-grid to ThemeIsle\GutenbergBlocks\Render\Posts_Grid_Block.inc/class-registration.php — Registration::register_blocks() lines 971-973 in v3.2.1 instantiates the mapped class solely when a dynamic-block mapping exists; the production telemetry points to line 973.inc/render/class-posts-grid-block.php — Posts_Grid_Block lines 8-13 declares the expected namespace and class in tracked source, indicating the failure occurs when that declaration is unavailable to the running request rather than from a source-level spelling mismatch.- Commit
476104b7f39e1ef80ba53de557ab143a5e112cba, titled fix: ensure dynamic block renderer class exists before instantiation, modifies this exact conditional after the 3.2.1 release tag 059432d3.
Engineering notes
The tracked v3.2.1 source declares the renderer and Composer maps inc/ for autoloading in composer.json lines 61-65. The reported class-not-found state therefore suggests a deployment or autoloader condition in which the renderer declaration is not available, but the pre-fix registration code turns that condition into a fatal frontend failure. The defect is confined to the inspected dynamic-renderer registration branch; the telemetry does not establish why the Posts Grid class was unavailable on the affected installations.
Test coverage status
tests/test-post-grid-block.php covers direct Posts_Grid_Block rendering, not registration when a renderer class is unavailable. Commit 476104b7 adds focused coverage in tests/test-registration.php: test_register_blocks_survives_dynamic_renderer_class_with_no_autoload_entry(), test_register_blocks_survives_dynamic_renderer_class_whose_file_is_missing(), and test_register_blocks_survives_dynamic_renderer_class_whose_file_is_unreadable().
What to verify or explore next
- Verify whether the release containing
476104b7 has been published after 3.2.1 and whether fresh telemetry continues after affected sites update.
- Run the focused
Test_Registration cases and exercise frontend initialization with a dynamic renderer whose classmap entry is absent.
- Inspect the affected release artifact and autoload metadata, if retained, to determine why the Posts Grid declaration was unavailable.
Unknowns / follow-up
- The production artifacts and autoload metadata from the two affected installations were not available for inspection.
- The telemetry does not identify a conflicting plugin, filesystem state, or deployment event that made this one renderer class unavailable.
Confidence
Confidence: 97/100
Production telemetry records the uncaught frontend exception in Otter Blocks 3.2.1 on two sites, and the exact pre-release code path instantiates the mapped renderer without confirming that its class was loaded. A subsequent repository commit explicitly guards this failure mode and adds coverage for missing renderer class files.
Crash telemetry
|
|
| Occurrences |
2 |
| Distinct sites |
2 |
| First seen |
2026-08-01 17:42 UTC |
| Last seen |
2026-08-07 19:48 UTC |
| Crash location |
product:inc/class-registration.php:973 |
| Request context |
frontend |
| Inside Themeisle SDK |
no |
| Product versions |
3.2.1 |
| WP versions |
7.0.2, 7.0.3 |
| PHP versions |
8.3.32, 8.4.23 |
| SDK versions |
3.3.58 |
Source: automated crash report — otter-blocks, fingerprint 5841fc718f370fa7c93f23e0ca87600c
Generated by bug-report-triage (ID: bug-report-triage_6a76c5ff6422e0.19052458)
Summary
Otter Blocks can terminate a frontend request while registering dynamic blocks when the Posts Grid renderer class cannot be loaded.
Expected behavior: Block registration continues and the affected block is registered without a server-side renderer when its renderer class is unavailable.
Actual behavior: Registration throws an uncaught
Class ".../Posts_Grid_Block" not founderror.Impact: Affected requests fail before page rendering completes.
Customer context
Class ".../Posts_Grid_Block" not foundat block registrationReproduction notes
init, register dynamic blocks with the Posts Grid renderer mapping present while the renderer class cannot be resolved by the active autoloader.Observed in production: registration reaches the mapped class instantiation and throws
Class ".../Posts_Grid_Block" not found.Repository reproduction status: The later focused tests model the same unavailable-class condition; the original affected production artifact was not available.
Diagnosis
Conclusion
The telemetry location maps directly to unconditional instantiation of the configured Posts Grid renderer. In
v3.2.1, the registration flow reachesnew $classname()after identifyingposts-gridas dynamic, with no check that the class was loaded. Commit476104b7(2026-08-06) explicitly changes this condition to handle unavailable dynamic renderer classes and adds focused tests for absent or unreadable renderer files. This confirms the reported crash is a product defect in the 3.2.1 registration path.Where this likely occurs
inc/class-registration.php—Registration::register_blocks()lines 856-864 mapsposts-gridtoThemeIsle\GutenbergBlocks\Render\Posts_Grid_Block.inc/class-registration.php—Registration::register_blocks()lines 971-973 inv3.2.1instantiates the mapped class solely when a dynamic-block mapping exists; the production telemetry points to line 973.inc/render/class-posts-grid-block.php—Posts_Grid_Blocklines 8-13 declares the expected namespace and class in tracked source, indicating the failure occurs when that declaration is unavailable to the running request rather than from a source-level spelling mismatch.476104b7f39e1ef80ba53de557ab143a5e112cba, titledfix: ensure dynamic block renderer class exists before instantiation, modifies this exact conditional after the 3.2.1 release tag059432d3.Engineering notes
The tracked
v3.2.1source declares the renderer and Composer mapsinc/for autoloading incomposer.jsonlines 61-65. The reported class-not-found state therefore suggests a deployment or autoloader condition in which the renderer declaration is not available, but the pre-fix registration code turns that condition into a fatal frontend failure. The defect is confined to the inspected dynamic-renderer registration branch; the telemetry does not establish why the Posts Grid class was unavailable on the affected installations.Test coverage status
tests/test-post-grid-block.phpcovers directPosts_Grid_Blockrendering, not registration when a renderer class is unavailable. Commit476104b7adds focused coverage intests/test-registration.php:test_register_blocks_survives_dynamic_renderer_class_with_no_autoload_entry(),test_register_blocks_survives_dynamic_renderer_class_whose_file_is_missing(), andtest_register_blocks_survives_dynamic_renderer_class_whose_file_is_unreadable().What to verify or explore next
476104b7has been published after 3.2.1 and whether fresh telemetry continues after affected sites update.Test_Registrationcases and exercise frontend initialization with a dynamic renderer whose classmap entry is absent.Unknowns / follow-up
Confidence
Confidence: 97/100
Production telemetry records the uncaught frontend exception in Otter Blocks 3.2.1 on two sites, and the exact pre-release code path instantiates the mapped renderer without confirming that its class was loaded. A subsequent repository commit explicitly guards this failure mode and adds coverage for missing renderer class files.
Crash telemetry
product:inc/class-registration.php:973Source: automated crash report — otter-blocks, fingerprint
5841fc718f370fa7c93f23e0ca87600cGenerated by bug-report-triage (ID: bug-report-triage_6a76c5ff6422e0.19052458)