Blocks field type for composable page sections

[mvanhorn]

For building landing pages, marketing sites, and structured content beyond blog posts, EmDash needs a way to compose pages from reusable content blocks.

What this enables

A "Landing Page" content type with a "sections" field containing: Hero, Feature Grid, Testimonials, CTA, FAQ blocks. Each block type defines its own fields (e.g., Hero has heading, subheading, image, CTA button). Editors pick from available blocks, reorder them, and fill in per-block fields.

Proposed behavior

• New FieldType: blocks
• Block types are defined per-field in the schema builder (not globally)
• Each block type has a name, icon, and set of sub-fields
• Stored as JSON array: [{_type: "hero", heading: "...", ...}, {_type: "cta", ...}]
• Admin UI: block picker dropdown, drag-to-reorder, per-block field editing
• Front-end: renderBlocks() helper maps block types to Astro components

Relationship to Portable Text

EmDash already uses Portable Text for rich text (inline formatting, links). Blocks are complementary -- they're for page-level structure, not inline content. A blocks field could contain Portable Text fields within individual blocks.

Scope

Two phases:

1. Core blocks field type with admin UI and JSON storage
2. Block type registry for plugins to register custom blocks

The existing packages/blocks/ directory has Portable Text block definitions and a playground that could serve as a foundation.

Happy to start with Phase 1 if the direction makes sense. Would appreciate guidance on whether to build on top of the existing blocks package or keep this separate.

[lightyearsagency]

Absolutely agree.

As bloated as Wordpress and ACF are, the ability to repeat structures across the site based on CMS settings is a massive part of what we deliver to clients.
Intro area on pages, grids of tiles with title, images and links etc. CTA blocks etc.

Though technically it could all be hard-coded and ran through an AI Agent, a 'Page\Block builder' is something I keep running into as a need for a CMS, not just a want.

If Emdash gains the functionality of ACF, I will be a happy developer.

[mvanhorn]

Totally agree, @lightyearsagency. Repeatable structured sections (hero, CTA, testimonials, etc.) are table stakes for agency delivery. The goal here is to give emdash that same composability without the ACF bloat. Glad to hear it resonates with your workflow.

[ascorbic]

Hey! Would sections handle this? It seems like it could.

[lightyearsagency]

Sections aren't as per-page dynamic, and insert into the main richtext area currently i think. So there's no clean input for say... A tile builder with title, icon, text and link each, than can be rearranged, and have a variable number, inside their own wrapper. I could be wrong, but wasn't able to work it out

…

On Wed, 8 Apr 2026, 7:37 pm Matt Kane, ***@***.***> wrote: Hey! Would sections <https://docs.emdashcms.com/guides/sections/> handle this? It seems like it could. — Reply to this email directly, view it on GitHub <#337 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKZDO2Y46NY2OC32ZWHR5D4UYMULAVCNFSM6AAAAACXOWSH4WVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNBYG4YDONA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mvanhorn]

@ascorbic Good question. Sections are reusable Portable Text content that gets inserted into a richtext editor - they're great for pre-built content snippets. What this proposes is a field type where each page defines its own sequence of typed blocks (hero, CTA, feature grid, etc.), each with their own schema. The key difference is per-page composition with structured fields vs. inserting pre-authored content.

@lightyearsagency described the use case well - a tile builder where each tile has title/icon/text/link, variable count, reorderable, in their own wrapper. Sections don't give you that per-field schema structure.

That said, if you think Sections could be extended to cover this, happy to explore that direction instead. You know the architecture better than I do.

[joaopedrofrech]

Wordpress has Elementor and many page builders with WYSWYG support, even Gutenberg kinda does it. Without this approach, this project will be more developer focused then end user focused, and I doubt it gains as much traction as it needs to compete.

[CacheMeOwside]

Strong +1 on this! Reusable patterns would be a great addition to EmDash.

I believe we can use the same JSON format EmDash already uses for Portable Text like @mvanhorn proposed. It looks like this would be similar to how Sanity CMS uses Portable Text for page building.

