Codeinwp / Codeinwp/otter-blocks

Prevent frontend fatal when Form Multiple Choice renderer is unavailable

Open Beginner friendly
#3,005 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug-report bug-report-triage crash-report
Dominant language
JavaScript
Stars
198
Forks
36
Avg merge
3d 4h
Merged PRs (30d)
30

Description

Summary

Otter Blocks can terminate a frontend request while registering the Form Multiple Choice block when its server-side renderer class is unavailable.

Expected behavior: Block registration continues safely when an optional or unavailable renderer cannot be loaded.

Actual behavior: The request throws Error: Class ".../Form_Multiple_Choice_Block" not found during block registration.

Impact: Affected sites return a fatal error on frontend requests. Production telemetry recorded 464 occurrences across two sites.

Customer context

  • Product / area: Otter Blocks dynamic block registration, Form Multiple Choice
  • Version: 3.2.1
  • Environment: WordPress 7.0.4 and 7.1; PHP 8.3.33 and 8.4.24
  • Integration / third party: ThemeIsle SDK 3.3.59 was present; the crash location is not inside SDK code.
  • Reported error / symptom: Error: Class ".../Form_Multiple_Choice_Block" not found on frontend requests.
  • Impact: 464 telemetry occurrences across two distinct sites between 2026-08-28 and 2026-08-29.

Reproduction notes

  1. Use Otter Blocks 3.2.1.
  2. On a frontend request, reach init so Registration::register_blocks() processes form-multiple-choice.
  3. Make the mapped Form_Multiple_Choice_Block unavailable to the active autoloader.
  4. The reported 3.2.1 path attempts to construct the unavailable class and produces the reported fatal.

Production reproduction evidence is the captured stack trace at inc/class-registration.php:973; the unavailable-class condition has not been recreated locally.

Diagnosis

Conclusion

The released 3.2.1 registration path maps form-multiple-choice to Form_Multiple_Choice_Block and directly constructs the mapped class after checking only that the mapping exists. The production fatal at that construction line confirms that the class was unavailable on affected installations. Commit 476104b7 later added a class-availability condition and is included in v3.2.2, which corroborates this unsafe path.

Where this likely occurs
  • inc/class-registration.phpRegistration::register_blocks() lines 855-868 maps form-multiple-choice to \ThemeIsle\GutenbergBlocks\Render\Form_Multiple_Choice_Block.
  • inc/class-registration.phpRegistration::register_blocks() lines 971-987 in v3.2.1 checks only isset( $dynamic_blocks[ $block ] ) before new $classname() at line 973, matching the telemetry location.
  • inc/render/class-form-multiple-choice.phpForm_Multiple_Choice_Block lines 8-24 defines the expected renderer class and its render() method.
  • composer.jsonautoload lines 61-65 declares a Composer classmap for inc/; the exact deployed reason the class was unavailable is not identified by the telemetry.
  • Commit 476104b7 (fix: ensure dynamic block renderer class exists before instantiation) changes this registration condition; git tag --contains identifies v3.2.2 as the first release tag containing it.
Engineering notes

This is an Otter Blocks registration-path failure, not a ThemeIsle SDK crash: telemetry marks the location as outside SDK code, and the relevant mapping and construction are in the plugin repository. The renderer is normally present in the inc/ classmap, but the observed fatal demonstrates that the 3.2.1 path does not tolerate an unavailable class. The evidence does not establish whether the affected installations had incomplete or stale distributed autoload metadata, or another loading conflict.

Test coverage status

tests/test-choices-field-block.php covers rendering methods for Form_Multiple_Choice_Block, not unavailable-class handling during registration. tests/test-registration.php lines 84-155 contains registration test scaffolding, added with the later protective commit; it was not present in v3.2.1. No relevant v3.2.1 test coverage for an unavailable dynamic renderer was identified during inspection.

What to verify or explore next
  • Reproduce with the v3.2.1 package while making the mapped renderer unavailable to the autoloader, then invoke the frontend init registration path.
  • Verify distribution artifacts and Composer classmap contents from affected 3.2.1 installs, if retained.
  • Run the dynamic renderer registration coverage in tests/test-registration.php against current release packaging.
Unknowns / follow-up
  • The telemetry does not expose the autoloader state or filesystem contents that made this otherwise shipped class unavailable.
  • The precise distribution or environment condition affecting the two reported sites is unknown.

Confidence

Confidence: 96/100

The production stack trace is anchored to Otter Blocks 3.2.1, whose released registration code directly constructs the configured renderer without confirming that the class is available. A later Otter Blocks commit explicitly adds that availability guard and is included in v3.2.2, corroborating the failure path.

Crash telemetry

Occurrences 464
Distinct sites 2
First seen 2026-08-28 21:55 UTC
Last seen 2026-08-29 13:47 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.4, 7.1
PHP versions 8.3.33, 8.4.24
SDK versions 3.3.59

Source: automated crash report — otter-blocks, fingerprint a290535629db22227642fadc1fdc4f1f
Generated by bug-report-triage (ID: bug-report-triage_6a93c741219e02.85555627)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Inspect Registration::register_blocks() in inc/class-registration.php, especially the dynamic renderer mapping and construction around lines 855-987. Read tests/test-registration.php and run its registration coverage, then verify that a missing Form_Multiple_Choice_Block does not abort registration while available renderers still work.

Written by the indexing model from the issue text.

Assessment

Tech stack
php, wordpress
Domain
backend, testing
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
78/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.