Otter Blocks 3.2.0 fatals when Form_Server cannot be autoloaded

Summary

Otter Blocks 3.2.0 can terminate frontend WordPress initialization with Class "...Form_Server" not found.

Expected behavior: Otter Blocks initializes its registered server components without a fatal error.

Actual behavior: initialization reaches the Form Server entry and the request fatals before the frontend page can render.

Impact: affected sites return a fatal error on frontend requests while the faulty release is active.

Customer context

• Product / area: Otter Blocks initialization and Form Server
• Version: 3.2.0
• Environment: WordPress 7.0.2; PHP 8.4.23
• Integration / third party: Themeisle SDK 3.3.58 was present, but telemetry marks the crash location as outside SDK code.
• Reported error / symptom: Uncaught Error: Class ".../Form_Server" not found at the product's main autoload loop.
• Impact: 2 occurrences across 1 production site in the telemetry window; frontend request context.

Reproduction notes

Reported production path:

1. Activate Otter Blocks 3.2.0.
2. Load a frontend WordPress request.
3. During the product init sequence, the autoload loop attempts to instantiate Form_Server.

Observed result: the request fatals with Class "...Form_Server" not found at inc/class-main.php:97.

Reproduction status: confirmed by production crash telemetry; a local run against the shipped 3.2.0 archive was not performed because the archive is unavailable in the workspace.

Diagnosis

Conclusion

Production telemetry provides a direct fatal at the product autoload loop in Otter Blocks 3.2.0. The release tag contains Form_Server with the namespace that the loop requests, but the runtime cannot resolve it. This establishes an Otter Blocks class-loading failure for the captured deployment; the exact missing artifact or generated-autoload state is not available in the workspace.

Where this likely occurs

• inc/class-main.php — Main::autoload_classes() lines 63-100 includes \ThemeIsle\GutenbergBlocks\Server\Form_Server at line 87 and unconditionally instantiates each listed class at line 97, matching the telemetry location.
• inc/server/class-form-server.php — ThemeIsle\GutenbergBlocks\Server\Form_Server lines 8-33 declares the requested namespaced class in tag v3.2.0.
• composer.json — autoload lines 61-65 uses an inc/ classmap, so the release depends on generated Composer autoload metadata containing this class.
• bin/dist.sh — release packaging lines 26-32 copies the source into dist before Composer install commands execute in the repository root. This is a relevant packaging boundary, but it does not alone prove the exact artifact state that reached the affected site.

Engineering notes

• Telemetry identifies inc/class-main.php:97 as product code and explicitly marks the crash as outside Themeisle SDK code; routing is therefore Codeinwp/otter-blocks.
• The failure happens on the init action registered by Main::init() at inc/class-main.php line 36, so it can affect requests unrelated to form submission.
• The inspected source in v3.2.0 contains both the requested class declaration and its startup registration. The observed mismatch is consistent with incomplete or stale class-loading metadata in the deployed package, but that mechanism remains an inference without the shipped archive.

Test coverage status

tests/test-form-server.php exercises Form_Server behavior, and phpunit.xml lines 1-14 discovers PHP tests under tests/. No relevant test was found during inspection that installs the release artifact and verifies Composer can resolve every class instantiated by Main::autoload_classes().

What to verify or explore next

• May be worth verifying the distributed 3.2.0 archive's Composer classmap entry for ThemeIsle\GutenbergBlocks\Server\Form_Server and the presence of inc/server/class-form-server.php.
• May be worth reproducing a frontend bootstrap from the 3.2.0 archive on WordPress 7.0 with PHP 8.4.
• If reproducible, checking release-generation logs and the package contents for the v3.2.0 release could distinguish a missing source file from stale generated autoload metadata.

Unknowns / follow-up

• The production archive and its generated vendor/composer files were not available locally.
• Telemetry contains no structured stack trace beyond the fatal location, and no site-specific configuration is available.
• The affected site had SDK 3.3.58, but no inspected evidence links SDK behavior to this product-code fatal.

Confidence

Confidence: 92/100

Production telemetry records two frontend fatal errors on Otter Blocks 3.2.0. The reported class is directly instantiated during init, while the matching class source exists in the tagged release, confirming a release/runtime autoload defect rather than an SDK failure.

Crash telemetry

Occurrences	2
Distinct sites	1
First seen	2026-07-30 13:16 UTC
Last seen	2026-07-30 18:23 UTC
Crash location	product:inc/class-main.php:97
Request context	frontend
Inside Themeisle SDK	no
Product versions	3.2.0
WP versions	7.0.2
PHP versions	8.4.23
SDK versions	3.3.58

---

Source: automated crash report — otter-blocks, fingerprint b84f4f6a0e94f3a4f268d90867d444b8
Generated by bug-report-triage (ID: bug-report-triage_6a6d8b7c53bf53.04789623)

Start with inc/class-main.php:97 and inc/server/class-form-server.php to compare the class instantiated during init with the shipped source. Inspect composer.json and bin/dist.sh, then verify the distributed 3.2.0 archive contains the class and matching Composer metadata. Done means a frontend bootstrap resolves Form_Server without a fatal and relevant coverage verifies the release artifact or autoload path.