AMP renderer initialization fatals when Circle Counter class is unloadable

Summary

Otter Blocks can terminate initialization with Class "...Circle_Counter_Block" not found while initializing AMP renderers.

Expected behavior: Plugin initialization continues when an optional AMP renderer cannot be loaded.

Actual behavior: The AMP renderer initialization path constructs the unavailable class and raises an uncaught error.

Impact: The affected request fails; telemetry captured the failure during AJAX requests on two production sites.

Customer context

• Product / area: Otter Blocks, AMP renderer initialization
• Version: 3.2.2
• Environment: WordPress 7.0.4; PHP 8.2.33 and 8.3.33
• Integration / third party: Composer autoloader; Themeisle SDK 3.3.58 and 3.3.59 were present, but the crash is outside SDK code
• Reported error / symptom: Class "...Circle_Counter_Block" not found during an AJAX request
• Impact: 2 occurrences across 2 distinct production sites in the telemetry query window

Reproduction notes

1. Use Otter Blocks 3.2.2 with the Circle Counter AMP renderer file present but unavailable to the active Composer autoloader.
2. Trigger WordPress initialization, including an AJAX request.
3. Registration::init_amp_blocks() reaches the Circle Counter entry and raises the reported class-not-found error.

Production reproduction is confirmed by two telemetry occurrences; the stale or incomplete autoload condition was not recreated locally.

Diagnosis

Conclusion

Production telemetry pinpoints an uncaught Circle_Counter_Block class-loading error at the direct AMP renderer construction. In v3.2.2, the class file exists and declares the expected fully qualified class, but the registration loop has no loadability check before construction. This confirms a product crash path when the generated Composer classmap or deployed autoload state cannot resolve that class.

Where this likely occurs

• inc/class-registration.php — Registration::init() lines 103-106 registers Registration::init_amp_blocks() on WordPress init.
• inc/class-registration.php — Registration::init_amp_blocks() lines 997-1008 lists ThemeIsle\GutenbergBlocks\Render\AMP\Circle_Counter_Block and directly instantiates each listed class at line 1005.
• inc/render/amp/class-circle-counter-block.php — ThemeIsle\GutenbergBlocks\Render\AMP\Circle_Counter_Block lines 8-13 declares the class named in the fatal.
• composer.json — autoload lines 61-65 classmaps inc/, so class resolution depends on generated Composer metadata.
• otter-blocks.php — bootstrap lines 35-42 only loads vendor/autoload.php before initializing Main in v3.2.2.
• Git history shows the unguarded AMP loop originates in 18e012b8. Later resilience commits 69e64b52330f4c7fcdc74c88211a8a5c4750764d and b8a7fd938c42a3746c04befd8364261b2d3b6e96 are not ancestors of v3.2.2.

Engineering notes

The tagged release contains the renderer source, so the telemetry error does not indicate that the repository omitted the PHP class. The observed failure is consistent with the class being present on disk but unavailable through Composer's generated classmap or another deployment/autoload inconsistency. The direct-construction AMP path differs from the separately guarded dynamic renderer registration path. The inspected telemetry covers AJAX requests only; broader request impact was not reproduced locally.

Test coverage status

tests/test-registration.php lines 163-245 covers Registration::register_blocks() behavior when dynamic renderer classes are missing, mapped to absent files, or unreadable. No relevant test invoking Registration::init_amp_blocks() or covering AMP renderer autoload failure was found during inspection.

What to verify or explore next

• Reproduce on a 3.2.2 installation where the AMP renderer source exists but the Composer autoload metadata does not resolve Circle_Counter_Block.
• Exercise Registration::init_amp_blocks() through an AJAX bootstrap and a standard frontend bootstrap.
• Check release-package Composer metadata against the inc/render/amp/ renderer files.
• Run the registration test suite while adding an AMP-path loadability scenario.

Unknowns / follow-up

• The telemetry payload does not include the installed vendor/composer classmap, filesystem state, or update history, so the exact reason the class was unloadable on the two sites is unknown.
• No local runtime reproduction was performed.

Confidence

Confidence: 94/100

Production telemetry records the same uncaught class-loading fatal on two sites running Otter Blocks 3.2.2. The tagged code directly constructs the reported AMP renderer without confirming that it is loadable, and local history contains later resilience work for stale Composer classmaps that is not included in 3.2.2.

Crash telemetry

Occurrences	2
Distinct sites	2
First seen	2026-08-13 00:09 UTC
Last seen	2026-08-13 00:10 UTC
Crash location	product:inc/class-registration.php:1005
Request context	ajax
Inside Themeisle SDK	no
Product versions	3.2.2
WP versions	7.0.4
PHP versions	8.2.33, 8.3.33
SDK versions	3.3.58, 3.3.59

---

Source: automated crash report — otter-blocks, fingerprint 6bd307720e22bbf2dfd19ab4df382dc7
Generated by bug-report-triage (ID: bug-report-triage_6a7d5d85c88fc5.33183855)

Start with inc/class-registration.php, especially Registration::init_amp_blocks() and its direct AMP renderer construction at line 1005. Review tests/test-registration.php for existing missing-class coverage, then add an AMP-path loadability scenario and run the registration tests. Done means an unavailable optional Circle_Counter_Block does not abort initialization during AJAX or frontend bootstrap.