I'm wondering if it would be possible to reuse <PortableText components={...} /> for the front-end endering of the blocks, instead of the renderBlocks() helper. <PortableText> already maps each block's type to an Astro component. Curious whether renderBlocks() would doing something <PortableText> can't.

[mvanhorn]

@CacheMeOwside That's a good instinct and probably the cleanest path. <PortableText components={...} /> already maps each block's _type to a component, and for top-level page sections that's exactly what we want. If we keep the storage format as [{_type: "hero", ...}, {_type: "cta", ...}], rendering reduces to <PortableText value={blocks} components={{hero: HeroSection, cta: CTASection, ...}} /> and there's no renderBlocks() helper to maintain.

The one thing PortableText assumes is that its input is a document with inline flow (paragraphs with marks, lists, inline custom blocks). A pure page-sections array skips the inline layer entirely. In practice that's fine - PortableText renders whatever types it finds in the components map - but it might be worth a small convention: either a wrapper block type for page-level sections, or just document that "pages are flat block arrays, rich-text pages embed richtext blocks inside."

This also answers @ascorbic's earlier question: if Blocks use the same Portable Text format and <PortableText> for rendering, then Blocks are mostly a schema-builder UI feature for defining per-block fields, not a whole new rendering pipeline. That's a much smaller scope than I originally proposed.

[ascorbic]

I think @CacheMeOwside has the right instinct here. The scope can be quite a bit narrower. @mvanhorn is right though that the layout expected by PortableText is different. I wonder if a new sibling component would be a better approach than a helper though.

It's worth looking at #679 too, which might help with the admin UI end of things.

[Natetronn]

I started giving EmDash a try and to see how far I could get with it by applying it to a site that was already fully built out on Astro with a Directus backend/api. I wanted to see what EmDash was capable of by having 100% of the context I needed to understand what it could handle on a known project versus starting a site from scratch and running into issues as I went. So I converted all this site's current templates and data over to EmDash (in the past this would be crazy talk, but we now have AI and all that jazz).

Anyway, not having this type of featues is one of the major pain points for me on this project so far, because I had built a "Page Builder" of "Blocks" and some repeating content/media as well.

Directus handles "Page Builder" or "Repeater" type content using its Relationship and or JSON arrays of objects fields.

Note: Directus just sits on top of a Database (Postgres, in my case) so it follows a database paradigm for all its fields. It talks a little bit about that here. It's my understanding that it uses Knex under the hood for DBs.

https://directus.com/docs/guides/data-model/relationships

It's Many to Any (M2A) Relationship field (aka interfaces) is what make the magic happen for Page Builders:

https://directus.com/docs/guides/data-model/interfaces#builder-m2a

It also has a repeater field that uses a JSON Array of Objects:

https://directus.com/docs/guides/data-model/interfaces#repeater

Directus is great! And I'll continue to use it for larger API driven projects, but for smaller ones, I have been looking for something similar to EmDash, and since I already use Astro, I was excited to test it out.

[djmtype]

Yes, Directus is great, but there are shortcomings like the repeater field doesn't seem to support an image field; probably for some good reason. Still, it's an extra step. You have to go out of your way to set up a relationship field for it. It's not a dealbreaker, but a quality-of-life annoyance.

My main criticism of Directus today is its lack of a PortableText equivalent. They have a block editor (via editor.js), but you can't add M2A blocks to it – at least to my knowledge.

There is a 3rd-party extension, I wish Directus natively adopted. It uses TipTap (like emdash) and allows integrating M2A blocks at the block- and inline-level. However, I'm afraid to use it on client projects because it might become vaporware.
https://github.com/formfcw/directus-extension-flexible-editor

At this stage, I think of Directus' M2A blocks like ACF's Flexible Content. https://www.advancedcustomfields.com/resources/flexible-content/

Of course, Directus goes far beyond a typical CMS with Flows, etc.

