Problem
The GenericEmbedBlock has accumulated custom logic for specific embed types (DonorBox, YouTube), which undermines its sandboxing and generic nature:
- DonorBox:
dbox-widget is explicitly added to DOMPurify's ADD_TAGS to allow widget scripts
- YouTube: Different rendering path (uses
srcDoc vs blob URL) based on whether <script> tags are present
- Script detection: The component branches behavior based on embed content, creating implicit "types" within a supposedly generic block
This makes the block harder to reason about security-wise and harder to customize per embed type.
Proposed Solution
Split GenericEmbedBlock into purpose-specific blocks:
-
GenericEmbedBlock — Keeps strict sandboxing, no special-case logic. For arbitrary HTML/iframe embeds with full DOMPurify sanitization.
-
VideoEmbedBlock — Specifically for video embeds (YouTube, Vimeo, etc.). Could offer:
- URL-based input instead of raw HTML
- Aspect ratio options
- Autoplay / controls configuration
- Proper iframe sandboxing for video players
-
DonationEmbedBlock (or broader FormEmbedBlock) — For DonorBox and similar form/script embeds. Could offer:
- Provider-specific configuration fields
- Controlled script execution
- Styling options that make sense for forms
Note: There will likely be many form-type embeds beyond donations (registration forms, surveys, etc.), so consider whether this should be a broader FormEmbedBlock with a provider selector.
Files to Modify
src/blocks/GenericEmbed/config.ts — Refactor into multiple block configs
src/blocks/GenericEmbed/Component.tsx — Split rendering logic into dedicated components
src/blocks/RenderBlocks.tsx — Register new block types
src/components/RichText/index.tsx — Register new blocks for Lexical
src/collections/Posts/index.ts, HomePages/index.tsx, Events/index.ts — Add new blocks to BlocksFeature
src/endpoints/seed/blocks/generic-embed.ts — Split seed data per block type
src/components/Footer/Footer.tsx — Update embedded form rendering
- Migration needed for new block database tables
Context
From team discussion: the current approach of adding provider-specific logic to GenericEmbedBlock erodes the security boundary that sandboxing provides. Specific blocks allow each embed type to have appropriate security policies and UX while keeping the generic block truly generic.
Problem
The
GenericEmbedBlockhas accumulated custom logic for specific embed types (DonorBox, YouTube), which undermines its sandboxing and generic nature:dbox-widgetis explicitly added to DOMPurify'sADD_TAGSto allow widget scriptssrcDocvs blob URL) based on whether<script>tags are presentThis makes the block harder to reason about security-wise and harder to customize per embed type.
Proposed Solution
Split
GenericEmbedBlockinto purpose-specific blocks:GenericEmbedBlock— Keeps strict sandboxing, no special-case logic. For arbitrary HTML/iframe embeds with full DOMPurify sanitization.VideoEmbedBlock— Specifically for video embeds (YouTube, Vimeo, etc.). Could offer:DonationEmbedBlock(or broaderFormEmbedBlock) — For DonorBox and similar form/script embeds. Could offer:Files to Modify
src/blocks/GenericEmbed/config.ts— Refactor into multiple block configssrc/blocks/GenericEmbed/Component.tsx— Split rendering logic into dedicated componentssrc/blocks/RenderBlocks.tsx— Register new block typessrc/components/RichText/index.tsx— Register new blocks for Lexicalsrc/collections/Posts/index.ts,HomePages/index.tsx,Events/index.ts— Add new blocks to BlocksFeaturesrc/endpoints/seed/blocks/generic-embed.ts— Split seed data per block typesrc/components/Footer/Footer.tsx— Update embedded form renderingContext
From team discussion: the current approach of adding provider-specific logic to GenericEmbedBlock erodes the security boundary that sandboxing provides. Specific blocks allow each embed type to have appropriate security policies and UX while keeping the generic block truly generic.