Static Otter blocks become invalid after visible HTML text edits

[pirate-bot]

Summary

Some static Otter blocks become invalid when a user uses Edit as HTML to change visible content, including date or text values. A content-only HTML edit is expected to remain a valid block when the editor offers this mode. Instead, reopening or parsing the edited markup can report that the block is invalid or broken, preventing users from making manual content changes without recovery. This affects users who prefer manual editing rather than AI-assisted editing.

Customer context

Product / area: Otter Blocks, block editor HTML mode
Version: Unknown from available evidence; the defect is present in current source corresponding to release tag v3.2.6
Environment: WordPress block editor; WordPress and browser versions were not provided
Integration / third party: No AI provider connected; the reported failure concerns manual HTML editing
Reported error / symptom: Changing block HTML, including a date, causes the block to break
Impact: Manual content edits through HTML mode are unreliable for affected blocks

Reproduction notes

Reported workflow:

1. Insert or open an Otter block.
2. Select Edit as HTML.
3. Change visible content, such as a date.
4. Return to visual editing or let WordPress parse the edited block.
5. Observe that the block is reported as broken or invalid.

Repository-derived representative cases include changing Countdown date markup, Progress Bar visible title or percentage text, and Accordion Item summary text. These specific cases were established from serialization inspection but were not executed in a browser during triage. The exact customer block, markup, WordPress version, and error text are unavailable.

Diagnosis

Conclusion

The reported behavior is consistent with a confirmed serialization defect in the inspected static-block paths. Several blocks emit user-visible values from attributes stored only in the block comment, while their metadata provides no HTML source from which a manual content edit can be parsed. The next serialization can therefore regenerate the old value and fail markup validation against the edited HTML. The customer did not identify a block slug, but the Countdown, Progress Bar, and Accordion Item paths all expose this defect class in current source.

Where this likely occurs

• src/blocks/blocks/countdown/block.json — Countdown attribute schema lines 10–16 and block supports lines 172–174: date has no HTML source, and the metadata does not opt out of HTML editing.
• src/blocks/blocks/countdown/save.tsx — Save lines 69–96: saved markup derives data-date from attributes.date and regenerates displayed timer markup from attributes rather than edited HTML.
• src/blocks/blocks/progress-bar/block.json — Progress Bar attribute schema lines 14–24: title and percentage have no HTML sources.
• src/blocks/blocks/progress-bar/save.js — Save lines 11–75: the unsourced title and percentage attributes are serialized into visible text in several markup branches.
• src/blocks/blocks/accordion/item/block.json — Accordion Item attribute schema lines 11–25: title has no HTML source, and HTML editing is not disabled in the declared supports.
• src/blocks/blocks/accordion/item/save.js — Save lines 10–29: attributes.title is emitted as visible summary content through RichText.Content.
• Git blame traces the Countdown schema and generated display markup to its original 2021–2022 implementation, present from the v2.0.0 release line onward. No verified previously working release boundary was found.

Engineering notes

The inspected defect is in free-plugin static block serialization, not the AI-provider flow. The customer’s AI comment describes an unwanted alternative workflow rather than evidence of an AI integration failure. The exact WordPress core validation implementation was not inspected locally; the reported runtime symptom plus the mismatch between declared sources and saved markup establishes the affected product path. Other static blocks may have the same contract, but only representative Countdown, Progress Bar, and Accordion Item paths were inspected closely.

Test coverage status

src/blocks/test/e2e/blocks/countdown.spec.js — Countdown Block tests lines 11–83 cover insertion, date selection, publishing, and frontend countdown output but not manual HTML round-tripping. src/blocks/test/e2e/blocks/progress-bar.spec.js — Progress Bar Block lines 11–25 covers insertion only. src/blocks/test/e2e/blocks/block-telemetry.spec.js — reports invalid Otter block markup once per slug lines 275–334 confirms invalid markup detection for an intentionally malformed Advanced Heading block, not validity after editing content in HTML mode. No relevant Accordion Item HTML-edit coverage was found during inspection.

What to verify or explore next

• May be worth reproducing Edit as HTML content changes separately for Countdown, Progress Bar, and Accordion Item on the supported minimum WordPress version and current WordPress.
• A focused parse/serialize check could confirm whether changing data-date, Progress Bar title text, or Accordion Item summary text produces isValid: false.
• May be worth inventorying other static Otter blocks whose saved visible content comes from attributes without HTML sources while HTML mode remains available.
• Checking packaged v3.2.6 assets against the source schemas can confirm the same metadata and serializers ship in the release artifact.

Unknowns / follow-up

The feedback does not identify the exact block type, original markup, WordPress version, or the precise validation message. A local browser reproduction was not performed.

Confidence

Confidence: 91/100

The customer’s symptom matches a concrete serialization mismatch in multiple inspected static Otter blocks: visible values are emitted from comment-stored attributes but cannot be parsed back from manually edited HTML. The report supplies the observed editor failure, and current source shows how content-only edits can produce invalid markup; no exact open GitHub issue was found.

---

Source: automated NPS survey feedback — otter-blocks, 2026-09-23
Generated by bug-report-triage (ID: bug-report-triage_6ab4b307027113.81109428)

[girishpanchal30]

I have fix it with PR #3073