Unfortunately, with Directus' lack of PortableText integrated custom blocks, I only use it on specific projects; and painstakingly default back to Wordpress, otherwise.

[Natetronn]

Yes, Directus is great, but there are shortcomings like the repeater field doesn't seem to support an image field; probably for some good reason. Still, it's an extra step. You have to go out of your way to set up a relationship field for it. It's not a dealbreaker, but a quality-of-life annoyance.

My main criticism of Directus today is its lack of a PortableText equivalent. They have a block editor (via editor.js), but you can't add M2A blocks to it – at least to my knowledge.

There is a 3rd-party extension, I wish Directus natively adopted. It uses TipTap (like emdash) and allows integrating M2A blocks at the block- and inline-level. However, I'm afraid to use it on client projects because it might become vaporware.
https://github.com/formfcw/directus-extension-flexible-editor

At this stage, I think of Directus' M2A blocks like ACF's Flexible Content. https://www.advancedcustomfields.com/resources/flexible-content/

Of course, Directus goes far beyond a typical CMS with Flows, etc.

Unfortunately, with Directus' lack of PortableText integrated custom blocks, I only use it on specific projects; and painstakingly default back to Wordpress, otherwise.

It's my understanding that the creator of Flexible Editor is now on the Directus team and the extension (or some form of it) is now first party, if not built in. So your concern may not be valid any longer.

There is PortableText of some sort and I began implementing things based on that, but I can't remember what I used. Not off the top of my head anyway (and I'm traveling so won't be able to check until I get back.)

Of course, my comment wasn't really about Directus and more a "this is how this feature has been implemented elsewhere" in the hopes of contributing to the conversation.

[djmtype]

Of course, my comment wasn't really about Directus and more a "this is how this feature has been implemented elsewhere" in the hopes of contributing to the conversation.

I know. I'm just an old man shouting at the cloud. I'm currently working on a Directus project, wanting to use emdash because of its PortableText integration, but realizing it's too green right now.

[Natetronn]

All good! I think I may have started using this at the time:

https://www.dirextensions.com/details/directus-extension-block-editor-interface/

It's been awhile and I didn't finish that aspect of the build (the client changed from wanting full edit capabilities so I was less concerned about implementing it; although I got 90% of the way there).

[djmtype]

Looks like an active Directus branch where they are natively implementing TipTap into their CMS. https://github.com/directus/directus/tree/feat/wysiwyg-tiptap

[cyface]

Production data point in support of the narrowed scope: we run an EmDash site in production whose landing pages are composed from exactly the shape this discussion proposes — five section block types (hero, feature grid, testimonials, cards grid, FAQ) registered as Portable Text custom blocks by a local plugin and rendered by mapping _type → Astro component. So we can confirm @CacheMeOwside / @mvanhorn's conclusion from the storage/rendering side: the Portable Text format + component-map rendering already works fine today for page-level sections. Nothing new is needed there.

All of our friction is on the editing/schema side, which supports the "Blocks is mostly a schema-builder UI feature" framing. Concretely, the workarounds we ship because per-block sub-fields don't have parity with top-level field types:

• No nested object element — a CTA's { label, url } has to be flattened into sibling scalar fields (primaryCtaLabel + primaryCtaUrl), and the renderer reads the flat keys.
• Repeater sub-fields are scalar-only — "list of content entries" degrades to a single multiline text field of entry slugs, split on newline at render time (our cards-grid block does this; typos are silent and there's no discoverability for editors).
• No media picker in the block field modal — image fields (e.g. a testimonial avatar) are hand-typed URL strings.

Each is workaroundable, but each moves the editing experience further from what non-technical editors expect from a section builder. A blocks/sections field whose per-block sub-fields support objects, entry references, and media picking would let us delete all three workarounds — that field-type parity is, from where we sit, the entire gap.

(Posted with AI assistance — Claude Code / Claude Fable 5, from @cyface's session; details are from our production plugin.)